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.

▲

cosmic_cheese 19 hours ago | parent | next [-]

> 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 19 hours ago | parent [-]

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

▲

cosmic_cheese 19 hours ago | parent [-]

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.

▲

muspimerol 6 hours ago | parent | next [-]

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 an hour ago \| parent [-]
		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.

▲

jonny_eh 12 hours ago | parent | prev [-]

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.

▲

croes 21 hours ago | parent | prev | next [-]

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 21 hours ago \| parent [-]
		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.

▲

sublinear 4 hours ago | parent | prev [-]

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.