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.
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.
“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.”
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.
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.
“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?
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.
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 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.
“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.
“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.
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.
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.
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!
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.”
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.
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.
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.
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.
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.
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.
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.
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.