Great article, but the takeaway is something so profound I fear a lot of people will miss it entirely when getting into the details. It is: Understand your to

Great article, but the takeaway is something so profound I fear a lot of people will miss it entirely when getting into the details. It is: Understand your tools. And a second but equally important takeaway is: Use the least amount of tooling to implement your functionality. If you understand your tools and you use the least amount of tooling in order to implement your functionality, your website or app will be easier to maintain, more performant, possibly more secure (less code = smaller surface area of bugs and other problems to exploit), and it will train future developers in a more sane art of programming. I recently inherited a codebase that was a monstrous combination of a Rails backend broken out into multiple namespaced modules + a giant grabbag of service objects + a React front-end with a shocking number of various components — all to accomplish a relevantly small number of basic web app-ish things. (And to top it all off, it was a failed product and I'm only working on it now because a biz dev friend of mine had purchased the product from the original devs.) All that extra "web-scale" work…for a product that didn't even succeed. They probably could have halved their dev time with a vanilla Rails app and some simple JS sprinkled on top (Stimulus for example), it would have worked perfectly fine, and they would have proven the app in the market (or not). Wait to get a thousand paying users — THEN rewrite with whatever fancy-pants frontend framework and microservices backend you like. We really need to do a better job as an industry of pushing back against complex tools and complex development processes until they're absolutely necessary. Don't reach for a jackhammer when a chisel will do just fine.