Managing cruft & legacy

As a contribution to our thinking beyond research and feature set, I 
wanted to raise a topic that I suspect has a big impact on the Web DX: 
because we're dealing with a 30 years old platform with a strong ethos 
of backwards compatibility, the platform exposes a lot of cruft that 
only makes sense because of this legacy.

To illustrate the type of cruft I have in mind:
* CORS - it is more or less required for any cross-origin interaction, 
while it's mostly to cater to the specific needs of IP-based authentication
* CSP - you need to get through a lot of hoops which are hard or 
sometimes impossible to deploy in a number of environments, only to get 
a sane and safe security environment
* customized form elements - as has been heavily explored by the OpenUI 
effort https://open-ui.org/
(part of my thinking is that even having a clear idea of what we 
consider to be "cruft" would help inform progress on improving the 
situation)

This cruft creates challenges for the developer experience, e.g.:
* the platform is harder to understand - it makes it hard to learn, but 
also hard to retain a consistent mental model of how it works
* the platform is clunky - you have to know esoteric moves to get 
started, even before you put your time and energy in the actual work you 
want to do.

This issue was illustrated in a recent thread on social media [1]: why 
is it so hard to create good web apps, even for people with lots of 
background and expertise? Why "simply" combining the default bricks of 
the platform doesn't yield at least good-enough results?

I think this cruft probably partly explains why, of all "platforms", the 
Web is the one most often mediated by frameworks - one of their 
historical roles has been to provide a smoother, more usable surface 
than what one would get from a vanilla experience.

At a high level, I believe improving the situation in that broad space 
typically can be done through two approaches:
* improving the platform where possible - either within the limit of 
backwards compatibility or by exploring better ways to manage backwards 
compatibility
* improving the ecosystem (server-side deployments, developer tools, 
frameworks) so that defaults are more often aligned with what a good DX 
should be

Both of these come with more specific approaches, a number of which have 
been explored over time ("interventions", feature-switch à la doctype, 
deprecation plans, outreach to ecosystem); I think a catalogue of what 
has been tried, how successful or painful it was would help both inform 
possible future work, and possibly identify gaps that would need further 
exploration.

Dom

1. https://w3c.social/@matthew@spooky.click/109660239976640601

Received on Thursday, 26 January 2023 13:32:50 UTC