I think it's the 50% part that we're meant to pay attention to. For me that's a pretty drastic, "why would you ever put this on the client side now that you know this" kind of thing.
The caveat is that this is in reference to a _landing page_ only. If you try to write an advanced application with vanilla.js and you aren't some Javascript guru, then you are going to really hate yourself later on -- I guarantee it.
Also, that 50% is only measuring the time to interactive on what I imagine is the first page visit. After everything becomes cached, I would think that the the benefit is dramatically lower.
Because it provides a robust, consistent, isomorphic framework which many people have decided that certain benefits (for us common tooling, maintenance, consistent implementation across the org, write once run twice isomorphism) outweigh the costs (interactable time, download size, etc). Everyone has to make their own choices, but this news was not surprising and did not change our opinion.
So, the developer experience trumps the user experience, in an industry where fractions of a second of load time can cost a company customers and conversions?
Not at all. The objective for a landing page is very different from all the other pages.
Landing Page: Make it load instantly so that a new user clicking on it doesn't get frustrated and close the window before it's ready to go. This is typically a static page. Note the tiny and heavily optimized google.com
Other Pages: It's sometimes necessary to load larger js libs gradually, but generally once they are loaded the browser cache makes their size a non-issue.
In summary: It's worthwhile to pay the cost of libraries, but that cost should not be paid by visitors to the landing page, and if the cost is high it might be necessary to load them in phases to preserve a good UX.
Life is full of trade-offs, gaining 1% more customers for a 10% increase in your engineering costs is not always a good deal. Being customer-centric is good, but not at all costs.
Ultimately many businesses will sacrifice polish and dev testing for features and deadlines on the skull-encrusted alter of short sprint cycles and rapid iteration.
You can't lose customers you never converted in the first place.
Does React really eliminate the potential for buggy implementations? Also I'm fairly certain that UX has more to do with design than your choice of frameworks.
You also have to consider what side benefits libraries provide. Eg, we're likely choosing React (first time in company using React) because we're choosing React Native for our mobile apps. This is because we're a very tiny shop, with very limited developers. We simply don't have the manpower to hire or learn both Android and iOS development.
Now, we reviewed a handful of iOS/Android abstractions, and React Native seemed competent - so we're using it for our first pass. Likely, we'll use it for the web frontend too, because we're using React Native. More familiarity can be a good thing.
As I discussed internally when we were choosing frameworks, if I was just choosing a web frontend it would never be React. It's not that I think React is bad, it's just that there are a dozen frameworks similar to it that are faster. It popularized a new good idea (vdom), but it's just not best in breed imo. Yet, having the same concepts and very similar codebase between mobile apps and frontend is a pretty big deal for us.
It may not eliminate them, but it's much better than my memory of developing interactive interfaces with lower level libraries like jQuery that force me to keep track of everything having to do with the DOM in my own logic.
There is such a thing as premature pessimization: making choices based on intuition about productivity benefits or personal taste that force you down the road to poor performance.
I think it's smart to include performance requirements in your specifications before starting a project (or when taking on the maintenance of one too). Set an upper limit on your TTI or server response times. Turn it into a budget. That's not optimization that's just engineering.
It's basically an excuse to not think about the performance or implementation of your entire product until the end and then, when you use a profiler and chop away "10%" here and "20%" there, you still end up with a slow-as-piss program with every function taking less than 1% total time. Then what do you do?
Oh yeah, what you should have done in the first place. _Think_ about how your program actually functions so you can remove all of the insane systemic, architecture decisions you made that all bleed a fixed amount of time every single function call. That's the difference between an engineer, and script kid. If you're not reasoning about _the entire platform_ (all the way down to the cache lines), you're not engineering. You can abstract all you want, but those abstractions don't magically prevent the underlying hardware and architectural decisions from affecting the product. Abstractions tools (read: approximations!) for high-level reasoning. They're not magic "you don't have to think [about low level implementation]" spells.
Actual experts keep trying to warn you guys about abusing that quote, but nobody apparently ever listens. Stop quoting it like a bible verse, because just like bible verses, everyone forgets the entire context and just uses it like a bloody bumper-sticker slogan.
In the words of Saul Williams: "You have wandered too far from the original source, and are emitting a lesser signal."
The full Donald Knuth quote:
>The real problem is that programmers have spent far too much time worrying about efficiency in the wrong places and at the wrong times; premature optimization is the root of all evil (or at least most of it) in programming.
That quote sounds much less like a law handed down by God, and more a guideline from experience, no?
Optimizing the wrong things (things that get thrown away when you change your program as you work toward your goal) ends up wasting time. But just because that was applicable _in the 70's_ doesn't mean modern programmers have the same mentality of "optimize optimize optimize." Modern programmers have the opposite. They're so afraid of having to learn how cachelines work, they use that quote to prevent having to do any optimization (or understanding of architectural layout tradeoffs). I can't count how many programmers I've met that hear "cache" and their eyes glaze over like it's some magical, incalculable thing.
Watch a lecture from Mike Acton, where on consoles, they don't have the luxury of writing poorly written, un-optimized code. They _do_ have to understand the entire platform to ship a competitive title. Because any optimizations they do, for a fixed platform, means they can pump out a better experience with those extra CPU cycles. An experience that elevates them above their competitors.
Which at one point wasn't a static landing page. Netflix has something of a captive market at this point in time; but could a newer startup scrambling to gain users afford to make the same choices?
I would hope that a startup scrambling to gain users would be able to explain in a simple static html site why their service is worth bothering with.
If I'm not particularly interested, I'm not going to wait around for mountains of JS to download and execute, and the typical content-free startup landing page full of hero images, stock photos, and vague bullet points to load up.
If this comment section is any clue, clearly it's not going to change a React programmers opinion because they completely loose their shit if you mention a flaw in React.
I believe my case was pretty clearly articulated as are some of the other comments on a thumbnail sketch of the tradeoff comparison we have and continue to do. I'm sorry you believe the worst in this community.
