the point is that Next can bootstrap an app with only 2 files (your entry point and package.json) as I mentioned.
Of course you can write code on top of bun to turn it into a mini web framework but it is nowhere as lean as the Nextjs minimal setup I've just described, in terms of how much code you have to write.
I should not have to explain this, but that just runs typescript. It doesn't even render tsx (you have to write the code to call renderToString or whatever), it also does not create the minimal html scaffolding behind the scence that nextjs does for you
Here is a one-liner:
$ bun add react{,-dom} next; mkdir pages;echo "export default () => 'Hello world'" >> pages/index.tsx; bun next dev
Note that if you replace "Hello world" with a stateful component (like a dummy counter) it would still work, because again Nextjs serves the js bundle and not just html.
With your `bun run pages/index.tsx`, it doesn't even work with the minimal tsx like that (obviously, it's for running a script). And after you add a bunch of code to render and serve html string, it still CANNOT serve a stateful react component.
Converting JSX to HTML with Bun requires only the react{,-dom} dependency.
And renderToString() is awesome in the sense that it is obvious code. Much less magic.
Don't get me wrong. Frameworks have their uses. But Bun offers routing and jsx rendering out of the box, making frameworks much less desirable for many use cases.
When a framework version deprecates, there's work to be done to convert to new versions. OTOH there's much less work if you don't use a framework.
It gives you building blocks to hack together your own router and SSR. Not the same as offering things "out of the box".
You talk about framework deprecation while using non standard APIs of an alternative runtime. The risk is the same. If anything, Bun is much less popular and more likely to die than Nextjs.
Don't even get me started on htmlx, something revolved around some wishful idea from 20 years ago on how the web should work, it never picked up all that time so why now?
> Don't even get me started on htmlx, something revolved around some wishful idea from 20 years ago on how the web should work, it never picked up all that time so why now?
I can talk about my own experience with this "just fetch and replace HTML instead of having a fat js frontend".
Before htmx or its ancestral intercooler even existed, I created a system using this methodoly. It fetches and replaces HTML using ajax/js.
It has been over a decade and it is still easy to maintain and getting new features. It has over 900 database tables and over 1000 different pages full of business logic, to give you an idea of the size. It is dead simple to deploy. Has no build step. The code is KISS but organized in layers, and can withstand regular developer churn just fine. New devs are productive week 1, sometimes day 2 even.
So yes, I'll get you started with htmx because, it feels dirty I know, but it scales and produces long lasting maintainable software.
> Bun is much less popular and more likely to die than Nextjs.
Can't agree. Bun is one of a kind, innovative, tool in many aspects. The package management alone is already leagues above yarn, pnpm and npm. They have other strong fronts such as builtin testing, bundling, and others.
Meanwhile Nextjs has some merits but it is just one of the thousand js web frameworks. There's sveltekit, nuxt, Angular. Next got popular because Vercel keeps pouring their 300 mil USD VC funds into marketing and youtubers.
Next has no big differentiation compared to other frameworks.
Of course you can write code on top of bun to turn it into a mini web framework but it is nowhere as lean as the Nextjs minimal setup I've just described, in terms of how much code you have to write.