🌐 If you’re going to build for the web, build *on* the web.

If I was only able to give one bit of advice to any company: iterate quickly on a slow-moving platform.

In the last year alone, I have seen two completely different clients in two completely different industries sink months and months into framework upgrades. Tens, if not hundreds, of thousands of dollars rewriting entire projects just to maintain feature parity with the previous iteration. This is not meaningful or productive work—it is time sunk into just keeping themselves at square one. A form of open-source vendor lock-in.
The saddest part of it all is that these were ex-clients who had to re-hire me because with the ā€˜upgrades’ came severe site-speed regressions. As good as it may be for business, I hate going through the same work with the same client more than once. After all, you should never need to call pest control twice.

The web as a platform is a safe bet. It’s un-versioned *by design*. That’s the commitment the web makes to you—take advantage of it:

šŸ’” Opt into web platform features incrementally;
šŸ’” Embrace progressive enhancement to build fast, reliable applications that adapt to your customers’ context;
šŸ’” Write code the leans into the browser, not away from it.

Each layer of abstraction made in the browser moves you further from the platform, ties you further into framework lock-in, and moves you further from fast.
.@nolan said it best when he said ā€˜the best SPA is better than the best MPA; the average SPA is worse than the average MPA’.
I’m not against front-end/JS frameworks, but if you’re going to use a front-end framework, I shouldn’t be able to smell it.
@csswizardry of that's a great way of phrasing it