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"
We moved Railway's frontend off Next.js. Builds went from 10+ mins to under 2
41–50 of 230 posts
Re: We moved Railway's frontend off Next.js. Builds went from 10+ mins to under 2
#42Re: We moved Railway's frontend off Next.js. Builds went from 10+ mins to under 2
#43A 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?
Re: We moved Railway's frontend off Next.js. Builds went from 10+ mins to under 2
#44Earlier quoted context omitted.
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.
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.
Re: We moved Railway's frontend off Next.js. Builds went from 10+ mins to under 2
#45Two minutes is still way too long. What are we doing? This is ridiculous.
Re: We moved Railway's frontend off Next.js. Builds went from 10+ mins to under 2
#46Re: We moved Railway's frontend off Next.js. Builds went from 10+ mins to under 2
#47Re: We moved Railway's frontend off Next.js. Builds went from 10+ mins to under 2
#48It’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.
Re: We moved Railway's frontend off Next.js. Builds went from 10+ mins to under 2
#49Earlier 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.
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
#50It’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.