Scraping Burned Toast

Hello. Hello. Hello. This is the Vanilla JavaScript podcast. I’m Chris Ferdinandi, thanks so much for joining me, and I hope your 2020 is off to a great start. This is the first show of the new year. And today I wanted to talk about how HTML is a living language. Back in mid December, so a few weeks ago now, Alex Russell tweeted HTML may be a dead language because those who claim to love it can’t [00:00:30] imagine it being better. And today I wanted to talk about how just utterly, completely wrong Alex is. Not on everything, just on this particular sentiment. There are two points to Alex’s tweet and I think we need to kind of break them out and explore each of them separately. So the first is the idea that HTML is dead. And the second is that people who claim to love HTML don’t want it to change. Neither of those statements are true.

So let’s dig in. [00:01:00] The first, HTML is not dead. Over the last few years, HTML has added a ton of awesome new features. First HTML5 brought us semantic elements like <nav> and <article> and <header>. We have browser native date pickers and special input types that handle form validation and pull up custom keyboards for email addresses and URLs. We also picked up browser-native ways to play video and audio files, things that used to require Flash. The website for this podcast [00:01:30] uses the <audio> element to stream episodes and it is so damn easy to use. Several years ago stuff like that required these complex JavaScript and Flash plugins. It was so much work, and now native elements make it really, really easy. We get native responsive images with <picture> element and srcset attributes. We can asynchronously load JavaScript files with async or defer and pre-load important content with rel="preload" attribute, and I’ll link to all this stuff [00:02:00] down in the show notes.

Most recently we’re now working on a new lazy loading attribute for images and iframes that will let you natively lazy load stuff without a JavaScript plugin. Jen Simmons explains in this really great video that I will also link to in the show notes, adding height and width attributes to your images, now reserve space for that image while loading and maintains aspect ratio. So you don’t end up with that jump [00:02:30] with the content when the image finally shows up. You’ve probably seen this before. A page loads, you’re waiting for an image, the image shows up and then suddenly the content gets pushed down. No more, with this new aspect ratio feature that’s coming. And there are plenty of new things that I would love to see added to HTML and CSS and JavaScript, but I don’t see how you can look at all this awesome stuff we’ve gotten and conclude that HTML [00:03:00] is dead.

The other piece here is that you can love HTML and still want it to get better. The idea that people who claim to love the web can’t imagine it being better is just patently false. Recently, Dave Rupert documented how <details> and <summary> elements are not actually an accordion even though they behave that way, and that this subverts expectations and makes his job harder. Scott O’Hara has written before about the <dialog> element, which functions kind [00:03:30] of like a modal, misses the mark in many ways and is not accessible by default out of the box. There’s a lot of stuff he needs to do to it to make it work the way it should have. In Dave’s article he even suggested new elements that he’d love to see exist, like accordion, tabs, drop-down, and tool-tip. I was chatting about this a little bit with Mandy Michael and she suggested a <carousel> element would be another awesome addition. And I think these are all things that are hard to do well and would benefit from built-in elements.

We spend [00:04:00] so much time on these low level features and I think what a lot of developers need are simple ways to do accessible things that are currently hard. So that’s one piece of it. The other thing here is that there’s a bit of a political backdrop to Alex’s tweet. It included a link to an article from Adrian Roselli that criticizes how Google Chrome hastily rolled out the <toast> element without going through [00:04:30] the proper standards process. And I will link to Adrian’s article in the show notes. Web standards are a set of processes that browser vendors are supposed to go through before implementing a feature to get other browser makers on board, document specs and iron out details. They exist to make sure that whatever you ultimately ship will be as useful as possible to as many people as possible and will be implemented consistently by all browsers.

If you’re newer to web development, [00:05:00] you may not know what the web was like before web standards. In short, it was fucking awful. Browser makers would just go off and do whatever the hell they wanted, creating new elements and new JavaScript methods and so on, to accomplish things that their users were asking for. It sounds good, but because each browser did things a little bit differently, writing code that worked everywhere was a fucking nightmare. Some people would use user agent sniffing to serve up different pages to different browsers. JavaScript files were littered with conditional if/else [00:05:30] statements using different methods for different browsers. It sucked. The web standards process ensures that this doesn’t happen again. It makes your life as a developer easier. I tweeted a little bit about this and Jon Lunman shared a really nice abridged history of the Browser Wars that I thought did a great job of summarizing what it was like and why standards matter. And he let me pull his series of tweets together into a summary that I will link to [00:06:00] down on the show notes as well.

Jon wrote in the early years of IE, Microsoft really pushed the boundaries of what could be done with JavaScript. They called it DHTML. It’s why so many enterprise/intranet systems were built for IE. No other browser at the time came close to offering the same native-like experience that we all take for granted today. Microsoft didn’t wait around for standards to emerge around this stuff, they invented whatever API they wanted, [00:06:30] CSS stuff too. Heck, they basically invented web components which they call DHTML behaviors all the way back in ’95. This meant a ton of rich dynamic web apps only worked in IE. But everyone used windows so everyone had IE, right? No big deal. Competing browsers gradually caught up in capabilities, but rallied around standards that different significantly from Microsoft’s made-up specs. By then there was a decade worth of enterprise [00:07:00] web apps in production that were built for IE only and it would be too expensive to rewrite or replace for modern browsers.

Many of these legacy systems are still in use today, which means many organizations still need IE in order to use them, which is why Microsoft can’t just kill it already despite desperately wanting to. And that’s one of the reasons so many of us still have to make our shiny new modern web apps also work in crappy old IE. We all want the web to evolve and get better, but if Google takes [00:07:30] matters into their own hands and adds nonstandard features to Chrome, then Chrome risks becoming the new IE6. So that was Jon. If it wasn’t obvious already from his last statement, this is why web standards matter and the Google Chrome team’s position that standards process is too slow is so dangerous to the web. I’d actually argue that as the dominant browser on the web, Chrome is already the new IE. They are not at risk of becoming [00:08:00] the new IE, they’re already the new IE, just by virtue of being the browser that most people use. And the question is will they learn from IE’s mistakes or are they doomed to repeat them?

Chrome has more developer advocates than some browser vendors have employees. And their approach to web standards is often, “We have an idea, let’s just throw it in the browser behind a flag and see what developers do with it.” And while that sounds reasonable on the surface, it’s behind [00:08:30] a flag after all, it means that Google never gets feedback from other browser vendors on what it is, how it should work or in the case of the ill-named <toast> element, what it should be called. And when Google does things like this, they put Firefox, Safari and other browser vendors in an awkward spot. Do they ignore the element and they get accused of not innovating? Do they push things through even when they have issues and reinforce to Google that it’s okay to just ignore the web standards process?

On mobile devices, a [00:09:00] majority of web usage happens in apps. To some people that means that the web as a platform is dying and it’s not a link to my kind of rant on that in the show notes, but the thinking here is that it can’t compete with native app features. A segment of people truly believe that in order to keep up, browser features need to grow rapidly to match the feature sets that are available in native apps. And I think that’s a false dichotomy. I don’t think this is a zero-sum game. The choice isn’t [00:09:30] web or apps, and one doing well doesn’t mean that the other is losing.

On desktop, we use browsers and native apps alongside each other comfortably all day long. No one thinks this is weird. But on mobile, it’s this big battle for the platform, and I don’t really understand why. On my phone there are some things I’d rather use an app for — email or streaming music. For others, I’d rather use a browser. I don’t think [00:10:00] that the overhead of another app is always worth the benefit. There’s some things I’d rather have a browser for. And I don’t really get why this is a bad thing. So no, HTML is not dead. The web isn’t dead. They’re changing and they’re growing slowly, deliberately slowly towards a wonderful future.

That’s it for today. If you want to finally master JavaScript, head [00:10:30] on over to VanillaJSGuides.com and check out my pocket guides and video courses. They’re short, focused and made for beginners, and you’ll learn the ins and outs of a topic in under an hour. As a listener of this show, you can take 30% off with the code podcast at checkout. See you next time. Cheers.