Written by Harry Roberts on CSS Wizardry.
This article started life as a
post on LinkedIn, but after some gentle nudging from friend, web custodian,
and unwitting mentor Jeremy Keith, I’ve
decided to publish and expand upon it here.
If you’re going to build for the web, build on the web and build with 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.
Collectively, they’ve spent 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 merely
keeping themselves at square one.
It’s a form of open-source vendor lock-in, and adding even the most trivial of
performance improvements becomes impossible as frameworks obscure or sometimes
remove the ability to fiddle with the nuts and bolts. The worst thing? You get
to do it all again in 18 months! The stack owns you, and you have an entire
development team who might be paid one or two quarters every two or three years
just to tread water.
They’re iterating slowly on a fast-moving platform.
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: To paraphrase my good
friend Ryan Townsend, customers don’t want smooth page
transitions—they want a website that
works. Don’t make your
entire site a single page app just so you don’t have to retransmit a header
and footer. - Embrace progressive enhancement to build fast, reliable applications that
adapt to your customers’ context: The beauty of opting into web platform
features as they become available is that your site becomes contextual. The
same codebase adapts into its environment, playing to its strengths, rather
than trying to build and ship your own environment from the ground up. Meet
your users where they are. - Write code that leans into the browser, not away from it: By using
progressive enhancement, you can opt into browser-native features that are
usually faster, more accessible, more secure, and—perhaps most importantly to
the business—maintained by someone else.
All of this seems painfully reminiscent. As far back as 2007, Dan
Cederholm gave us
dowebsitesneedtolookexactlythesameineverybrowser.com
(the answer is no; I saved you a click). Almost 20 years ago, the discussion
was around much more trivial, visual flourishes like rounded corners and drop
shadows, but the sentiment still rings true today: shipping hundreds of
kilobytes of JavaScript so you can give an otherwise static site smooth, soft
navigations is entirely nonsensical. Nowadays, you can implement that with one
line of CSS and the worst case scenario is that browsers that don’t support
it simply traverse your site just like they were always designed to do. Your
escalator became stairs.
The web platform moves slowly, and I understand that can be frustrating for
developers who want to innovate, but over a decade of consultancy
experience has taught me time and time again that the
alternative is much more restrictive in the long run. What’s brand new today
starts to show its age much more quickly than something that’s already stood the
test of time.
Every layer of abstraction made in the browser moves you further from the
platform, ties you further into framework lock-in, and moves you further away
from fast.
I remain convinced that the typical developer doesn’t know enough about business
analysis, and the typical business analyst doesn’t know enough about
development, to fully reconcile the two sides of the coin. Deeper, and more
balanced, long-term discussions need to be had from both parties, because the
lock-in (and its ongoing cost) is very real, and today’s shiny will soon become
tomorrow’s millstone.
I’m not against front-end frameworks, and, believe me, I’m not naive enough to
believe that the only thing a front-end framework provides is soft navigations,
but if you’re going to use one, I shouldn’t be able to smell it.
If you’re going to go all-in on a framework or, heaven forbid, an SPA, give the
long term some serious consideration, and make sure you do a really, really good
job.
Nolan Lawson said it best when he said the best
.
SPA is better than the best MPA; the average SPA is worse than the average
MPA
