I'm coming back to Django after a decade of experience with it post-0.96 and having moved to Next.js a few years ago. Going from 1,700 dependencies to 65 total with Django + Wagtail + HTMX.
With C#'s Blazor templating, you can ditch all JS logic, and use raw C# for all front-end logic, and have it all be transparently server rendered similar to how Phoenix has LiveView.
I also have experimented with HTMX and Django, and that seems to be a nice combination.
There are some easy optimizations wins for this page but none of the top ones are framework related. Maybe with the faster build times they can easily optimize images and 3rd party dependencies. As someone else pointed out, nearly half that data is unoptimized images.
For the curious, google's current homepage is a 200kb payload all in, or about 50 times smaller.
Who remembers sprite sheets? Does that give my age away?
I did an optimization pass for a client once where I got rid of a ton of the sprites but didn't have the energy to redo it all, so it just had huge sections that were blank.
same here and I'm using a beefy MacBook (Apple M4 Max, 64gb ram). something is wrong with the front end code. there are a lot of animations, so my hunch would be that something goes wrong there.
Ha! I normally wouldn’t find it quite so hilarious, but it’s a stylistically pixelated image. There’s just too much irony packed in there to not chuckle.
I migrated the landing pages for my app[1] from Nextjs to Astrojs mainly because I was paying Vercel $20 per month for serving static pages(it’s 4 times more than I pay Railway for the Postgres database for the actual app and also 4 times more than I pay Cloudflare for hosting all my apps). I used AI for migrating and it took a few days only as the existing repo was used as “instructions” and it included some upgrades and improvements here and there.
It means you take responsibility of maintaining the server forever, i.e. dealing with TLS certificates, SSH keys, security updates, OS/package updates, monitoring, reboots when stuck, redeploy when VPS retired, etc. Usually things work fine for a year or two and then stuff starts to get old and need attention and eat your time.
I just did this over at Hetzner and Claude admins it for me so I don't need to learn the CLI or anything, describe the proxying I want, and it setups up a bunch of small side project pages for me.
We went through a very similar migration. Had a Next.js landing page and a separate TanStack Router SPA - consolidated both into a single Vite + TanStack Start app. Same experience with build times and the architecture mismatch: our app is heavily client-side with real-time state, and fighting Next.js's server-first assumptions wasn't worth it. TanStack Router's type-safe routing and file-based route generation have been great.
I hadn't heard of TanStack but a quick look at their website doesn't inspire confidence tbh. I mean, just take "TanStack Pacer".
It provides such things as:
```
import { Debouncer } from '@tanstack/pacer' // class
const debouncer = new Debouncer(fn, options)
debouncer.maybeExecute(args) // execute the debounced function
debouncer.cancel() // cancel the debounced function
debouncer.flush() // flush the debounced function
```
Why? Just why do you need to install some "framwork" for implement debouncing? Isn't this sort of absurdism the reason why the node ecosystem is so insecure and vulnerable in the first place? Just write a simple debouncer using vanilla js...
I have a Nextjs heavy app which takes around 7 minutes currently. But I've been thinking of moving away from next for a long time now. TanStack seems to be a good fit. This gives me a bit more confidence in just doing it.
Is server-rendered HTML that bad for 2026 web or is everyone building complex apps?
Many of my customers insists on using Next.js or similar but when I browse their website I don't get the point. They are downloading and executing megabytes of JS while in-page interactions tends to be limited to few basic stuff. Never seen one of their project requiring offline mode. Maybe that's being able to easily replace a [FRAMEWORK] dev with another.
I think the unfortunate truth is the simplest. Web development has long been detached from rationality. People are drawn to complexity like moths to a flame.
I made two serious attempts to get into front end web development, around 5 years apart. Both times I started with the most popular framework. Both times the most popular framework was something different before I even finished the project.
I've been pretty happy with TanStack start for a medium-sized project. I would not know how its build time would compare to Next, but our similarly sized Remix (sorry, React router v7) app takes longer to build.
TanStack just has a nicer mental model overall and works great with TanStack query for cache I validation and stuff like that.
Remix was promising but there was so much ceremony in registering API routes and stuff. Tanstack just lets you define server functions arbitrarily with no ceremony.
Might be worth a spike and some tokens to ask Claude Code to migrate and test the build time and ergonomics.
I've been on the remix on a previous project, I have to say that Remix was even worse. But that's probably of the setup with vite etc not being correctly done.
We also recently cut our build times in half moving from Webpack to Turbopack on production builds after jumping to NextJS 16. We'd already been using Turbopack in development for a while which yielded massive DX improvements related to performance. Production build times will drop further once Turbopack production build caching is stable.
Webpack -> Turbopack is the smart initial migration. I'd bet Railway went straight from Webpack -> Vite not realising that their real gains sat with the build tooling, not NextJS vs Tanstack.
A lot of the LLMs are very familiar with next.js and vercel is also aggressively building an ecosystem around their tooling for LLMs. So I wonder if this problem will only be exacerbated when everyone using LLMs is strongly nudged (forced) to use next?
Is that because LLMs default to the older pages router? Or are they actually providing a different version of the library optimised in some way for agents?
The irony is deploying NextJS on the railway platform is super slow since they use containers, on Vercel 2 min is like 12 min on railway, deployments on a vps are only like 20 seconds.
*I know this is just build time, so this is different then their deployement time
Not containers to blame but overprovisioning and how much resources dedicated to building. I am not sure how Vercel gets things build in literal seconds, but, hey, they are the creators of NextJS.
At DollarDeploy we building it also in containers but every build get 4GB/2CPU so it is quite fast but not as fast as Vercel.
This is the kind of post I wish more teams would write. The "we picked the popular thing and it got slow" story is so common. But most teams just live with it. They don't want to touch it. 10 minutes to 2 minutes is huge for dev speed!
I'm a huge fan of tanstack start especially the ability to just static prerender some paths (a feature I'm missing a ton with astro)
For me tanstack start is the new dominator on the stack!
Is the quality of software engineers really dropped that low that people get excited when they move off from "heavy bloated" frameworks to lighter alternatives? Or is this just SEO farming garbage to position the company higher in search results?
I don't know the situation now, but a while ago there were a lot of pushback using Next.js because it was not easy to use all features if not hosted on Vercel.
I've used the other major meta frameworks (remix and tanstack). I don't think there is a way to improve the speed of building the app in those ecosystems. Happy to be proven wrong.
Anyone tried to use vinext from Cloudflare in production? Might be faster.
But seriously, not sure why NextJS builds take so much, we are using stable and functional pages router in DollarDeploy and it is still takes too much time to build.
None of the above. It is a utility (I guess framework maybe) for a feature that was cool in ASP.NET back in 2005. But that is it's charm. It is just JS swapping out the dom for you.
As a non-frontend developer mainly observing and touching something here and there, a lot of the things that frontend developers do seem vastly over-engineered.
I'm not insanely deep into frontend, I mostly just pick up React and call it a day, but it seems like this is also over-engineered?
I've seen vanilla JS before, and I just know I wouldn't want to do the housekeeping that comes with it. People claim it's less work because it' simpler, but I fully expect myself to rewrite the thing at least twice, only to give up because I have no actual mental model anymore of how it works.
Isn't the main problem that the building blocks the modern web is based on are not a good fit for what we do with it?
CSS is a total mess. HTML is a mess. JS is okay, but is not a high quality language.
We would save so much time and money if we would have a modern base to build on. Sadly this will probably never happen, because company interests will try to corrupt the process and therefore destroy it.
This is my understanding too - tools like react are like microservices - they’re a technical solution to an organisational problem. HTML/css/JavaScript is an imperfect abstraction, so we got bootstrap. Then we got client side frameworks which introduced a build step, and then we got asset bundles, optimisers, linters, validators, tree shakers, package managers, validators for your package managers. All of these monkey patched around the actual problem with more abstractions, and the end result is what we have now.
Not that backend is any better - microservices everywhere, must scale to Facebook traffic even if we only have 10 customers, etc. Saying this as a backend dev
C is infinitely less complex to parse and validate than Typescript. C is compiled in a single pass, the `tsc` type checking algorithm has to check structural typing, conditional types and deep generics while also emulating JS' dynamic behaviour.
I don't think any C compiler has been single pass for the last 20 years. Typescript's analyses are also not that complicated, it's just that the typescript type checker is written in js. Iirc the actual ts -> js part is pretty fast with some of the more recent compilers.
I disagree - this is an excuse. Even the post we’re commenting in now shows that it’s a series of poor abstractions and bad tooling that takes way too long to do the basics, combined with a language and ecosystem that encourages this behaviour . They saw a 5x speed up by changing tools while still using a JavaScript framework so it’s clearly possible for it to not be complete nonsense.
The two-PR strategy is smart — decouple from the framework first,
then swap it. That's the kind of migration discipline most teams skip,
and it's why they end up running two systems in parallel for months.
I run a Next.js App Router site in production (marketing + blog).
Build times aren't painful yet, but I've noticed the same pattern:
most of the build time is Next.js doing things I didn't ask for.
For a mostly-static marketing site it's tolerable, but I can see
how it becomes a dealbreaker for a rich client-side app like Railway's
dashboard.
Curious — after the migration, did you see any measurable difference
in runtime performance (TTFB, hydration) or was the win purely
on the build/DX side?
I just tried their domains page it took 10.8MB of data and took 2s for the DOM to be ready.
page actually took 17s to fully render with multiple shift changes.
all to render a domain search bar similar to google home page.
https://railway.com/domains
web dev is a sewer
All my projects are server rendered with jinja/minijinja, bootstrap, jQuery, and htmx when I need a little bit of SPA behavior on forms.
No builds, just static <script src= tags. Very fast and easy. I'll never recommend anything else.
I'm coming back to Django after a decade of experience with it post-0.96 and having moved to Next.js a few years ago. Going from 1,700 dependencies to 65 total with Django + Wagtail + HTMX.
When I am given the choice to pick a stack, it is classical Java and .NET Web frameworks, with minimal JavaScript.
On hobby projects same script approach without any kind of build step.
With C#'s Blazor templating, you can ditch all JS logic, and use raw C# for all front-end logic, and have it all be transparently server rendered similar to how Phoenix has LiveView.
I also have experimented with HTMX and Django, and that seems to be a nice combination.
Everything is AJAX again.
There are some easy optimizations wins for this page but none of the top ones are framework related. Maybe with the faster build times they can easily optimize images and 3rd party dependencies. As someone else pointed out, nearly half that data is unoptimized images.
For the curious, google's current homepage is a 200kb payload all in, or about 50 times smaller.
Who remembers sprite sheets? Does that give my age away?
I did an optimization pass for a client once where I got rid of a ton of the sprites but didn't have the energy to redo it all, so it just had huge sections that were blank.
Super snappy loading afterwards though.
1 reply →
Dear lord. It's actually laggy for me to scroll on that page.
same here and I'm using a beefy MacBook (Apple M4 Max, 64gb ram). something is wrong with the front end code. there are a lot of animations, so my hunch would be that something goes wrong there.
The 3.57MB background PNG is hilarious [0]
[0] https://railway.com/dots-oxipng.png
They could have saved themselves 3MB by converting it to AVIF.
Ha! I normally wouldn’t find it quite so hilarious, but it’s a stylistically pixelated image. There’s just too much irony packed in there to not chuckle.
I migrated the landing pages for my app[1] from Nextjs to Astrojs mainly because I was paying Vercel $20 per month for serving static pages(it’s 4 times more than I pay Railway for the Postgres database for the actual app and also 4 times more than I pay Cloudflare for hosting all my apps). I used AI for migrating and it took a few days only as the existing repo was used as “instructions” and it included some upgrades and improvements here and there.
[1]: https://www.sqlai.ai/
Why is everyone so afraid to get a $5/mo Ubuntu/Debian VPS, install nginx and call it a day?
Then you can even run multiple projects off the same server.
It means you take responsibility of maintaining the server forever, i.e. dealing with TLS certificates, SSH keys, security updates, OS/package updates, monitoring, reboots when stuck, redeploy when VPS retired, etc. Usually things work fine for a year or two and then stuff starts to get old and need attention and eat your time.
1 reply →
No click-ops that way.
I just did this over at Hetzner and Claude admins it for me so I don't need to learn the CLI or anything, describe the proxying I want, and it setups up a bunch of small side project pages for me.
1 reply →
this is neat
We went through a very similar migration. Had a Next.js landing page and a separate TanStack Router SPA - consolidated both into a single Vite + TanStack Start app. Same experience with build times and the architecture mismatch: our app is heavily client-side with real-time state, and fighting Next.js's server-first assumptions wasn't worth it. TanStack Router's type-safe routing and file-based route generation have been great.
I hadn't heard of TanStack but a quick look at their website doesn't inspire confidence tbh. I mean, just take "TanStack Pacer".
It provides such things as:
```
import { Debouncer } from '@tanstack/pacer' // class
const debouncer = new Debouncer(fn, options)
debouncer.maybeExecute(args) // execute the debounced function
debouncer.cancel() // cancel the debounced function
debouncer.flush() // flush the debounced function
```
Why? Just why do you need to install some "framwork" for implement debouncing? Isn't this sort of absurdism the reason why the node ecosystem is so insecure and vulnerable in the first place? Just write a simple debouncer using vanilla js...
Obviously it's more than just debouncing. https://tanstack.com/pacer/latest/docs/overview
Two minutes is still way too long. What are we doing? This is ridiculous.
2 mins for a production deploy of an app with millions of users? Seems fine to me! How fast would you expect it to be?
How does an apps user base affect its build time?
We're doing structural type checking for a language that wasn't developed with that in mind.
I have a Nextjs heavy app which takes around 7 minutes currently. But I've been thinking of moving away from next for a long time now. TanStack seems to be a good fit. This gives me a bit more confidence in just doing it.
Is server-rendered HTML that bad for 2026 web or is everyone building complex apps?
Many of my customers insists on using Next.js or similar but when I browse their website I don't get the point. They are downloading and executing megabytes of JS while in-page interactions tends to be limited to few basic stuff. Never seen one of their project requiring offline mode. Maybe that's being able to easily replace a [FRAMEWORK] dev with another.
It is fashionable, and Vercel has made a chain of partners that make Next.js/React the only official option to extend SaaS products.
I think the unfortunate truth is the simplest. Web development has long been detached from rationality. People are drawn to complexity like moths to a flame.
I made two serious attempts to get into front end web development, around 5 years apart. Both times I started with the most popular framework. Both times the most popular framework was something different before I even finished the project.
Looks like maybe things haven't changed much?
As a cpp developer I had to chuckle there. And I thought our compile times were bad.
I've been pretty happy with TanStack start for a medium-sized project. I would not know how its build time would compare to Next, but our similarly sized Remix (sorry, React router v7) app takes longer to build.
TanStack just has a nicer mental model overall and works great with TanStack query for cache I validation and stuff like that.
Remix was promising but there was so much ceremony in registering API routes and stuff. Tanstack just lets you define server functions arbitrarily with no ceremony.
Might be worth a spike and some tokens to ask Claude Code to migrate and test the build time and ergonomics.
I've been on the remix on a previous project, I have to say that Remix was even worse. But that's probably of the setup with vite etc not being correctly done.
Are you on turbopack? It's available on Next 16 and just took our build times down from 6 minutes to 2 minutes
Yep this is what's often misunderstood.
We also recently cut our build times in half moving from Webpack to Turbopack on production builds after jumping to NextJS 16. We'd already been using Turbopack in development for a while which yielded massive DX improvements related to performance. Production build times will drop further once Turbopack production build caching is stable.
Webpack -> Turbopack is the smart initial migration. I'd bet Railway went straight from Webpack -> Vite not realising that their real gains sat with the build tooling, not NextJS vs Tanstack.
Yes I'm on turbopack and running the latest version of Nextjs.
A lot of the LLMs are very familiar with next.js and vercel is also aggressively building an ecosystem around their tooling for LLMs. So I wonder if this problem will only be exacerbated when everyone using LLMs is strongly nudged (forced) to use next?
When you create a Next.js project from Vercel's template, you get an AGENTS.md that literally says "THIS IS NOT THE NEXT.JS YOU KNOW"
Is that because LLMs default to the older pages router? Or are they actually providing a different version of the library optimised in some way for agents?
3 replies →
We've had shitty bloated websites before LLMs were a thing.
The irony is deploying NextJS on the railway platform is super slow since they use containers, on Vercel 2 min is like 12 min on railway, deployments on a vps are only like 20 seconds.
*I know this is just build time, so this is different then their deployement time
Not containers to blame but overprovisioning and how much resources dedicated to building. I am not sure how Vercel gets things build in literal seconds, but, hey, they are the creators of NextJS.
At DollarDeploy we building it also in containers but every build get 4GB/2CPU so it is quite fast but not as fast as Vercel.
Turbopack, custom runtime infrastructure on top of AWS Lambda.
Incredible that the builds were ever 10min. How far things have regressed.
Time to move your blog off Next too? It’s slow as molasses for me, loads a billion JS chunks and JSON fragments, when it can be a static site.
This is the kind of post I wish more teams would write. The "we picked the popular thing and it got slow" story is so common. But most teams just live with it. They don't want to touch it. 10 minutes to 2 minutes is huge for dev speed!
I'm a huge fan of tanstack start especially the ability to just static prerender some paths (a feature I'm missing a ton with astro) For me tanstack start is the new dominator on the stack!
We made a similar move from Next.js to Vite (with Tanstack router): CI build dropped from 12 min to barely 2 min. We won't look back.
Can we just get back to html/jQuery/handlebars? Those were the good old days :`(
:suprised_pikachu_face:
Is the quality of software engineers really dropped that low that people get excited when they move off from "heavy bloated" frameworks to lighter alternatives? Or is this just SEO farming garbage to position the company higher in search results?
Both can be true at the same time!
They don't even mention the Next.js version used - where they using Turbopack or not?
excellent question - recently switched from turbopack after getting annoyed by build times. we saw them go from 6 mins to 2 mins
Zero references to Turbopack, maybe start there?
Reminder, as its not mentioned:
Next.js is produced by Vercel, a competitor to Railway.
Moving to vite + tanstack builds faster is also a fact.
Only if they weren't using Turbopack.
2 replies →
True. That framework is owned by a cloud company and the way they host Next.js apps in a secure and scalable way remains secret sauce.
Now it doesn't really impact build time and Railway offers Next.js hosting.
It's not mentioned because it's not relevant.
Of course it should be mentioned, it's a basic disclaimer.
I don't know the situation now, but a while ago there were a lot of pushback using Next.js because it was not easy to use all features if not hosted on Vercel.
2 replies →
This is one of the most frustrating thing about working with NextJS. There seems to be no way to improve the speed of building the app.
I've used the other major meta frameworks (remix and tanstack). I don't think there is a way to improve the speed of building the app in those ecosystems. Happy to be proven wrong.
Anyone tried to use vinext from Cloudflare in production? Might be faster.
But seriously, not sure why NextJS builds take so much, we are using stable and functional pages router in DollarDeploy and it is still takes too much time to build.
Wait till you use HTMX!
As in, htmx is better? I haven't used it but last I looked into it I was extremely confused as to whether it was a meme, an actual framework, or both.
HTMX is great when your web interface is just a representation of a server state.
If web interface is an application backed by a remote state HTMX falls apart.
None of the above. It is a utility (I guess framework maybe) for a feature that was cool in ASP.NET back in 2005. But that is it's charm. It is just JS swapping out the dom for you.
1 reply →
It’s absolutely mind boggling to me that we have gotten to a point that building a web frontend takes longer than compiling the Linux kernel..
As a non-frontend developer mainly observing and touching something here and there, a lot of the things that frontend developers do seem vastly over-engineered.
I'm not insanely deep into frontend, I mostly just pick up React and call it a day, but it seems like this is also over-engineered?
I've seen vanilla JS before, and I just know I wouldn't want to do the housekeeping that comes with it. People claim it's less work because it' simpler, but I fully expect myself to rewrite the thing at least twice, only to give up because I have no actual mental model anymore of how it works.
2 replies →
Isn't the main problem that the building blocks the modern web is based on are not a good fit for what we do with it?
CSS is a total mess. HTML is a mess. JS is okay, but is not a high quality language.
We would save so much time and money if we would have a modern base to build on. Sadly this will probably never happen, because company interests will try to corrupt the process and therefore destroy it.
5 replies →
This is my understanding too - tools like react are like microservices - they’re a technical solution to an organisational problem. HTML/css/JavaScript is an imperfect abstraction, so we got bootstrap. Then we got client side frameworks which introduced a build step, and then we got asset bundles, optimisers, linters, validators, tree shakers, package managers, validators for your package managers. All of these monkey patched around the actual problem with more abstractions, and the end result is what we have now.
Not that backend is any better - microservices everywhere, must scale to Facebook traffic even if we only have 10 customers, etc. Saying this as a backend dev
Like using SPAs for classical Web development, and then they rediscover PHP.
It’s mind blowing when you check the generated code, because it goes over 50 elements deep for a simple looking website.
Makes me think that there’s no way this is computationally efficient either.
2 replies →
And underenginered at the same time !
Same reason why 90% of websites have serious UX issues and constant bugs. This and ad frameworks.
C is infinitely less complex to parse and validate than Typescript. C is compiled in a single pass, the `tsc` type checking algorithm has to check structural typing, conditional types and deep generics while also emulating JS' dynamic behaviour.
I don't think any C compiler has been single pass for the last 20 years. Typescript's analyses are also not that complicated, it's just that the typescript type checker is written in js. Iirc the actual ts -> js part is pretty fast with some of the more recent compilers.
That's not the point...
I disagree - this is an excuse. Even the post we’re commenting in now shows that it’s a series of poor abstractions and bad tooling that takes way too long to do the basics, combined with a language and ecosystem that encourages this behaviour . They saw a 5x speed up by changing tools while still using a JavaScript framework so it’s clearly possible for it to not be complete nonsense.
[dead]
[dead]
The two-PR strategy is smart — decouple from the framework first, then swap it. That's the kind of migration discipline most teams skip, and it's why they end up running two systems in parallel for months.
I run a Next.js App Router site in production (marketing + blog). Build times aren't painful yet, but I've noticed the same pattern: most of the build time is Next.js doing things I didn't ask for. For a mostly-static marketing site it's tolerable, but I can see how it becomes a dealbreaker for a rich client-side app like Railway's dashboard.
Curious — after the migration, did you see any measurable difference in runtime performance (TTFB, hydration) or was the win purely on the build/DX side?