Harry Robertsš 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.
McNeely@csswizardry of that's a great way of phrasing it
Jasper@csswizardry I am going through this now, as a small agency with quite a few active clients (ranging in _how_ active, but still active) and we basically have 3 states: gulp (moving away from this), webpack (we can mostly stay because it still upgrades OK butā¦), and vite (new hotness, but for how long?!)
I want to go back to a world where we write CSS and JavaScript and maybe have something like Vite but only for hot-reloads. All transpiling and post-processing ends up kicking your ass.
Andy Wootton@csswizardry It doesn't need to be slow, just stable and backwards compatible. I chose emacs and Clojure because I'm older than The Web.
@csswizardry 'Obviously', I didn't choose Clojure before the web, though I did try a Lisp before Common Lisp was standardised, back in the Early AI Winter.