Transcription
Christian Heilmann: All right. No pressure then. That’s fine. I want to talk about breaking out of the Tetris mindset today. That sounds cryptic, and that’s what it’s supposed to be. Now we’re starting the timer to make me even more stressful here. Okay.
I’m Chris Heilmann. I’m @codepo8 on Twitter in case you have enough -- you want to know about JavaScript news, Web news, kittens, hedgehogs, and all kinds of things that happen to me. I tweet a lot. People actually tell me that I probably hired people to tweet for me. They’re not. It’s just that’s how sad I am.
Audience: [Laughter]
Christian Heilmann: I’ve got my blog at ChristianHeilmann.com since 2006. This is the thing that fascinates me that we have these things, just these few lines gives you now a chance to rant at me, to talk to me, to ask me questions. Give a chance for me to connect with you and to find out what you are doing, how creative you are. This is why I love the Web. This is where I have fell in love with the Web from the very beginning that it’s really easy to set up your presence on the Web. It’s really easy to leave a terrible mark and, like, lots and lots of data that you don’t want to get cached on the Web, but it’s just this wonderful thing.
The other day I went through my flat and cleaned it up like it was a new month, and I had to find a few things. I found this old picture of my first setup, first professional setup of a computer was. I wrote games on Commodore 64, and I did illegal things on Commodore 64.
This is the printer that I printed all my A-level paper. It took me like 19 hours to get the whole thing out because it always rendered half a page and then it printed it out. Then it rendered another half, and it printed it out. My neighbors absolutely loved me for that.
But what is important about this here is these photos up there. There’s photos on the wall of people that I’m actually connected to. I started using a computer to get to know people worldwide. My village that I grew up in was 3,000 people. Whenever you did something wrong, everybody knew the next morning, and the people that you met were not that exciting. Until you had a car, you basically were stuck there, but we had the opportunity to get to know people with computers.
Back then I packed floppy disks into envelopes and emailed [sic] them worldwide and then got floppy disks back. Then we shared photos with each other to have a face on the people that we sent letters to each other. Long notes on like just written on that thing, and nowadays we could send each other emails every two minutes and we don’t. We just basically do, like, blah-blah-blah. Do this now.
The art of conversation and the loveliness that we had back then went a bit away because everything became too fast and everything became a race. We wanted to be like the first one to do something.
When you think about it, how rudimentary that setup was and how amazing it is nowadays that I’ve got a laptop that I turn into a tablet and I have with me all the time. I’ve got a mobile phone in my pocket. Not now because it will interfere with the microphone, but I normally have a mobile phone in my pocket that is a computer that allows you take pictures, to annotate them, that has machine learning on the images to recognizes people automatically.
We’ve come so far, and yet right now I get this feeling that we’re in a stress situation. Every single conference, and I’m speaking at one every week right now, has a talk about mental health, has a talk about how we are all overwhelmed, and how technology is going too fast and what to do to keep up with it. I found this animated GIF a long time ago that summed it up quite nicely that if Tetris has taught me anything it’s that errors pile up and accomplishments disappear.
This is really dark if you think about it, but it is kind of that way. Like every time you make a mistake in Testris you basically pile up and it gets further and further. I love Tetris. It’s like playing with anxiety and, like, rudeness at the same time and getting you a threshold better about it.
I took this this metaphor, and I’m taking it now to our market. I’m talking about the spectrum that we have. We always talk about Web development, but there are so many different things in it. I think it goes from an innovative and controlling end of the spectrum of the market to a conservative and a trusting environment.
I want to make sure that, before we go on, I have quotes in there that are amalgamated quotes. Some of them are verbatim, but some of them are just from other quotes that I have. These are not mine, so please don’t say Chris Heilmann said on stage this and that, and we cause Twitter drama because one thing we need less of it’s Twitter drama.
We have the right conservative blocker. This is not my political view. It is, but it’s like I had to start somewhere. You see these quotes where people are like, “Don’t trust a client site. Do it all on the server.” Browsers are terrible. JavaScript is a toy language. You see less and less of those people, but these quotes are still around. These are still coming from time-to-time.
“Web standards are good, but let’s not get overboard with fancy things.” We might be at rounded corners, but we don’t do any of this animation stuff because that doesn’t work.
“It’s great that they’re evergreen browsers, but that doesn’t apply to our customers.” I heard that all the time and it’s true. I mean a lot of people can’t upgrade. That’s why they have ransomware right now. But it’s always sometimes one of these copouts like, okay, I don’t want to think about I want to upgrade my skill set for 2006. I want to just keep going where it is.
Well, the good thing about that is all of these interfaces that are coming from that mindset are bulletproof. They’re working interfaces, but they’re likely to bore end users. Like clicking on something and having it reload every single time in between looks weird to us nowadays. We’ve been conditioned to things being much more high fidelity and much more responsive to us.
Also, we kind of hold the Web back that way because, when you do these kind of interfaces, you don’t give people something for upgrading their browsers, like any upgrade of a browser should be connected with something. It should be more perfection. It should be better interfaces, should be new interfaces. But we just, basically with that one, keep the Web back. Browser makers can benefit from it, though, because if people rely completely on the browser to do everything, we can stop, do performance enhancements in the browser to make sure that things work nicely.
Now the right conservative piece goes a bit further and goes on with progressive enhancement. That’s what I’ve been for a long, long, time. Progressive enhancement is the way to build working solutions. You build on static HTML generated from a backend, and it will never break the user experience.
Or you have no rights to block any user. The Web is independent of device and ability. IT is our job to make sure that people can use our products. We do that by relying on standards.
“Web products do not have to look and work the same in every environment.” It hurts me that we have to repeat this over and over again, but we still do.
This is, to me, the place where we get working, great looking interfaces that vary with the environment. Too many clients still don’t understand that. They’re like, no, if it looks the same on your mobile phone and your desktop, you probably made a mistake. You didn’t do anything good to any of these users.
It’s the best of both worlds, but it means that you need to test and understand the older environments as well. A lot of people don’t want to do that. Traditionally, browser makers learned a lot from this group because they actually want standards to succeed. And we actually want standards to succeed as well, so we actually work together quite nicely this way.
Then we got the square, which is, in Tetris, the thing that gets you two lines, but it’s always, bang, in the middle. “No matter what you do, HTML is always the thing the browser gets. HTML is fault tolerant and will work wherever and forever.”
“Using semantic HTML gives you a lot of things for free: accessibility, caching, fast rendering. You can’t lose if you rely on HTML.” This is true. This is a final truth, 100% correct. In the end the browser will get some HTML to render. If you start with Jade, if you start with Markdown, if you start with JavaScript, if you start with PHP, Pearl, whatever, HTML is what the browser needs to do something with it. If that’s a button, it actually gives you more things than when you give it a div and some class on it and you hope JavaScript does the rest.
The problem is, though, when we moved HTML in HTML 5 away from documents to apps. We lost a lot of things that we promised. Still to date, a date picker is not working across browsers. The input type number doesn’t allow me to use floating numbers in most mobile keyboards, so it doesn’t work in iOS. It doesn’t work in Android because Android -- while, iOS gives you floating point numbers, Android doesn’t give you negative numbers. Windows Mobile gives you all of them, but it has no users.
Audience: [Laughter]
Christian Heilmann: We have all these primitives in HTML 5, but they don’t work the way we expect them to, and a lot of times they make very odd things for us, odd decisions for us because the HTML standard did not define how an interface should look. It just defines what it should do, so browser makes and obviously operating system makers on mobile devices went completely nuts and did random stuff with it.
Now this is not the fault of the browser makers because we, as a community, we lost sight of HTML as well. We did not demand that, like, an input type date works properly. We just, instead, replaced it with something else. This is the main thing there.
The straight and narrow piece in Tetris is great because you get four lines gone. But if you put it on the right-hand side or on the left-hand side, then you need another four piece to actually make something. Otherwise you have a massive gap in there.
In the Web, to me this is like the polyfills and jQueries and abstraction libraries that we started to use and fixed the HTML problems that we saw. Browser differences are annoying and shouldn’t be in the way of the developer. That’s why we need abstraction libraries to fix these issues.
A lot of people have jQuery in their thing to fix Internet Explorer 6 problems. They don’t have Internet Explorer 6 users any more, but they leave it there for prosperity, and let’s hope that everything works.
The other day I saw a demo where somebody had a dollar AJAX from jQuery with an arrow function in it. Basically you expect the newest, well, ES6, the JavaScript from one year ago, and at the same time you put jQuery in there to support browsers from 2004, or 1999 in this case. That’s a mix and match that fascinates me.
“Understanding standards while they are in the making is nothing we have time for.” A lot of developers feel still disconnected from the standard procedures because it’s not much fun to sit in those meetings, and it’s not much fun to have, like, these 300 email threads, but they’re important email threads.
“Library is so much easier. Why don’t we just add those to the browsers?” When I worked on Firefox, the amount of people that asked me, “Why isn’t jQuery in the browser?” drove me nuts, but that’s what people expected, so why didn’t you ship that with the browser? Why do you make a decision for us that we hate in two months?
There’s no doubt that jQuery, Modernizr, and other polyfills are to thank for the Web we have today. They make things work. They also empowered a whole new generation of developers who didn’t want to understand about Web standards, who didn’t understand about standards or what standards really give you. For me as an old, decrepit, lost man of the Web, I used to -- I was happy when we finally didn’t have Netscape 3 and IE4 to care any more. I love Netscape 6. I hated it because it crashed all the time, but it was the first browser to have DOM JavaScript support, the standardized DOM and not the document.layers and document.all.
These pains are not understandable for most developers nowadays that started with jQuery because everything just clicked with a few lines of code. That’s good. The problem, though, is that we have far too many projects that are dependent on it. I just upgraded my -- I wrote a new template for my WordPress blog, and then one of my plugins didn’t work, the highlighting of the code.
I’m like, okay. I complained. I went to GitHub to the plugin and tried to fix it. They’re like, no, you don’t have any header tags in your template. I put the WP header in there, and all of a sudden I had jQuery in there. I had Bootstrap in there. I had some emoji library in there, and I’m like, what the hell is this? This has nothing to do with my template. This has to do only with the admin interface of WordPress. I wrote a filter to get out of that again, but this is what we did. We’re like, you rely on this. It’s good.
The other problem is that a lot of developers became dependent on these abstractions. They want to be jQuery developers and not JavaScript developers. I had people that applied to work on Firefox and only knew jQuery. I’m like, that’s not what Firefox is written in. It’s written in JavaScript, and XML and all kind of other stuff.
Browser makers and standard creators can learn a lot from that, though. We learned a lot from jQuery. The new APIs that we have in the DOM now are very much influenced what jQuery gave us, so I’m not hating, as the young kids say, on jQuery here. I’m just saying that we made ourselves reliable far too much on these abstractions to fix problems that probably don’t exist any longer because these browsers are not being used any more or should not be used any more.
The T-block in Tetris is, of course, the one you want to wait for because that one fits everywhere and solves every problem. That to me is JavaScript. I can do everything in JavaScript. Every developer on the Web should know it. Using JavaScript, I can test if something I wanted to happen happened. There’s no hoping that the browser did it right. We know. It’s great that HTML and CSS is forgiving, but you never know if it really gets applied properly. You don’t get any error handling back. In JavaScript, when you mess up, you know, and you can put a trap in there so you don’t mess up, but that’s the next step of development.
JavaScript, to me, was necessary to make the Web of today happen. Without the HX stuff we had, without proper DHTML as well, we wouldn’t have had these things. I remember when, like a few years ago, we had HTML 5 game libraries, lots of them as well. Nowadays almost everything on the Web is HTML 5. Flash is dying rapidly, and good riddance. But we don’t even have to understand that any more. It is a thing we use.
The great thing about JavaScript is that you can actually make things more accessible by using JavaScript. Putting an area attribute, most area attributes, onto an HTML element doesn’t make it accessible at all. You still have to write a JavaScript to interact with that and do something and change the state of it. It’s just you’re translated to the assistive technology. So there’s a misconception that just by putting area on everything you already make things accessible. You don’t. You have to use JavaScript because you didn’t use a native control from the very beginning. If you simulate a button, you have to simulate a lot of stuff.
It’s a fickle friend as well. That’s the problem with JavaScript. JavaScript can fail in many ways. I’m not talking about people who turn off JavaScript because, fair enough. Good luck to them. If you want to turn off JavaScript, turn off JavaScript. You should still get something. A good interface should still work.
I’m talking about the halfway case where, like, one or two of your libraries have loaded and the other one stops. Or when you have an AJAX call that isn’t doing anything and doesn’t have a time out and gets a spinner here, basically like installing Windows kind of thing. It just is not a sensible thing to do. With JavaScript, we have massive control, but we have also massive responsibility. We shy away from that responsibility from time-to-time.
Then we’ve got the innovation piece where it’s like it’s okay to rely on JavaScript to be available. The benefits of computation of values without reloads are too many to miss out on. I don’t want to have to think about older browsers and broken environments. Frameworks and build processes can take care of that. That’s where browser sniffing comes in to a degree and blocking out things.
“The concept of starting with a text editor and static files is outdated. We have so much more benefits from using a proper tool chain. If that’s too hard for you, then you’re not a Web developer.” That’s a quote a saw that somebody emailed to me that was quite fun.
Audience: [Laughter]
Christian Heilmann: “But that’s where we are. Web standards like CSS, JavaScript, and HTML are conversion targets. Sass, CoffeeScript, Elm, Markdown, and Jade give us much more reliable control right now, better syntax, and not just waiting for browsers to catch up.”
“Knowing about different browsers and caring about broken implementations is a waste of time. It’s much more efficient to start with an abstraction.” When you look at, like, games development or something like that, that’s where that comes from. Nobody writes directly to the metal of the chip any more. Everybody uses libraries for everything, and we now started bringing that mindset into the Web as well.
Developer convenience in this case trumps end user experience. We make it easier for us to build things, and that can result in massively bloated solutions. Like, okay, our build script is like five lines of code and I write type script, and then it generates something. I don’t care as long as it works.
But the good thing is that we write technology then to actually undo the mistakes we did before. We put too much code in, and then we write some other pre-compiler or post-compiler to actually take the things out that are not used after animating it and running it through a virtual DOM or whatever like that.
Browser makers can’t help you with that because you got away from the metal. You got away from the DOM. You got away from what browsers actually implement, so all we can do is give you, like, developer tools to help you out and source maps to get from where you actually wrote to what’s finally executed in the browser.
Then you got the innovative blocker. “Browsers and Web standards are too slow and don’t give us enough control. We want to know what’s going on and control every part of the interface.” This is where, like, the Reacts come in, the virtual DOMs where we render everything in JavaScript and spit out one HTML document at the end.
“CSS is broken. The DOM is broken. We have the technologies in our evergreen browsers to fix all that reliably. And we have insight into what’s happening and we can optimize it.”
This is a high fidelity, beautiful, responsive interfaces. These are really, really cool interfaces if we think about it. I’ve seen great stuff in those of coming out of that mindset, but it actually locks out a large group of users, and we see a lot of talks about how the Web is becoming more international, and people can’t afford iPhones and they can’t afford anything else.
We assume that everybody has access to a high-end environment, and we leave others out. So any environment with that high level of control also comes with a lot of responsibility. It’s your job to do whatever a browser does for you. It’s your job to actually make that accessible. It’s your job to make it performant.
You have the tooling. You have the insights. You know everything, but you also have to take the responsibility. I don’t see that very often. We just do the innovative thing and, like, oh, for our end users they should just buy a new phone, right?
Browser makers can take these new ideas and standardize them and help them with that as well, so this is not lost as well. I’m not saying that any of these things are wrong. I’m just saying quotes that I encountered over the last few years.
All of these parts have a place on the Web. All of them are invited to have their opinions, are invited to build things the way they want to. You can be hardcore and say, like, if Internet Explorer 5 doesn’t render your page, you are a terrible person. Or you can say, if you don’t use React then you’re not a Web developer. You have the right to do that. That’s totally okay. That’s the diversity of our market and our approaches that we forgot about.
This is huge. We changed from, like, a few kids that wanted to do Web standards and wanted to do have predictability on Web development to a whole world of JavaScript. I gave a talk at ScriptConf about how JavaScript is buffet and not a main course. You pick and choose what you want to have rather than having to know everything.
All of them result in better experience for our users in their frame of reference. A React developer will tell you that all their users love what they do, whereas somebody working for the NHS on Internet Explorer 6 says, like, our users, they use that. I can’t do anything else. This is what they expect. This is the interfaces that are best for them.
I think the difference is responsibility and support. On the right-hand side we give end users the responsibility or the ability to change the interface to what they need it to be. And the product runs everywhere. We don’t even think about it because we just control the server and we say, like, okay, the rest should go.
On the other side we have a high responsibility and a high demand on the end user’s environment. If they don’t have a fast mobile phone that is well connected with a SIM card right now, they might not get anything. This is what we should be talking about more. We should be interested in more who is responsible for what and not what technology you use. I really don’t care any more which abstraction library you use, which build scripts you have. I just want to know who is responsible for what and what do you do to make sure that when something goes wrong not the wrong people get blamed or don’t get an interface that they demanded.
Now who defines who is allowed to use our products? Like, oh, all users need to have an iPhone. We don’t have any blind users. Everybody should know English who uses these things. Like, oh, if you have a touch interface, nobody uses that on our device.
Who has the final say how an interface looks and what it is used for? The amount of times I see people on the Web, and me included, abusing interfaces for things they were not meant to do, that’s great. I love this innovation.
The other day somebody, you know, recapture that audio -- that audio -- that capture thing where you have to put in any distorted characters. It has a version for blind users where you can say, “Listen to it again,” so it’s the audio capture to make sure that recapture was accessible. Somebody used the audio output of that and sent it to the machine learning or the deep learning algorithm of Google that turns audio into text. By wiring up two Google APIs, they correct each other.
Audience: [Laughter]
Christian Heilmann: I love that people come up with that. I’ve been at universities where children use blocked websites by running them through Google Translate because the Google Translate server is not being blocked and it doesn’t send the headers forward, so it always looks like they just looked at Google Translate, although they looked at things that were blocked in their university or in the country that they’re in right now.
The W3C specifies that as a very, very basic principle of everything that is done there. “Users over authors over implementers over specifiers over theoretical purity.” This is the chain of command when it comes to designing anything in the W3C, and this is something we should start integrating more with ourselves. We should understand again, like sure, if our end users are on an iOS, it’s a terrible experience that they’re actually reloading every single time and they don’t get native controls that they expected to have. That doesn’t mean that you’ve given up on the Web and you’re a terrible person.
At the same time, it’s like if the end user has a problem because you wanted to theoretically use that cool, new version of ES17 on the client, that’s your fault. That’s up to you to actually go up to your users and explain to them why they’re actually being locked out.
We’re in this spin cycle of, like, innovation. Do more. Do more. Do faster. Write less. Achieve more. Move fast and break things.
This is stupid. This is burning us out. This is making us unhappy. We should not be the miners or the investment bankers of the ‘80s where we got demands all the time to do more and more and more in a shorter amount of time. It’s no wonder that we don’t have much diversity in our market if everybody has to be a young person with lots of free time and that’s happy to do something in the evening or weekends. This is not right. We have to grow up as a market and stand up to that.
Now if our users are the end goal, finding some best practices should go both ways. The innovative part should go back to the conservative one, and the advocates of a sturdy Web can learn from innovators, and vice versa. We should not be fighting over this. We all want to do the same thing. We want to build interfaces so people can do things and click on ads and make us money. That’s basically it.
Somehow that’s the biggest problem. We have no way of making money on the Web. Everybody wants everything for free, and that’s why native is supposedly winning. It’s not. Nobody makes money on native either. We actually live on borrowed money that doesn’t exist from BC companies that fund, like, sneaker things online or something.
Audience: [Laughter]
Christian Heilmann: However, we’re not quite doing that. We’re not talking to each other. All of these parts of our market are very dogmatic in their approach and, like, every time somebody does a React component, somebody says, “But it’s not accessible,” or, “It doesn’t work on my IE6.” And every time somebody says, like, “I’ve got an accessible interface, but it looks shit on iPhone.”
We don’t actually work with each other. We don’t understand that this is a spectrum, that this is a sliding scale. That thing between, like, what’s an app, what’s a website, has always been a sliding thing there.
We also have conferences for all of these things and they don’t talk to each other. I spoke at Angular conference. I never touched Angular, but I was happy that I could talk there and talk about things they haven’t thought of. We have React Conf. We’ve got CSS Conf. We’ve got JS Conf. All these sub-communities are basically talking to themselves rather than to each other, and this is why this is a conference that I really support because you’ve got the whole breadth of what we’re doing here.
Everything we do is a mixture of UX design, writing, coding, and testing, and many, many other things. It’s not just like one -- ten times a developer can do all of that. We should actually talk much more with each other, and that’s why I’m talking at a Drupal conference about CSS soon. Why not?
Now the developer mindset is actually fixing it. We love technology, and we see technology as this little hammer. When you have a hammer, everything looks like a nail. Sometimes a thumb comes in between, but that’s okay as well.
We really want to fix things, like that guy. I love that one. Okay, this is blinking. Probably just poke it a bit and then it will be fine. And, look at that. A few things, and he made it work, and everybody is happy.
Audience member: Oh!
Audience: [Laughter]
Christian Heilmann: And this is happening often enough. How many times have you just fixed a little bug in the front and then all of a sudden you broke a build script, or you changed a build script and all of a sudden some DNS server was not available any more?
One of my favorite interview questions when I hire people is, like, when would you not fix a bug? There’s great answers to that. There’s like, “It’s too easy for me to fix that bug, so somebody else who just learns to get onto the project should do that bug to get into the project and get a positive experience as the first thing doing in the project.” Or, “It’s Friday. I don’t touch shit on Friday because Saturday and Sunday nobody is here.”
Audience member: Yeah.
Christian Heilmann: Or, “I don’t know what is connected with that. I don’t know the dependencies, so by fixing that I might break 10,000 other things. There’s no unit test or no implementation test associated with it, so anything might happen.”
But we’re always like, okay, I can use JavaScript to do that. That’s why we have 10,000 polyfills for problems that don’t exist any more, but the polyfills are still on the Web and they’re being loaded. Load them on demand. It’s much, much easier.
Now we work in an incredibly creative, fast moving space that is in constant flux. I love that. I’ve been doing Web development for 20 years and, every month, I have to learn something new. Every month I feel like an idiot because something new came out that looks amazing. This should make me feel terrible, but I’m like, you know what? I interiorized it. I’m okay with it. I’m okay to be the idiot for a few weeks because that’s how we learn.
It’s a mess, but mess can be fun. I mean how much fun is jumping around in puddles and stuff? We should be embracing it in our technology approaches as well.
Working in a creative space needs a certain attitude. It needs relaxation. I want to quickly show you a video that hopefully the sound will work right now. I love watching “making ofs” of movies right now because YouTube has lots of--probably copyrighted things, but I don’t care--like making of, behind the scenes of movies. I force myself watching “making ofs” of movies that I hated because I’m a film snob. I love movies. I love. I’m on several forums where I rant with other people how bad that movie was, how good that movie was.
I felt like I’m actually doing -- am I doing this justice just by judging it the way I look at it? Then I realized a lot of these “making ofs” of movies that I hated, these are humans. People have put a lot of effort into that. The final product was basically bad because it had to be cut to get a certain rating or a certain time or the budget had ran out. It was not the fault of the people who made it, so I humble myself by looking at these things. But I find it more exciting. By looking at “making ofs” of movies, you realize how much work is going into a day-to-day movie, how much effort there is in there.
I watched Imagining Zootopia, which is the making of Zootopia, a great Disney movie, a Disney movie about bias and racism. I mean how -- I want to be in that pitch where it’s like, oh, yeah, we want to make this a movie about racism. What? Like not the old ones that were racist, like about racism, against them, like not Song of the South.
This Imagining Zootopia on that YouTube URL is really, really cool to see, and I learned something amazing in there. Look at this.
Animator: When you’re a storyboard artist here at Disney, you have to be comfortable with your work getting thrown away. All of us who board, who storyboard in this movie have done literally thousands of drawings that have wound up in the garbage because these ideas come in and they go out of the films very, very quickly.
And the idea with that is to be wrong as quickly as possible, so you really try to, you know, try out as many ideas as we can. Then when they right ideas really click in, then you’ll see, from screening-to-screening, they’ll start to build. The rest of the film will start to build around those key ideas. It doesn’t have to be very many, but just a few that kind of hold up the structure of the film where you can really lock in to, like, okay, that’s your character. That’s your movie. And then everything else builds from there.
Christian Heilmann: How cool is that? How cool is that approach? It’s so much more healthy than our approach of saying, like, everything we do has to work wherever and has to be, like, the JavaScript library to use instead of the other one that almost did the same thing.
When you know you’re being creative, you know that things get thrown away. But actually it’s a journey to find three things to make the movie good later one, the same way we can build 10,000 build scripts, 10,000 libraries, 10,000 abstraction libraries to understand which of the Web standards makes sense in a browser to be fully supported. But we need to be more patient about that. We need to be okay with things being thrown away.
I just deleted one of my servers: icant.co.uk. All my code examples from 2001 to 2006 to 5/17, lots and lots of broken, broken links because I didn’t want to maintain that server any more. Most of it was based on Yahoo APIs that don’t exist any longer. There was no outrage. Nobody nailed me to a cross for it. Nobody basically -- I got a few emails like, “Oh, where is that?” I’m like, “I moved that to GitHub. It’s available now there.”
It’s okay to let things die. It’s okay to let things go because they’re not necessary any more. I’d rather delete my old tutorial how to make layout tables before people find it again and do layout tables.
Audience: [Laughter] [Applause]
Christian Heilmann: Because we have solid foundations. We moved so far ahead on the Web, but we’re still bitching and complaining that things are not there yet and, oh, it would be so much easier if we had, like, the Flexbox everywhere.
If you look at the stuff that we have, JavaScript is unstoppable. Everything is JavaScript now, and I love that to bits because everybody complains about the language, and it’s been done in ten days, probably in a drug fueled rage by Brendan Eich, like randomly put things in there. There’s a null, and there’s an undefined that drives every C++ developer crazy. I love this big hack that JavaScript is.
But it’s open source, and it has embeddable VMs now. You can use V8 and build on top of that. That’s how we got Electron. You can use Chakra Core and build something on top of it, which people should do. You’ve got Node.js and NPM. You’ve got a solid DOM access and traversal. You’ve got fetch, bark, play dead, and good boy. The others we haven’t implemented yet, but fetch is there.
Audience: [Laughter]
Christian Heilmann: And we’ve got promises and async/await, so look at these things if you look at JavaScript. Don’t point people to an AJAX tutorial any more. Fetch is here and it’s so much easier.
We’ve got query selector in DOM traversal. We’ve got now ways to actually use match media, for example, to do different -- to do media queries in JavaScript, which nobody uses and I don’t know why. It’s actually a really, really cool idea. We’ve got so many good things going on in Node.js and NPM, it’s not even -- I can’t even take it in any more nowadays.
How cool is CSS? We’ve got transitions that make everything look smooth. You don’t even know -- need to know it. It’s four milliseconds between this and the other state. I don’t want to know these states. I just know it’s going to look smooth now. Okay, smooth to a degree. Probably every animator now kills me if I start to say that just four milliseconds is fine.
We’ve got animations, and animations interact with JavaScript as well, so you’ve got your on and transition end and on animation end, so you can actually time them and lock them one after another. We’ve got the Web animation API, which is another one to do the same thing. We’ve got Flexbox, of course. We’ve got grids. We finally got grids. Remember when Internet Explorer got grids and everybody was like, man, whatever?
Audience: [Laughter]
Christian Heilmann: Now we’ve got grids and everybody is like, oh, cool. We got to have grids.
I’m so happy for Rachel and for Jen who basically have been talking about grids for years and years, and people are like, yeah, whatever, you W3C monkeys are never going to come, and now it’s in every browser. They’re like, oh, cool, they have all these tutorials for the last five years that I didn’t care about.
Audience: [Laughter]
Christian Heilmann: And we got custom properties and variables. Well, variables is -- the real name is custom properties, and this is the coolest thing ever. I mean by being able to access a custom property in CSS via JavaScript, I can get computational values into my CSS without going through Sass and without doing any rendering problems.
Leah LaRue gave a talk about this at CSS Day, and I know her talks are daunting, but this one is great. This one is very, very on the spot explaining every single thing you have to understand about CSS custom properties. I can only--
Go home. Watch it. Not now. Just watch the talk today. But when you get back, watch that video. It’s really, really good.
How much of a great opportunity are progressive Web apps? I’m not going to talk about that now in detail, but I’m going to give a lot of talks about this. Just having a manifest, a standardized W3 manifest, not a Web OS manifest, a Firefox manifest, a Chrome manifest, a whatever manifest. I think there was a communist one as well.
Audience: [Laughter]
Christian Heilmann: We have now a standardized way to tell a renderer that this is an app and not only a website. And we just announced that Bing is now indexing the Web and finding PWAs by indexing these manifests instead of putting a header thing in there like we had to use in iOS. These are great.
Service workers is of course amazing. You can do your offline functionality. You can do pre-rendering. You can do everything in another thread because even the page renders. This is proper progressive enhancement. This is not something you expect to happen. If it doesn’t get loaded, you don’t have that functionality, but it’s not in the way of the end user.
How amazing are our developer tools? In-browser tooling: Chrome dev tools, F12 dev tools, Firefox dev tools. By now you actually have to read books about understanding them, the amount of insights they give us. I remember when alert was the thing that was the only thing we had, and then you ended up in the for-loop and pressing the Enter button 500 times.
Audience: [Laughter]
Christian Heilmann: We have this now, hackable editors written in Web technologies. I’m working on Visual Studio code, an editor written in typescript that I used to write typescript with. How awesome is that? Extensions that are compatible between Atom and VS code and other editors. Tool chains to produce what we need when it makes sense and not all the time. Webpack, Prepack, Grunt, Gulp, Broccoli, whatever is out there, all these things are there for you to build things when you need them.
How easy is it for us to stay up to date? Browser makers are available for feedback and information. It’s not the black hole any more where we feed developers in the basement from time-to-time. We’re all open in public, and we answer your questions.
We have collaboration tools by the truckload: GitHub, Baseboard, like all the things where you can work with other people live in the environments, like Slack, Mastodon, all the things that we’re using. We have more events than I can count with published videos, so watch these videos.
Take a time out in the office and bring some cookies in and watch a great conference talk. Then discuss in your company how you could use these technologies in your day-to-day products. That’s an hour of productivity that everybody can benefit from. Watch these videos. We do a lot of work to make these videos happen. I watch them on trains. I watch them in the gym. I learn something just by downloading them onto my iPod and going with it.
It’s time to fill the gaps of the Web. It’s time to realize that not everything we do is lasting forever and it needs to add up to a perfect solution. Let’s not be dogmatic about our stuff any more.
It’s okay for our accomplishments to vanish. It’s okay. I don’t care if people are excited about my 2006 tutorial on AJAX. They should not fight this any more because it’s dead. It’s not a good way of actually doing HXR nowadays now that we have fetch.
It’s not okay for them to become landfill of the Web. It’s not okay for our stuff to stay forever and be successful and give people bad information.
Our job right now is to create interfaces that are simple, human, and fun to use. That’s our job. What you use for that, I don’t care as long as you keep people in mind.
Inclusive design is a big, big thing. There’s no thing as a perfect user. Think inclusive. This isn’t about allowing access. It’s about avoiding barriers. That’s the biggest thing that we don’t do at the moment.
All these things come together. No matter where you are on that spectrum of Web development, together we make up what we do for end users out there, so we’re not siloing. There’s no point in being dogmatic about these things.
Think about what W3C defines. “Users over authors over implementers over specifiers over theoretical purity.” This is a very simple thing to think about. Your users are the ones that make you money, not your tool chain creators, not you yourself because you don’t want to spend money on that stuff.
We have come a long way. We made the world much smaller and much more connected. I don’t have to get photos in the mail any more. I can connect to you 24/7, all the time. All the speakers here are available for you to pester afterwards. We have this wonderful gift that is the Internet, and we still have it. Governments are doing their job right now to actually make it only for the rich people and sensor it and all kind of things, so we should think about that as well, but I’m not putting that hat on today. But we came a long way since that.
Things are looking up. I can’t wait to see what all of you together will actually make with this. Think about it together, most of it. You don’t need to be the rock star ninja developer. You don’t need to be the next John Resig. You don’t need to be the next Paul Irish. You don’t need to be the next whatever. It’s like you can work together to build amazing things.
Let’s storyboard the next Web. Let’s not do it. Let’s not build it. Let’s storyboard it. Use Codepen, use JSbin, use all the fiddles that we have out there. Give feedback on standards and browsers features. Do little steps. Do one thing to move towards that goal.
Don’t try to be frustrated because it doesn’t work immediately because this is not how the Web works. This is not how working works. This is not how humans work. Little steps and doing things that get thrown away and don’t hurt anybody, and learning from it and taking the learning to the next step is what we should focus on.
Let’s stop fussing over minor details and show more love to the Web, more love to the craft, and much more respect for another. I’m tired of bickering. I’m tired of people just finding just one argument to say, “But your product is shit because this.” This doesn’t get us anywhere. We should b working better together and have more respect for each other.
You don’t owe the world perfection. We think we do. We’re always like, oh, it’s not perfect. I’m not going to release it.
You have a voice, though, that should be heard, and your input matters to everybody, so get creative because no creativity is a waste, no matter what you do. As long as you’re being creative and you let your brain play and you shared it with other people, let them go ahead with it. It’s not your job any more. You don’t owe the world perfection.
Thank you.
Audience: [Applause]
