I mean, that’s a thing, right? Us devs are all talking all the time
about the tool chain and the libraries and the npms and just how hard
building the web has become. But we’re talking about it wrong. The
problem is not that writing JavaScript today is hard; the problem is we
still have to write so much of it.
There isn’t a front-end development crisis; there is a browser
development crisis.
Think about how many rich text editors there are. I don’t mean how many
repositories come up when you search for “wysiwyg” or whatever on
GitHub; I mean how many individuals out there had to include a script to
put a rich text editor in their page. And for how long now? Ten years?
Sure, we got contenteditable, but how much human suffering did that
bring us?
Where is <textarea rich=”true” />? Where, for the Medium-editor fans,
is <textarea rich=”true” controls=”popup” />?
Believe me, I have already thought of your cynical response. There are
9,999 reasons to call this a pipe dream. I don’t have time for them,
thanks to all the Webpack docs I have to read. I’m not talking about
things that’d break the web here – I don’t want us to try to build
jQuery or React into the JS engine. I’m talking about things that are
eminently polyfillable, no matter how people are deploying them now. And
do I want to start another browser war? Yes – if that’s the only way my
time can be won back.
Lots of web pages have modal content – stuff that comes up over the top
of other stuff, blocking interaction until it’s dismissed. It was
pointed out to me on Twitter that there have already been not one, but
two standards for modals in JS, both of which have been abandoned. But
they tried to reach toward actual, application-level modals, which
already constitutes a UX disaster even before you add the security
problems. By contrast, the web modals you see in use today are just
elements in the page; a <modal> element, that you can inspect and
delete in Dev Tools if you want, makes perfect sense. It might not
replace a ton of code, but every little bit helps.
It doesn’t stop with obvious individual elements, although that may be
the best initial leverage point (reference the <web-map /> initiative and its Web Components-based polyfill, the better to slot
neatly into a standards proposal). There are plenty of cowpaths to pave.
We need to start looking at anything that gets built over and over again
in JS as a polyfill… even if for a standard that might not have been
proposed yet.
You know what a lot of web sites have? Annotations on some element or
another, that users can create. They have some sort of style, probably;
that’s already handled. They might send data to a URL when you create
them; that could be handled by nothing more than an optional attribute
or two. While you’re at it, I want my Ajax-data-backed typeahead
combobox. But now that we’re talking to servers…
You know what a lot of web sites have? Users. I’m not the first to point
out that certificates have been a thing in browsers for pretty much the
entire history of the web, but have always had the worst UX on all the
civilized planets. There is no reason a browser vendor couldn’t do a
little rethinking of that design, and establish a world in which
identity lives in the browser. People who want to serve different
content to different humans should be able to do it with 20% of the code
it takes now, tops. (Web Access Control is on a standards track. Might
some of it require code to be running on the server? Okay – Apache and
Nginx are extensible, and polyfills aren’t just for JS; they’re for PHP
too.)
And all of that implies: you know what a lot of web sites have? ReST
APIs. Can our browser APIs know more about that, and use it to make Ajax
communication way more declarative without any large JS library having
to reinvent HTML? Again, it’s been like ten years. ReST is a thing.
While we’re talking reinvention, remember the little orange satellite-dish icons that nobody could figure out? Well, if we didn’t
want to reinvent RSS, maybe we shouldn’t have de-invented it to begin
with. In the time since we failed to build adequate feed-reading tools
into browsers and the orange icons faded away, nearly all of the value
of the interconnected web has been captured for profit by about three
large companies, the largest being Facebook. For all practical purposes
in America, you can no longer simply point to a thing on the web and
expect people who read you to see it. Nor can you count on them seeing
any update you make, unless you click Boost Post and kick down some
cash.
Users voted with their feet for a connected web, which had to be built
on one company or another’s own servers – centralized. It had to be
centralized because we weren’t pushing forward on the strength of the
web’s connective tissue, making it easy enough to get the connections
users wanted. And credit where it’s due to Facebook and Twitter (and
Flickr before them) for doing the hard work of making the non-obvious
obvious – now we know, for example, that instead of inscrutable little
orange squares in the location bar, we should put a Follow button in the
toolbar whenever a page has an h-feed microformat in it. Or a bunch of
FOAF resources marked out in RDFa, for that matter.
Speaking of microformats and RDF and bears oh my[1], it might be
time to stop laughing at the Semantic Web people, now known as the
Linked Data people. While we’ve been (justifiably) mocking their
triplestores, they’ve quietly finished building a bunch of really
robust data-schema stuff that happens to be useful for a clear and
present problem: that of marking things up for half a dozen different
browser-window sizes. Starting with structured data is great for that.
Structured data may also be helpful for the project of making browsers
help us do things to data by default, instead of having to build
incredibly similar web applications, over and over and over again.
But Mike, you’re thinking, if the browsers build all these things
we’ve been building in JS as in-browser elements, then everything will
look the same! To which I say, yes – and users will stand up and
applaud. They love Facebook, after all, and there ain’t no custom CSS on
my status updates. It’s not worth it. Look, I don’t want to live in a
visual world defined by Bootstrap any more than you do, but it’s time
for the pendulum to swing back for a little while. We need to spend some
time getting right about how the web works. Then we can go back to
sweating its looks. And it’s not as if I’m asking for existing browser
functionality to go away.
But Mike, you’ve now thought hard enough that you’re furiously typing
it into a response box already, you have no idea. Seriously, you have
no idea how hard it would be to do all this. Well, you don’t spend 20
years building the web, as I have, without getting at least some idea
of how hard some of this will be. But you’re right, it will be stupid
hard. And I’ve never been a browser engineer, so I have no real idea how
hard.
And you, I counter, have no idea how worth it all the hard work will
be. To break Facebook’s chokehold on all the linking and most of the
journalism, or, if that doesn’t move you, to just see what would
happen, what new fields would open up to us if connection were free
instead of free-to-play. To bring users some more power and consistency
whether individual web builders lift a finger or not. And yes, to bring
front-end web development back a little bit towards the realm of the
possible and practical.
Flash is dead; that is good. Apple may have dealt the decisive blow, but
browser vendors did most of the legwork, and now as a direct result we
have browser APIs for everything from peer-to-peer networking to 3D, VR,
and sound synthesis. All of that is legitimately awesome. But for all
the talk about defending the open web, that stuff only got done because
a software-platform vendor (or three – Google and Microsoft’s browser
teams helped a bunch) detected a mortal threat to the market of its
product. When Mozilla threw its first View Source conference in Portland
last year, that was my biggest takeaway: Mozilla is a software platform vendor, first and foremost, and will make decisions like one. It
happens to be a nonprofit, which is great, but which may also contribute
to its proclivity to protect itself first. That self-interest is what
will drive it to do things.
So. Dear Mozilla: there is a new mortal threat to the market of your
product. It is the sheer weight of all this code, not in terms of load
time, although that’s bad enough, but development time. The teacups of
abstraction are wobbling something awful, and we need you to have our
backs. You employ people who are way smarter than me, and they can
probably think of way better things to put into place than the examples
I’ve got here. That isn’t the point. The point is there has to be less
code to write. Pave some cowpaths. Make Browsers Great Again. Or
something. Please. Thank you.
[1] Because I know they’ll get all in my mentions, I hasten
to add that microformats were created by an entirely different tribe of
developers than RDF-and-such, and were in fact created as a direct
response to how awful RDF was to deal with at the time. And yeah, it was
pretty awful to deal with… at the time. Now it’s better, and I kind of
think team Linked Data has regained the edge. I tried really hard not to
make this piece into a Semantic Web/IndieWeb beef tape. I’m sorry.