3 ms·

I don’t have much experience with frontend frameworks / libraries, but I really dislike the way this article presents React as the silver bullet. Maybe it is f

by e28eta 3y ago

I don’t have much experience with frontend frameworks / libraries, but I really dislike the way this article presents React as the silver bullet. Maybe it is factually accurate that Angular was the wrong choice for e-commerce (at the time?). I don’t know. Without SSR, was there really nothing feasible they could do to reduce the page load time? Did Angular make tradeoffs that are better for a large, interactive web application; and you want a different set of tradeoffs for ecomm use cases? Or were they just stuck with the wrong tech at the wrong time: complicated enough that it’s too slow in Angular, and the project hadn’t caught up to them yet? That JS bundle was doing _something_ (probably lots of somethings). How many features did the React rewrite drop? Could you have removed those features from the old codebase, or would that have been politically infeasible at the company? (“no, don’t delete that” vs “yeah, we can live without that, you don’t need to implement it” -> author gets to add a Loss Aversion sidebar). Are there still items in the backlog to re-implement missing features (that the team intends to complete)? Development effort compared between stop-the-world rewrites (in order to hit their 7 week “really big shopping event”) vs rewrite following ongoing feature development and the painful merges mentioned in the article. Obviously business appetite changed for a stop-the-world rewrite, but could that have been identified earlier? Changing requirements: did the Angular upgrade start with “we need SSR” as a top requirement? It seems more likely that there were a bunch of benefits / requirements for a technology upgrade, and over the previous 10 months they’d discovered SSR as a blocker. Erasing the other improvements makes the 10 months vs 7 weeks sound very impressive, but seems disingenuous. Maybe my expectations are off for a blog post format.

OJFord 3y ago
> I really dislike the way this article presents React as the silver bullet. It didn't read like that to me, I thought the point was they went for a rewrite on the new breaking changes major version, expecting specific features to eventually land, were waiting for them, and React had them already. So it's more (to me) like 1) don't do that; 2) if you're going to do that maybe take a step back and there's something else out there already or that's a better fit.
- dfcowell 3y ago
  Author here. That’s the takeaway I was going for. It could have been any technology. The silver bullet is choosing the right tool for the job. I don’t have an attachment to any particular tech. At the time React was what I knew, and I was coming off the back of building a server side rendered React site when I joined this company. I had a team of JavaScript-focused engineers to work with.

by e28eta 3y ago

OJFord 3y ago

> I really dislike the way this article presents React as the silver bullet. It didn't read like that to me, I thought the point was they went for a rewrite on the new breaking changes major version, expecting specific features to eventually land, were waiting for them, and React had them already. So it's more (to me) like 1) don't do that; 2) if you're going to do that maybe take a step back and there's something else out there already or that's a better fit.

dfcowell 3y ago
Author here. That’s the takeaway I was going for. It could have been any technology. The silver bullet is choosing the right tool for the job. I don’t have an attachment to any particular tech. At the time React was what I knew, and I was coming off the back of building a server side rendered React site when I joined this company. I had a team of JavaScript-focused engineers to work with.