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.
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.
Sounds more difficult then modern web frameworks. We've all done this for little projects, but anything with users or development teams, your method is DOA.
I disagree, most webapps, like 99.9% I would say, are just forms, links, and pages. Meaning, they can be done with 0 reactivity and that is the most simple and straightforward way to do it.
Less code is basically always better, so if you can skip the huge amounts of JS and orchestration required by modern web frameworks, then it will be easy. People are out here using React to render static pages. It's very overkill.
Eh, there’s tradeoffs. They’re real. But I’ve done plenty of this on teams back in the day before all these frameworks and it can absolutely work. It may even be easier now with JS modules.
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.
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.
It's more halftone (might not be the correct term), not pixelated
There might be more irony in saying it's stylized pixels without realizing that the style of the image can't be replicated with blocks of the same size but I dunno, I'm not Alanis Morissette
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.
just ask claude to do all that :), he is excellent and installing & managing new servers and making sure all security patches are updated. Just be careful if its a high risk project.
I really doubt that people who can’t install an ssh key should be able to practice software engineering. Sometimes, I think that software engineering should be a protected profession like other types of engineering. At least it will filter out the people who can’t keep their OS up to date.
This is not about how easy or difficult it is to issue TLS certificates, to configure SSH keys or to update the OS. It's about having to actively maintain them yourself in every possible situation until eternity, like when TLS versions are deprecated, SSH key algorithms are quantum-hacked, backward-incompatible new OS LTS versions are released, and so on. You will always have new stuff come up that you need to take care of.
Exactly. Also, being that my specialty is writing software and not server maintenance, no matter how much of an effort I put forth there's substantial risk of blind spots where holes can lurk.
I felt more comfortable maintaining a VPS back between 2005 and 2015, but at that point attackers were dramatically less sophisticated and numerous and I was a lot more overconfident/naive. At least for solo operations I'm now inclined to use a PaaS… the exception to that is if said operation is my full time job (giving me ample time to make sure all bases are covered for keeping the VPS secure) or it's grown enough that I can justify hiring somebody to tend to it.
They shouldn't, that's why self hosted PaaS already do it for you, it's not a differential reason to use cloud services instead just because they do it for you too.
When buying the infrastructure as a managed cloud service, yes, I trust that they've got people handling it better than I could myself. The value proposition is that I don't even see the underlying infrastructure below a certain level, and they take care of it.
This is extremely easy with tools like dokploy tho... I use dokploy locally to manage all my VPSs + home server. Truly good stuff and I don't believe your quip at the end, it feels like poisoning the open source waters for consolidated anti democratic cloud platforms.
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).
Maybe you're right - I've never tried dokploy, but from documentation it sounds like mostly a deployment, monitoring and alerting tool. For me the problem has always been that once you get the alert (or something just stops working), a human needs to react to it and make things work again. In cloud services you mostly pay for them providing the human, and in self-hosting you're the human.
I can see though that today's AI models could eventually replace the human in the loop and truly automatically fix every possible situation.
yeah i've had more downtime on managed db's & cloud servers then on my own managed VPS. And if it happens, with VPS i can normally fix it instantly compared to waiting 20-60 min for a response, just to let you know they start fixing it. And when they fix it, it doesnt always mean your instance automatically works.
You might be right. I've been mostly using serverless / managed cloud services such as AWS Lambda, API Gateway, S3, DynamoDB for the past 10+ years. When I've needed to respond, it's been because I myself deployed a bad update and needed to roll it back, or a third party integration broke. The cloud platform itself has been very stable, and during the couple of bigger incidents that have happened, I've just waited for AWS to fix it and for things to start working again.
IDK, I only found out about Dokploy six months ago. The tool for managing small hosted solutions is absolutely amazing. You can do a lot with a single VPS if you avoid bloated software choices.
People often forget there is a massive economy out there for niche solutions and if you're a small team you don't exactly need a large slice to make a nice life for yourself.
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...
Not to feed the trolls, but you responded to a comment about TanStack Start (a full-stack metaframework) by denigrating @tanstack/pacer -- a separate, niche utility published by the same team.
You're entitled to your opinions, but I'm happy to defend the rationale of leveraging battle-hardened, rigorously-tested, open-source, type-safe libraries instead of DIY cowboy vanilla js spaghetti.
TanStack started out by providing a very good JS table library. Now they offer a Router, and some more libs. They are definitely an up and coming name in the JS space.
TanStack Query is the relatively newer name for React Query -- one of the most popular JS libraries of all time.
TanStack Start is a recent metaframework (and the one w/ the brightest future, IMO), but Tanner and team have profoundly significant bona fides. IOW, the dev team is far from being the "new kids on the block".
Thank you, but no.
I typed "Router" when I meant "Query". TanStack Query is the newer name for the library FKA react-query.
TanStack Router is an alternative to React Router.
TanStack Start is an alternative to Remix/react-router-7's framework mode.
The naming history and evolution of react-router and its relationship to Remix is a bit convoluted, but an unrelated tangent to the point I was making.
Moved our Midas dashboard from Next.js to static HTML on Cloudflare Pages for similar reasons. Build times went from minutes to under 2 seconds. For content-heavy sites that do not need SSR, the complexity tax of a full framework is hard to justify once you measure what you are actually paying in build time and deployment friction.
One way to think about it might be that the site supports lots of users who use it for various things. So, everyone uses 80% of the site, but everyone also uses a different portion of the final 20%. So, if you have lots of users, you might also have lots of smaller features that a significant minority use.
I don't know, just an interesting way of thinking about it.
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.
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.
> People are drawn to complexity like moths to a flame.
Not to complexity, but to abstraction. The more something is abstracted away, the more fungible "developers" become, to the eventual tune of Claude Code.
No one cares that trying to debug a modern application is as hellish as its performance, the KPI that executives go for is employment budget.
I don't know if Next.js, TanStack, etc are more abstract than Rails, Django, etc. They're undoubtedly more complex though. I also find it hard to believe that it's some sort of conspiracy by management to make developers more fungible. I've seen plenty of developers choose complexity with no outside pressure.
I recently switched from NextJS — where every one of the dozens of projects I built would have 7-8 minute deployment times, regardless of hosts — to React Router, and saw my deployment times drop to 1-2 minutes.
Aside from some difficulty with mastering environment variables, I’ve been delighted with the change and will probably not look back.
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?
I think they just want LLMs to read the docs they began shipping[0] along with the library instead of using their own knowledge. For example, when I used Next.js a few months ago, models kept using cookies() and headers() without await, because that's how older Next.js versions worked, but modern Next.js requires await. I imagine there are more cases like this.
One rather prominent case would be Tailwind. v4 made breaking changes in the way Tailwind is set up, requiring different packages and syntax. However, if you ask an LLM how to set up Tailwind on your Vite & React app, it will confidently list the setup steps for Tailwind v3, which no longer work.
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.
This was so unbelievably obnoxious when I first started trying to use Cursor last year at some point. Also because if you tried to not use tailwind the AI would eventually try to force it in anyway. I don’t know how it is nowadays but that was so frustrating and funny at the same time. And! When I setup Tailwind v4 ahead of time, got it working, and told the AI about the v4 changes, it would “correct” it to v3 anyway. Another fun “metric” was to ask an AI how to setup react because it was still recommending create-react-app though nowadays I’m sure it’ll be harder to find any model that still has that in its training set.
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'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.
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.
We used NextJS on a project hosted on AWS a while ago. We learned quickly it wasn't the best tool for what we wanted to do which is why we stopped using it. But it's an open source project whose purpose is to drive devs to Vercel. It doesn't surprise me that there are some features that work best with Vercel (but it does surprise me that only recently other providers started to need adapters).
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.
Besides the way it maps server side code into serverless, it has a custom runtime, functions that expose cloud infrastructure, integration with multiple language runtimes for the backend.
You get to pick Vercel + headless CMS + assets managed + eshop, and you're done in terms of big corporations.
Might seem a lot in licenses, however it allows for smaller dev teams, which is what management floor cares about, all those salaries.
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.
It's mostly because a lot of the web tooling is written in JavaScript. The build times for the "next generation" tools written in Rust/Go are dramatically faster.
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.
I have never in my career encountered a Vanilla JS project of at least medium size that I would have called simple. They all feature brittle selfmade frameworks whose developers have since left the company years ago.
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.
How are CSS and HTML a mess? Combined, they're an incredibly powerful layout engine that works almost the same across all environments and devices while also featuring easy accessibility.
When taking a bird eyes view on CSS it will be hard to oversee that CSS is a mixture of different concepts that evolved over time with a lot of inconsistentsies. It is possible to make it work, but it's not pretty.
Same for HTML. If the web would be reimagined today, there is a very low chance that we would create HTML as is.
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
Hard disagree. This is JavaScript frameworks building a hierarchy for themselves and ignoring any sort of complexity on the generated DOM. There’s 0 reason for these 8-10 nested divs other than that’s what the framework spits out.
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?
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
reply