This is looking at the "fully loaded" time. I can tell you this, you can make the fastest retail website ever seen with 100 score on lighthouse and it's going to get absolutely murdered when you try to deploy it.
The business will want pixels. Data analytics. AB Tests. Social buttons. These will be attached to million dollar campaigns. You do not get to say no. There goes your "fully loaded" time. Every client side event is now wrapped in nasty JS beacon reporting, probably a few of them.
The home page team wants recommendations that can't be cached. It's determined to fetch this on the client to enable a faster TTFB. All those products need to fetch images, too. The time to interactive bumps up a bit.
After a while, it turns out even the CMS static content wasn't safe. The CMS team wants interactive elements. You hack a little more JS. The time to interactive bumps up a bit.
The checkout team has a more dynamic approach because of the user expectations. They use some packages they want preloaded because the metrics tell them that getting to checkout faster means more conversion. More unused JS to load on the homepage in case of clicking "add to cart." You might argue about it, the button could take you to the cart page and the server could perform the add to cart. Maybe you win and implement it. This version fails the AB test.
After a while of this, the team chafes at plain css. Just 10% of it is still used on the homepage and people are afraid to delete things because it's so hard to know what the effect is across the site. The common css continues to bloat for forever. Some day, years from now, it's such an unrecognizable mess that the decision is made to delete and start over.
The JS isn't aging well either. Just writing script tags led to poor reusability and breaking the browser cache too often. Pretty early on somebody added rollup and a major project is done to clean up script tags. Progressively enhancing the "legacy framework" html worked well in the beginning but now you're staring at a mile long bug backlog of reports like "when in this state, click this thing and then click the other thing and it's not showing expected x."
Worse, you can't hire any frontenders. Gone are the days when frontend would also know whatever "legacy" backend framework you have. They don't want to work in PHP or Java or whatever, they want to specialize in the frontend. Most of your frontend team joins, complains loudly and leaves inside a year.
I've lived this nightmare a few times. I have cleaned up after this nightmare a few times.
React is ~40kb of well-earned patterns and a sane way to handle complexity over years of development. You still have to engineer well, but after having seen really smart people fail with seemingly smart frameworks, I appreciate the React way.
This sums it up exactly. The problem is with the decision makers who are almost never the dev team. Even when it is the dev team’s fault, that is often also the fault of management who cheaped out and hired a junior team rather than paying for experienced devs to do the spearheading.
The business will want pixels. Data analytics. AB Tests. Social buttons. These will be attached to million dollar campaigns. You do not get to say no. There goes your "fully loaded" time. Every client side event is now wrapped in nasty JS beacon reporting, probably a few of them.
The home page team wants recommendations that can't be cached. It's determined to fetch this on the client to enable a faster TTFB. All those products need to fetch images, too. The time to interactive bumps up a bit.
After a while, it turns out even the CMS static content wasn't safe. The CMS team wants interactive elements. You hack a little more JS. The time to interactive bumps up a bit.
The checkout team has a more dynamic approach because of the user expectations. They use some packages they want preloaded because the metrics tell them that getting to checkout faster means more conversion. More unused JS to load on the homepage in case of clicking "add to cart." You might argue about it, the button could take you to the cart page and the server could perform the add to cart. Maybe you win and implement it. This version fails the AB test.
After a while of this, the team chafes at plain css. Just 10% of it is still used on the homepage and people are afraid to delete things because it's so hard to know what the effect is across the site. The common css continues to bloat for forever. Some day, years from now, it's such an unrecognizable mess that the decision is made to delete and start over.
The JS isn't aging well either. Just writing script tags led to poor reusability and breaking the browser cache too often. Pretty early on somebody added rollup and a major project is done to clean up script tags. Progressively enhancing the "legacy framework" html worked well in the beginning but now you're staring at a mile long bug backlog of reports like "when in this state, click this thing and then click the other thing and it's not showing expected x."
Worse, you can't hire any frontenders. Gone are the days when frontend would also know whatever "legacy" backend framework you have. They don't want to work in PHP or Java or whatever, they want to specialize in the frontend. Most of your frontend team joins, complains loudly and leaves inside a year.
I've lived this nightmare a few times. I have cleaned up after this nightmare a few times.
React is ~40kb of well-earned patterns and a sane way to handle complexity over years of development. You still have to engineer well, but after having seen really smart people fail with seemingly smart frameworks, I appreciate the React way.