The Frontend Treadmill
polotek.net
The Frontend Treadmill
1–10 of 722 posts
Re: The Frontend Treadmill
#2I have recently been doing some upgrades to the build system for our FE code to swap out yarn for pnpm. I’m normally a backend engineer, but I’ve spent plenty of time in the JS mines.
The most frustrating thing about dipping in to the FE is that it seems like literally everything is deprecated. Oh, you used the apollo CLI in 2022? Bam, deprecated, go learn how to use graphql-client or whatever, which has a totally different configuration and doesn’t support all the same options. Okay, so we just keep the old one and disable the node engine check in pnpm that makes it complain. Want to do a patch upgrade to some dependency? Hope you weren’t relying on any of its type signatures! Pin that as well, with a todo in the codebase hoping someone will update the signatures.
Finally get things running, watch the stream of hundreds of deprecation warnings fly by during the install. Eventually it builds, and I get the hell out of there.
It’s just nuts to me the degree to which FE development as a whole seems to embrace the breaking change, the deprecation, etc. I’ve been working on a large rust project for nearly four years and in that time there have been a few minor breaking changes in or of third party libraries, but only one major breaking change that required significant changes to our application. Meanwhile in JS it seems like you can’t go more than six months without having to rewrite something. It’s bananas.
Okay, rant over.
Re: The Frontend Treadmill
#3> But our current framework layer is working against the grain instead of embracing the platform.
Said the person with this bullshit in their page code, which will not deactivate when JavaScript fails to run:
body{visibility:hidden;opacity:0}
Re: The Frontend Treadmill
#4Based on the first paragraph alone, almost all devs I know think that a complete rewrite will solve all the issues, thats not only frontend but backend too.
Web development in its current form is a beast and if we want true change we need to fix the biggest issue there is for all of webdev: Forcing everything into Javascript and incompetence. I wont claim I am competent, but at least I acknowledge that SvelteReactVueSolidNextNuxt is not the solution but rather trying to patch up some symptoms... The Web needs true change.
Re: The Frontend Treadmill
#5> Whatever framework you choose will be obsolete in 5 years.
I've been writing React professionally for over a decade at this point. I don't know what this guy's on about.
Re: The Frontend Treadmill
#6> But our current framework layer is working against the grain instead of embracing the platform. Said the person with this bullshit in their page code, which will not deactivate when JavaScript fails to run: body{visibility:hidden;opacity:0} Guess who just saw it happen.
That comes from the theme they’re using, and there’s a noscript directive immediately after it.
https://github.com/Mitrichius/hugo-theme-anubis/blob/main/la...
Re: The Frontend Treadmill
#7Great advice, but my case is different because our framework is REALLY hurting us.
/s
It's wild how easy it is to fall into this trap. IMO, if you're considering switching frameworks (especially for perf reasons), your time would be better served by getting parts of your app off framework completely (assuming there's truly no way to get the results you want in your current framework.)
Re: The Frontend Treadmill
#8> Whatever framework you choose will be obsolete in 5 years. I've been writing React professionally for over a decade at this point. I don't know what this guy's on about.
Component lifecycle methods to hooks and HOCs, does that ring a bell?
Re: The Frontend Treadmill
#9To jump off the treadmill is not using a fronted framework: at all, and not using a random one and not rewriting the code later. Server side rendering, JavaScript only when needed, no separation between backend and frontend folks in the company.
Re: The Frontend Treadmill
#10Amen!