🌐 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.
=> More informations about this toot | More toots from csswizardry@webperf.social
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.
=> More informations about this toot | More toots from csswizardry@webperf.social
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.
=> More informations about this toot | More toots from csswizardry@webperf.social
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.
=> More informations about this toot | More toots from csswizardry@webperf.social
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.
=> More informations about this toot | More toots from csswizardry@webperf.social
.@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’.
=> More informations about this toot | More toots from csswizardry@webperf.social
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.
=> More informations about this toot | More toots from csswizardry@webperf.social
@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.
=> More informations about this toot | More toots from jasper@dystopianpresent.club
@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.
=> More informations about this toot | More toots from woo@fosstodon.org This content has been proxied by September (ba2dc).Proxy Information
text/gemini