llm/5888b8dc-b96e-4444-9c3c-465dde409e92/topic-10-2c5154c3-cde4-465e-85d3-3a70f064481b-input.json
You are a comment summarizer. Given a topic and a list of comments tagged with that topic, write a single paragraph summarizing the key points and perspectives expressed in the comments. TOPIC: Frontend framework fatigue COMMENTS: 1. I feel like we are just covering whataboutism tropes now. You can absolutely learn from an LLM. Sometimes.documentation sucks and the LLM has learned how to put stuff together feom examples found in unusual places, and it works, and shows what the documentation failed to demonstrate. And with the people above, I agree - sometimes the fun is in the end process, and sometimes it is just filling in the complexity we do not have time or capacity to grab. I for one just cannot keep up with front end development. Its an insurmountable nightmare of epic proportions. Im pretty skilled at my back end deep dive data and connecting APIs, however. So - AI to help put together a coherent interface over my connectors, and off we go for my side project. It doesnt need to be SOC2 compliant and OWASP proof, nor does it need ISO27001 compliance testing, because after all this is just for fun, for me. 2. > they've stolen a mountain of information In law, training is not itself theft. Pirating books for any reason including training is still a copyright violation, but the judges ruled specifically that the training on data lawfully obtained was not itself an offence. Cloudfare has to block so many more bots now precisely because crawling the public, free-to-everyone, internet is legally not theft. (And indeed would struggle to be, given all search engines have for a long time been doing just that). > As the arms race continues AI DDoS bots will have less and less recent "training" material My experience as a human is that humans keep re-inventing the wheel, and if they instead re-read the solutions from even just 5 years earlier (or 10, or 15, or 20…) we'd have simpler code and tools that did all we wanted already. For example, "making a UI" peaked sometime between the late 90s and mid 2010s with WYSIWYG tools like Visual Basic (and the mac equivalent now known as Xojo) and Dreamweaver, and then in the final part of that a few good years where Interface Builder finally wasn't sucking on Xcode. And then everyone on the web went for React and Apple made SwiftUI with a preview mode that kept crashing. If LLMs had come before reactive UI, we'd have non-reactive alternatives that would probably suck less than all the weird things I keep seeing from reactive UIs. 3. I don't want to waste time learning how to install and configure ephemeral tools that will be obsolete before I ever need to use them again. 4. Exactly, the whole point is it wouldn’t take 30 minutes (more like 3 hours) if the tooling didn’t change all the fucking time. And if the ecosystem wasn’t a house of cards 8 layers of json configuration tall. Instead you’d learn it, remember it, and it would be useful next time. But it’s not. 5. The problem with modern web development is that if you're not already doing it everyday, climbing the tree of dependencies just to get to the point where you have something show up on screen can be exhausting, and can take several of those half hour sessions. 6. The good thing about AI is that it knows all the hundreds of little libraries that keep popping up every few days like a never-ending stream. No longer I need to worry about learning about this stuff, I can just ask the AI what libraries to use for something and it will bring up these dependencies and provide sample code to use them. I don't like AI for coding real algorithms, but I love the fact that I don't need to worry about the myriad of libraries that you had to keep up with until recently. 7. I'll sometimes ask Claude Sonnet 4.5 for JS and TS library recommendations. Not for "latest" or "most popular". For this case, it seems to love recommending promising-looking code from repos released two months ago with like 63 stars. 8. > On the frontend, you have build pipelines, bundlers, CSS frameworks with their own toolchains, progressive web apps, Core Web Vitals, SEO, layout shifts, srcset/responsive images… I remember when the biggest challenge was IE6 compatibility. You only have those things if you choose to use them. I've been building websites for 25 years. I use the same core technologies today that I did when I started. Sure, I make use of modern improvements to the languages themselves, but I have never permanently adopted any of the "hot new trends" and feel I am better - or at least saner - for it. No, your marketing or e-commerce website almost certainly doesn't need a JS bundling toolchain. It almost certainly doesn't need a CSS preprocessor or even a CSS boilerplate/framework. It almost certainly doesn't need an enterprise-class PHP framework; or a dependency manager; or a CI/CD pipeline. 9. > you need fancy tooling to ensure everyone can work at a reasonable level of productivity. If you have a thousand people working on a single product, yes, but you also have the resources to have dedicated tool support teams at that level. In my experience, if you’re under multiple dozens of developers or not everyone works on all of your projects, the tools fragment because people aren’t combining or configuring them the same way and there’s enough churn in the front-end tool space that you’ll hit various compatibility issues which lower the effectiveness of sharing across projects. This is especially true if you’ve hired people who self-identify as, say, Next or Tailwind developers rather than web developers and lack the understanding of the underlying technology to fix complex problems. 10. > build pipelines, bundlers, CSS frameworks with their own toolchains, progressive web apps, Core Web Vitals, SEO, layout shifts, srcset/responsive images Build pipelines are purely a technical decision. Bundlers are purely a technical decision (TBH, a non-brainer if you decide to have a build pipeline, but it's not an organizational helper). Those help one do some things, not several people to organize. I'm still waiting for any person to claim they made CSS maintainable by adopting a framework. It's an almost purely organizational decision with no upsides at all. PWAs are a product decision, not technical or organizational. The same applies to Core Web Vitals, SEO, layout shifts and srcset, those are all product decisions. You can escape the technical and organizational decisions. You can't escape the product ones. 11. This is why web development stopped being fun: developers that cannot manage or train people and instead hope garbage like jQuery will simply act as a surrogate parent. 12. I used to think the same about server-side rendering until I more closely looked at React SSR. I think it makes a lot of sense and allows for faster initial rendering of the page while automatically setting up the JS and interactivity in the background. 13. React has always supported server-side rendering and there have been many tools over the years to "rehydrate" data from the server to the client for when the client-side React application "takes over". 14. Couldn't you just static render the parts that you're using SSR for? I am not trying to be dismissive, but a common strict requirement is static hosting from a CDN, embedded environments, etc. 15. If you static render, it won't be an interactive application. With React SSR you get the best of both: stream static HTML chunks immediately, and rehydrate with JS later, prioritizing components the user interacts with. It should load quicker compared to traditional React apps where the browser loads the HTML, then loads the JS bundle, and only then renders a loading skeleton while likely triggering more requests for data. 16. > It should load quicker compared to traditional React apps where the browser loads the HTML, then loads the JS bundle, and only then renders a loading skeleton while likely triggering more requests for data. Then your JS bundle is broken. Promises exist. Modules exist. HTTP/2+ exists. You can load data while you are loading a small amount of JS required to render that data while you are loading other parts of your JS. If everything is sequential: load giant JS bundle -> fetch -> render, that's because someone architected it like that. Browsers give you all the tools you need to load in parallel, if you don't use them then it's not the browser's fault. You do not need SSR or rehydration. That's just Vercel propaganda. They saw that people are doing a stupid thing and decided to push a complex solution to it. Why? It makes them money. 17. You cannot load any data in a regular React application before you loaded both React and your React components that trigger the fetch. If you use code splitting, your initial bundle size can be smaller, yes. That's about it. I guess in theory you can hack together static loading skeletons that you then remove when React loaded your initial bundle, but that's certainly far from a common approach. By that standard, the vast majority of JS bundles would be "broken". 18. You seem to be confused about your terms, both SSR and SSG can rehydrate and become interactive, you only need SSR if you have personalized content that must be fetched on an actual user request, and with frameworks like astro introducing island concept it even let's you mix SSG and SSR content on a single page. 19. That depends on how you interpret "static render". I did not interpret that as React SSG. SSG is the default behavior of NextJS unless you dynamically fetch data, turning it into SSR automatically. What I thought of is React's "renderToString()" at build time which will produce static HTML with event handlers stripped, in preparation for a later "hydrateRoot()" on the client side. 20. Static rendering has nothing to do with interactivity in a web app. I guess if you're already so deeply entrenched in writing all your application logic on the server side you need React SSR, but that sounds miserable. 21. On the frontend, you have build pipelines, bundlers, CSS frameworks with their own toolchains, progressive web apps, Core Web Vitals, SEO, layout shifts, srcset/responsive images… I've been making web stuff for a similar length of time as Mattias by the sounds of it. I started with Perl but moved to PHP 4 pretty soon after. I recognise this problem but I have different take. All the complexity was there 20 years ago, but we ignored it. That doesn't mean it was simpler. It just means we took crazy (with hindsight) risks. Sure, there were no build pipelines like today, but we had scripts we ran to build things. There was Adobe Pagemill for making site wide changes before we deployed a new version. Back in the day we made those changes, did a very brief check that things worked locally, and then manually FTP'd files to a server, breaking it in the process because a user would see the site change as they navigated. Some of us would put up a maintenance page during an update effectively just blocking all the traffic. That's certainly 'simpler', but it's also much worse for the user, and on a site that did things with data potentially risked corrupting a user's records. It was incredible that things didn't break more often. Maybe they did and we just never realised. We didn't have CSS frameworks but we certainly did have our own in-house templates, and they had separate toolchains. As time went on that toolchain mostly migrated to Wordpress and it's template builder plugins. Again, give me Tailwind over that mess. We had Core Web Vitals and SEO in the form of Urchin Stats. We had layout shift but we called it FOUC. We had kind of had srcset, but it was implemented as a set of Macromedia Dreamweaver mm_ JS image preload and swapping functions. <picture> is a lot nicer. Things are just better now. Writing web software is loads of fun. I also leverage LLMs in my code because they're awesome, but not to simplify things. I don't think the complexity is new. I just think it's visible now. 22. > On the frontend, you have build pipelines, bundlers, CSS frameworks with their own toolchains, progressive web apps, Core Web Vitals, SEO, layout shifts, srcset/responsive images… LLMs are successful in webdev because of unnecessary frameworks being piled on top of each other more in the name of job security than technical necessity. 23. Those things exist because of eachother. If you’re not using a reactive framework, you probably have no need for a bundler and if you’re not using a bundler, you probably have no need for a build pipeline. 24. Ironically I'm thinking the exact opposite. Now I can build stuff without dealing with the chaos in the frontend frameworks ecosystem... 25. Maybe it's just me, but the idea that the average web project out there is a complicated mess and thank God we have AI so we can finally think about the things that matter while AI deals with the mess... it makes me sad. 26. To me, what sucks the most about programming is dealing with ecosystem issues. You want to write a little tool for personal use, but NPM starts acting out. Then you need to do something in java, which you don't use very often, and you get a giant maven error stack trace which you now need to try to understand. All of this frustration is gone since I use AI and I can focus solely on the thing I'm trying to accomplish. 27. Before I clicked on this I was optimistic and thought this was going to be about how we've turned a corner and the web stack pendulum is now swinging back to the easier days before frontend frameworks. 28. > On the frontend, you have build pipelines, bundlers, CSS frameworks with their own toolchains, progressive web apps, Core Web Vitals, SEO, layout shifts, srcset/responsive images… I remember when the biggest challenge was IE6 compatibility. I know which I'd choose. In my experience of the IE6 era, tooling was atrocious, and most (all?) cross-browser testing was manual. Varying box models and no devtools? Give me npm framework churn and layers of transpilation any day. 29. Strong agree. The modern web world is clearly better but we traded a whole lot of complexity for a little bit of benefit (and frequently regressed on speed). The microservices and javascript framework wars were the dark ages. 30. it is fun again because we can remove ourselves completely from it? seems like web enthusiast are always the first to drop ship huh. "llms good because I no longer have to interface with this steaming pile of shit that web development has become", not because the web ecosystem has improved by any metric. 31. But what if it isn't just a basic website? Most sites I've worked on required things like content management, or auditing stuff, a bunch database stuff, SAML single sign on etc. Most languages end up being better at some parts of the stack, like Java for overcomplicated enterprise BS backends. It seems bad to "fight" that trend. 32. Couldn’t agree more. Changing anything in oUR react Bootstrap frontend was a visit to the dentist. But Llms really lowered the pain. 33. There’s also change over time to consider: web programming has become immensely more stable and simpler and more mature over time, thereby enabling classes of application and experience that traditionally meant a client application to be built on the web, hence modern web app development becoming a complex and complicated morass. Facebook and others have delivered a bunch of cross platform shizz that really should be baked into the desktop and mobile OS itself, moving complexity up the stack. Microsoft Office uses React, to highlight the issue. We’ve spent decades chasing the basics of fat client development and doing it in JavaScript. 34. please, developers are making terrible slop way before AI, look at the javascript infested frameworks in use on the web. they make NO sense. they are not making things simpler 35. And now you can generate javascript infested slop frameworks for $5 per million tokens. Such an improvement. And it's so easy to just ask Claude to make one for you, why even bother standardizing anything when you can just use bespoke slop for anything anymore. Libraries and frameworks? Not needed. Just shove everything into CC/Codex and let it figure it out. 36. The financial incentives of the Chatbots are always going to push people towards increased complexity, as well. The tendency will be for frameworks to become more complex, which will lead to increased LLM use, which will increase complexity. 37. That actually might be an improvement over the JS frameworks... Write a concise, engaging paragraph (3-5 sentences) that captures the main ideas, notable perspectives, and overall sentiment of these comments regarding the topic. Focus on the most interesting and representative viewpoints. Do not use bullet points or lists - write flowing prose.
Frontend framework fatigue
37