page actually took 17s to fully render with multiple shift changes.
all to render a domain search bar similar to google home page.
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.
On hobby projects same script approach without any kind of build step.
I also have experimented with HTMX and Django, and that seems to be a nice combination.
Everything is AJAX again.
For the curious, google's current homepage is a 200kb payload all in, or about 50 times smaller.
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.
Then you can even run multiple projects off the same server.
It's way way way way easier managing a basic VPS that can be highly performant for your needs. If this was 2010, I'd agree with you but tooling and practices have gotten so much better over the last decade (especially the last 5 years).
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...
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.
Looks like maybe things haven't changed much?
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.
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.
[0]: https://nextjs.org/docs/app/guides/ai-agents#how-it-works
At times I would see people daily asking for help with their broken Tailwind setups, and almost always it was them trying to use Tailwind v4 the v3 way because some AI told them so.
*I know this is just build time, so this is different then their deployement time
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.
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?
Next.js is produced by Vercel, a competitor to Railway.
Note how many HNers are making the same remark.
Now it doesn't really impact build time and Railway offers Next.js hosting.
Anyway, my point is that no one is forced to use NextJS and if they like NextJS but not Vercel they can always fork it or, apparently write an adapter.
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.
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.
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.
Same for HTML. If the web would be reimagined today, there is a very low chance that we would create HTML as is.
second biggest problem is "no stricter mode". so even wrong or useless html/css code goes unflagged and is treated as it is normal.
CSS is way too powerful.
https://csszengarden.com/pages/alldesigns/
That statement wasn't true ages ago, and it's even less true now.
Makes me think that there’s no way this is computationally efficient either.
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?
