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.