[danielvinson]

I think this article discounts the reasons behind frontend decisions... priorities are absolutely fast execution time and ease of hiring. There is very, very little reason to care about optimizing frontend performance for a vast majority of apps. Users just don't care. It doesn't make the company more money.

If a framework is easy to use and everyone knows it, it's simply the best choice for 90%+ of teams.

[croes]

The UX for me went downhill the last 5-7 years. I don’t know if it’s react but something changed. Pages load slow or even don’t, strange display errors, slow reaction times etc.

[tracker1]

Too few run output analysis on their bundles or even track bundle sizes. There's a lot of kitchen sink repos, not to mention any number of other bottlenecks between the front end and back end. Worse across split teams for larger apps.

[cosmic_cheese]

> There is very, very little reason to care about optimizing frontend performance for a vast majority of apps. Users just don't care. It doesn't make the company more money.

There’s plenty of users who care, but when the competition is also all slow and heavy they don’t get any choice in the matter.

[jonny_eh]

It's usually not the framework that causes apps/sites to be slow.

[cosmic_cheese]

Not directly, but when you have devs who only know how to build with the framework and don’t have a grip on what’s going on under the hood or how it all interacts in the browser environment (increasingly common), performance is sure to take a hit.

[jonny_eh]

It's not React's fault that people either don't know what they're doing, or don't care enough to make their software performant. This is not a new phenomenon, bad/rushed software has always existed.

[wahnfrieden]

GitHub somehow became instantly slow to this day after they started introducing React but I guess it’s just their devs faults

[jonny_eh]

Well, ya

[muspimerol]

This happens regardless of which framework is used or even if no framework is used. Plenty of web developers do not understand how the browser or JS work at a deep level.

[LegionMammal978]

Yeah, it's pretty close to the "Imagine how great the world would be if everyone used Lisp/Haskell/WhateverLang instead of Java/JS everywhere!" take you sometimes see. As if the common developer wouldn't just write in all those languages like they're Java/JS, and keep clear of the advanced macros/type systems/whatever.

Even languages or environments that try to "steer the developer into the correct direction" have only really managed it when the new direction is something they already might've chosen to write. Otherwise, you just end up with many square pegs filed down to fit in round holes.

[sublinear]

This isn't true at all if you're working on maintaining a web app. When ease of hiring and getting tasks done quickly have become the priority it's because the business has let too much work pile up. It has very little to do with the money unless it's a small startup.

Frontend skills are misunderstood by most of HN because it's a hard role that directly involves business and product wants. There's a ton of hiring (and firing) because it's not easy to find the right people who can communicate about the work clearly with non-devs, navigate the office politics, know what to push back on or when to ask questions, and still write good code.

[danielvinson]

I agree that maintaining web apps is an entirely different set of skills, though in my experience (mostly small and mid size companies) PMs come in with massive projects and huge changes constantly and management has to say yes to a few. I try my best to shield my devs as much as possible from the politics but usually my teams are still ending up with huge 4-5 sprint frontend projects. It's extremely hard to find devs who can create simple technical designs when there is absolutely any frontend complexity (especially things like wizards, why are wizards so hard for people...). My standard these days for a "good hire" is anyone who can handle these sorts of projects without a huge amount of help.