🧠 Some brief thoughts on front-end frameworks and upgrade hell: csswizardry.com/2025/01/buil... - ThreadSky

csswizardry.com • 100 days ago

🧠 Some brief thoughts on front-end frameworks and upgrade hell:
https://csswizardry.com/2025/01/build-for-the-web-build-on-the-web-build-with-the-web/

Comments

stefanjudis.com•100 days ago

Was hoping you'll turn this one linked post into something real. 💯

joebell.studio•98 days ago

Let me guess, were those clients upgrading to the Next.js App Router?

Gone through this exact migration path 3 times now — never again

josephscott.bsky.social•99 days ago

This is a surprisingly difficult message to get across today. One approach I tried was to encourage thinking in 20 year increments. In the next 20 year cycle, how much time do you want to devote to fixing/speedingup/updating/replacing your front end frame work?

alexsuzuki.com•99 days ago

I‘m planning to migrate some Angular SPAs to more „bare bones“ tech, but not sure if I can get by with just plain JS or if it‘s too cumbersome. I‘m thinking maybe TS for type safety and htmx for navigation/DOM replacement. Do you have a recommended stack?

deanleigh.bsky.social•100 days ago

We seem to live in a world where every new hire brings a new framework. I shouldn't complain as untangling overcomplicated builds has kept me employed for the best part of 28 years, but I take no pleasure seeing peoples pain trying to manage these projects.

olivierforget.net•100 days ago

We need a new generation of tooling that helps build things *with* the browser, instead of frameworks that stand between the browser and the developer.

shearer.co•97 days ago

Exactly this. I think the reason a good chunk of people reach for JS frameworks might not even be for the navigation transitions or whatever but for the developer ergonomics instead.

shearer.co•97 days ago

Being able to set up and deploy a site with routing, components, PostCSS, server middleware etc etc in a matter of seconds is too easy with things like Next.js etc. I am guilty of this.

olivierforget.net•97 days ago

Agreed. For me it's the excellent experience of the dev-server proxy I get when I work on a Vue SPA. Having my changes to components and CSS reflected immediately after I save is fantastic. This from @chriscoyier.net comes to mind (https://chriscoyier.net/2024/11/07/designing-dx/)

olivierforget.net•97 days ago

There are some backend templating engines that try to do live reload, but I don't think it's as easy or as slick as a pure frontend devserver.

https://templ.guide/developer-tools/live-reload

And it's Go-only. Once you start using a backend language, you split the world up, and each has to re-implement these niceties

shearer.co•97 days ago

Hah funny you should suggest that: https://github.com/maxshearer/max.shearer.co

shaneosbourne.bsky.social•100 days ago

I also wrote about this idea - where being leaner is a good long-term strategy https://shane-o.dev/articles/introducing-tru

velvetcladgeometro.bsky.social•99 days ago

Good read. Even without doing a lot of the “fancy” things you mentioned (page transitions), the (react) upgrade cycle is a bear across our many micro frontends. Ultimately our refactors have been a net benefit, but the npm ecosystem + renovate bots means constant maintenance PR’s.

aerotwist.com•100 days ago

Super post. I've held similar views for a long time, but it can be hard to plan for the longer term if incentives are set for the shorter term and if planning for the longer term runs the seeming risk of over-engineering.

csswizardry.com•100 days ago

Agreed. And my advice there is generally ‘make decisions you can easily change or undo’. You don’t need to have all the answers now, but you do need to remain adaptable.

Comments

Posting Rules

Reply