After reading the entire thread I am still in the dark about what exactly the author wants to see changed.<p>The narrative that frameworks = bad and vanilla js = good falls apart quickly IMHO in medium to large sized projects since the complexity has to be abstracted in some way in order to reach a realistic timeframe for completion.
I'm at a startup that builds an e-comm platform. Currently on Next.js; evaluating Astro.<p>We're slowly coming to the realization that none of these platforms are either simpler or faster than what we could do with modern vanilla.<p>Some very basic things like show/hide images and blocks of text based on user selection require an obscene amount of code/complexity in React that in vanilla is just<p><pre><code> element.style.display = condition ? 'none' : 'block'
</code></pre>
Bonus is that there's no need to think about component re-render. No need to think about hooks, callbacks, memos, effects, etc. A whole layer of complexity disappears.<p>From a performance perspective, there's no contest. Not only is the resultant JS more performant, having the content actually in HTML at download results in faster renders and time to interactive. Our stats show 90+% of our users are mobile so being fast and light are key parameters.<p>I think the author's point is that while HTML, JS, and CSS have been advancing, a generation of developers have been invested in React rather than learning the fully capable and often better underlying capabilities of modern browser platforms. There are many, many developers who have been trained in React + component frameworks with only a very cursory understanding of the underlying HTML, JS, and CSS.<p>Should any team use component libraries or roll vanilla? It depends on the objectives of each team. Often that tradeoff is time to market and future tech debt versus absolute performance. (I have not worked on a React project that didn't have massive tech debt not because of React itself, but the complexity ramp that arises with additional packages, dependencies, state management, and general lack of deep understanding of React's render model).<p>We still like Astro because it allows us the flexibility to use React (or Vue, or Svelte) in dollops where it makes sense.
Ah, yes. Everyone’s favorite whipping boy: the front end developers. I don’t think the last decade was a mistake. React (and Preact and similar) are my favorite ways to build out UIs. I prefer it to every other thing I’ve tried— and I’ve tried just about every other thing, including building native UIs for a decade.<p>It’s not perfect. I think we’ll find a better approach eventually, which is why I’m fine with the churn. The churn is part of the search for something better.<p>I hate the poor UX often produced by React— fat, slow, clunky pages with loading spinners and jank. So, I sympathize with the author. I hope something like Quik gets it’s footing.<p>But until there’s a better way to build UIs from this subjective developer’s perspective, I’m sticking with React.
I thought it was a good thread.<p>For those unaware of the missing context, what he's talking about is how in the 2010s, progressive enhancement — long seen as a webdev best practice — was largely replaced by a JS-first approach by JS frameworks in practice.<p>It does seem like the JS-first bubble is deflating a bit, but I'm not sure it's on its way to fully popping like the Flash bubble did. I do agree it was a lost decade though. More than a decade. I miss when everyone agreed progressive enhancement was the way to go.<p>It's entirely possible to build a SPA without abandoning progressive enhancement, but the frameworks do not encourage those best practices. As such, it's rare to see a web app built with a framework that doesn't create a hard dependency on JavaScript or isn't an accessibility disaster.<p>When I reflect on the last decade of frontend development, the lesson I draw from it is everyone is susceptible to ill-conceived fads, including people who think of themselves as evidence-driven. We're good at convincing ourselves we're objective, especially at times when we're not.<p>What's really depressing is this tendency applies to <i>all</i> the applied sciences. Tons of people who think of themselves as motivated solely by evidence fall for terrible fads in their field all the time, including, terrifyingly, in areas like medical practices.<p>I think we'd all do better to spend less time emotionally attaching to our tools and more time looking at evidence and metrics in a dispassionate way. As Paul Graham once said, keep your identities small.<p>A great book that's vital to grokking this stuff is The Scout Mindset by Julia Galef. She argues we should always just go where the evidence leads. But our monkey brains are bad at this, so it takes a lot of conscious effort or we'll do it poorly. I think JS framework mania is yet more evidence of her thesis.
I feel the author misjudges the people making these decisions because for <i>them</i> in <i>their own</i> situation, the choice of large frameworks isn't the right one.<p>But many smart people are in different situations in which the best decision is to use a framework.<p>If I'm Amazon or Google and each ms of time to page load (p99 and average) is measurably worth a 6+ figure sum of money per year, then yes, cutting out the framework and going very very basic is the right thing to do.<p>If I'm a startup with 3 engineers who need to iterate quickly and don't care about page load time (yet) then I'm going to reach for React.
What's the missing context for this thread? This person seems upset at something, but it's entirely unclear what they're actually talking about...
To add my subjective opinion:<p>I came back to frontend development after a break of 10 years. Back then there was jQuery, CSS and HTML.<p>I found that the complexity of the tooling had increased 20-fold. All these build and task runners that were cool for a year and then a new one came along.<p>Those were the costs, but what was the upside? It seems that you can do maybe 10%-20% "more" than back then. It seems to me that this is a very very steep price to pay.
The problem is misaligned incentives.<p>Sure, for my personal projects I am all about KISS but at work, if someone insists we try out this new framework and build a super complicated SPA, why not?<p>People make fun of resume-driven development but besides the money which obviously is the main benefit of having a job, experience is the other big thing that a job can offer. It is in my best interest that we use the most complex solution. I like the challenge.<p>Lets be honest, most fronted jobs could be rationalized away and the products would actually be better. It depends on your exact business but in many areas there is not point in keeping your UI "fresh". I have seen lots of redesigns actually HURT sales. Once you have found a design that works for you target customers, just keep riding the good thing.<p>So yeah, things are insane but as a developer it is neither in my power nor in my interest to change anything.
Front end development won't change. We'll just keep switching out frameworks for the shiny new one with the hope the next one won't be an overly complex mess of npm packages and microservices that can topple over at any moment.
This is just good old cargo cult JS Framework Fatigue but then in a fancy “thought leader” writing style, yes?<p>Am I missing some fundamental new insight?
Red flags words in web tech/tools to me:<p>- modern<p>- revolutionary<p>- love ("really really like" is ok)<p>- can't go back to / can't live without<p>- is the future<p>- just (describe which is not)