Why does FE development have such churn? Desktop toolkits from 30 years ago work just as performantly today; what is so difficult about the browser that demands constant framework updates?
[flagged]
The Frontend Treadmill
71–80 of 722 posts
Re: The Frontend Treadmill
#72Earlier quoted context omitted.
Right??? I started out the process trying to stick with yarn and upgrade it to use plug and play for better CI caching, but svelte apparently just does not work with it and will not do so, so I started looking into pnpm.
Meanwhile, I had to do some backend thing yesterday, and ended up using the LD_LIBRARY_PATH trick, which was introduced in 1988 . I'm grateful that LLMs are great at writing frontend code for me, though the broader implications are a bit scary.
But can a LLM help writing code for a library released or updated a few months ago, covering the implied breaking changes? With the way they work today, probably not.
Re: The Frontend Treadmill
#73Earlier quoted context omitted.
This was true in the lodash and jquery as essential days, but hasn't been the case for years. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
Ah, I stand corrected. I have more recent examples but I struggle to recall them. Map and Set were certainly the two largest absences I remember.
Yeah, those were two big sticking points.
There's also Object.groupBy() now which was another thing I always missed from the standard library.
Proposals tend to get adopted at a snail's place but it's neat to see what's coming down the pike: https://github.com/tc39/proposals
Re: The Frontend Treadmill
#74To 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.
No separation between backend and front end is hard. I’m not good at front end, and we don’t have a designer. I’m miles better on backend though and other team members are more talented than me for front end design.
Design shouldn't be part of front end engineering - there is a reason there is a separate role for that, designer.
Re: The Frontend Treadmill
#75Earlier quoted context omitted.
This was true in the lodash and jquery as essential days, but hasn't been the case for years. https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
Ah, I stand corrected. I have more recent examples but I struggle to recall them. Map and Set were certainly the two largest absences I remember.
Worth noting that those features were indeed added after the creation of e.g. React, but both have been widely available for ~10 years now.
Re: The Frontend Treadmill
#76Based 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 SvelteReactVue…
> The Web needs true change.
Here's how that works: Make something better and get people to adopt it. "The web" isn't set in stone, it's a series of tubes. Be warned though, odds are you will fail to gain traction because while we all agree that the web sucks, we all disagree on what the change should be.
I for one have the complete opposite take regarding Javascript. Just give up on the web as a declarative document platform and embrace it as an application platform. Use an actual programming language instead of adding yet another feature to the Rube Goldberg machine that is HTML+CSS. That's not solving any real problems, it's just making it incrementally less feasible to have multiple browser implementations and anyway it's not like you'll want to use the feature until years down the line when it's gone through the whole standard and adoption phase.
Re: The Frontend Treadmill
#77Earlier quoted context omitted.
This is exactly why I am a huge fan of ember.js Unfortunatelly it fell behind in popularity mostly due to some unimportant reasons (eg not being able to render 1M rows faster than react) and some important ones (load times), but boy did they build a stable ecosystem! I haven't seen such a commitment to stability and guardrail upgrades to this day on any other piece of front end library.
I'm thinking of building a long term living app (say an app that I will use the next 30 years). It has to be a web app so I was thinking of going pure JS. With that requirements in mind would you recommend ember.js?
Go for web components. It's guaranteed to last 30 years
Re: The Frontend Treadmill
#78Feels like an article from 2015, where churn was still enormous. Today we have more stability: mostly React, Angular is also still around, some novel approaches like Svelte or HTMX, but mostly its the reactive paradigm packaged in different ways (eg Vue.js). No XHTML, no IE6, heck not even IE. CSS converges on Tailwind. What is unsolved is the dependency hell: builds break over time, just by NPM rot.
Meanwhile, my team has been trying to upgrade a large app from vue2/nuxt2 to vue3/nuxt3, which has no real upgrade path at all. Oh, and the time between nuxt3's prod release and vue2's EOL was like 9 months. Vue 3 IS better than 2, but at what cost?
At least when Vue 4 rolls around, you can pay Claude Code to do it for you (for a modest fee).
Btw what made you choose Vue over React?
Re: The Frontend Treadmill
#79I 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 d…
This is why I have been so pumped for LiveView. It just removes so much javascript from the equation
Re: The Frontend Treadmill
#80To 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.
> no separation between backend and frontend folks in the company.
This is the biggest gain available anywhere.
When you have one engineer who is empowered to write SQL specifically crafted to pull the exact columns required to SSR a web view (which they are also responsible for), you don't need to spend a single second thinking about APIs or ORMs or whatever. You just need to know SQL and modern vanilla HTML/CSS/JS. The server-side programming ecosystem really starts to take a back seat since most of what you are doing is transforming views of the business (SQL) to DOM (HTML).
I think the end game is doing SSR of web content inside the RDBMS (e.g., Oracle APEX), but most engineers aren't ready for that conversation yet. I know I wasn't when I saw it for the first time in the wild. We're very attached to our modes of suffering.