I’ve been self hosting small web apps using an SSH service https://tuns.sh and it helped me replace my DO droplet pretty successfully. What’s nice is it also has built-in usage analytics, alert notifications when a tunnel goes down, and fully manageable with a remote TUI which means I don’t have to install anything to use it.
I’m not an expert in this but as far as I can tell there will never be a margin call. There’s only a margin call if he defaulted on his loans. All the banks will do is ask to restructure the loan to compensate for the loss in the collateral.
Further, it’s just $6bn which musk can easily cover.
> The funding included $7 billion of senior secured bank loans; $6 billion in subordinated debt; $6.25 billion in bank loans to Musk personally, secured by $62.5 billion of his Tesla stock; $20 billion in cash equity from Musk, to be provided by sales of Tesla stock and other assets; and $7.1 billion in equity from 19 independent investors.
As far as I’m concerned, SSR is completely over-hyped and adds a ton of complexity to your project. All these search indexers are all running headless chrome anyway so the SEO argument is largely false now.
Running vite and deploying a fully static site that interacts with an API is, to me, vastly simpler to reason about than a blackbox react framework (next.js) sitting on top of a black box rendering library (react).
Having a “backend for your frontend” is pure overhead for most projects. I’ve been building on the FE for a decade and have only needed SSR once and certainly never needed some hybrid static/dynamic/islands setup.
If you need SSR, you need it, but I find SPAs to be vastly superior in terms of dev speed and overall performance of an app once the JS has loaded.
> That project was depreciated and the popularity of the Next.js site framework for react projects (plus I certainly assume heavy lobbying from Vercel) pushed the react docs to officially suggest create-next as the new starting point.
It seems like Vercel had enough money and hype to lure react devs away from facebook to work for them. I see this as the biggest reason why react is pushing users towards vercel. Further, Vercel was able to work very closely with the react dev team when developing react server components, giving vercel a first-to-market advantage and a headstart on vendor lock-in.
They don't, though, they consistently want the cheaper machine made products rather than the artisinal human made versions. Sure it might align with their "values" but when they see the value difference at the cash register their minds will quickly change. It's already happening with AI designed products.
The problem with sync engines is needing full-stack buy-in in order for it to work properly. Having a separate backend-for-frontend service defeats the purpose in my mind. So what do you do when a company already has an API and other clients beyond a web app? The web app has to accommodate. I see this as the major downside with sync engines.
This comment is steeped in bias. The front end is not complex for its own sake, it’s complex because APIs are needlessly rigid: https://bower.sh/front-end-complexity
If you're not building something like Gmail, Docs, or Figma (AKA an app that should be on the desktop instead of the web). Rendered HTML should be the way to go, even if it's just a gateway to a more complex infrastructure.
reply