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..
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.
We moved Railway's frontend off Next.js. Builds went from 10+ mins to under 2
61–70 of 230 posts
Re: We moved Railway's frontend off Next.js. Builds went from 10+ mins to under 2
#62Earlier quoted context omitted.
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.
the biggest problem with html/css is that they are tightly coupled. you can't meaningfully modify a layout with css alone. 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.
Re: We moved Railway's frontend off Next.js. Builds went from 10+ mins to under 2
#63Earlier quoted context omitted.
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.
Same for HTML. If the web would be reimagined today, there is a very low chance that we would create HTML as is.
Re: We moved Railway's frontend off Next.js. Builds went from 10+ mins to under 2
#64Re: We moved Railway's frontend off Next.js. Builds went from 10+ mins to under 2
#65It’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.
Re: We moved Railway's frontend off Next.js. Builds went from 10+ mins to under 2
#66Re: We moved Railway's frontend off Next.js. Builds went from 10+ mins to under 2
#67I 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.
Are you on turbopack? It's available on Next 16 and just took our build times down from 6 minutes to 2 minutes
Re: We moved Railway's frontend off Next.js. Builds went from 10+ mins to under 2
#68I 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.
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…
Re: We moved Railway's frontend off Next.js. Builds went from 10+ mins to under 2
#69I'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!
Re: We moved Railway's frontend off Next.js. Builds went from 10+ mins to under 2
#70Earlier quoted context omitted.
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. [0]: https://nextjs.org/docs/app/guides/ai-agents#how-it…
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.