I was once again a guest at devchat.tv’s “My JavaScript story” podcast and Charles Max Wood grilled me on Edge moving to Chromium, how I got into programing, blogging and what products I was happy to have contributed to. We also pivoted into events and online videos, how amazing our current development environment is and what not to do to discourage others from working.

You can check the podcast on the devchat page and here is a transcript I created with AWS and cleaned out a bit by hand.

Slightly cleaned up transcript

[MJS] Hello everybody. And welcome to another episode of my JavaScript story. This week we’re talking to Chris Heilmann. Chris, do you want to say hello?

[CH] Hello.

[MJS] Now do you want to just quickly remind people who you are; what you do.

[CH] I’m Chris. I’ve been web developing for about 20 years. I worked for lots of agencies that created large websites. I then started working for Yahoo and from Yahoo went on to Mozilla. Worked there on Firefox, Firefox OS and a few other things and the MDN docs. I went to Microsoft four years ago where I’m currently working at the Edge team. Releasing the new browser and basically making sure that Internet Explorer is not a thing that we need to use all the time. We’re actually up to date and bring in lots of enterprise customers to the new web that way.

[MJS] Edge made an announcement that you guys were moving over to Chromium. You want to just briefly tell us about that before we get into your story?

[CH] It was a very pragmatic decision. We thought, OK, what do we do? We have a browser that people want – Edge – as a replacement for IE. We thought everybody would upgrade to Windows 10 to get the new browser so we didn’t make it backwards compatible with older Windows versions. Then we realized that didn’t happen as much as we wanted it to. But we realized that the browser is basically much more than the rendering engine. It is the services that come with the browser and the UX/UI. So we thought, why not actually shift to Chromium, where we can be on all the Windows versions, on Mac and everywhere else where the Chromium engine runs. The other thing that we found interesting as a challenge is that Chromium runs the Web. It’s powers not only Chrome but also Electron. So we thought, okay, if this is an open source project and it’s the de facto web, there should be more than one big player in there. And that’s why we thought we give it a go. Now we’re actually part of the Chromium project. We put in hundreds of pull requests already, we met with the Chrome team and they were quite excited how far we’ve come in half a year releasing our browser on the Chromium project. So, personally for me as an open source person and open web person, I find it sad that we have one engine less, but I find it much more interesting for the future of the web that the engine that the web runs on is not owned by and mostly contributed to by one company. That makes sense.

[MJS] I’m a little curious. Are you moving off Chakra to V8?

[CH] Yes, we do. The thing is, it comes bundled with the Chromium engine. And the main thing is also that we found even with ChakraCore, when we released it that we had to release a lot of shims to make it compatible with what people are writing. A lot of, especially Electron code, is catered to V8 and not necessarily to the EcmaScript standard. So we had to find a lot of ways to actually make that work. And we realized instead of putting all that effort into making things work, it makes more sense to contribute.

[MJS] So let’s talk about you. How did you get into programming?

[CH] I always was fascinated by computers. I was fascinated by them as a kid growing up watching movies like Tron and I’m like, “this is so cool, this is a different world!”. I guess because that movie was basically telling me there’s a world inside computers, and I’m like, “this is awesome”. So I started very early on by getting my first computer on a flea market and started writing BASIC. It was a Commodore 64. So I actually learned Assembly language and started coding little games and intros and these kind of things for the demo scene. I realized out of a sudden that there’s actually a career in that as well. But I didn’t start as a programmer. I started as a radio journalist. I was a newscaster at a local radio station, and coded and wrote little games and stuff in my free time. Then the Internet came around, and I’m like “This is amazing! Now I can use my media knowledge, my media affinity and my programming knowledge to get a job!”. As I was one of the first people that actually built websites in my area and then later on Germany wide, I got a good contract with BMW to work for them, and that’s how I got into web programming and the web as a whole. So it’s a “the right moment, right time” scenario. I never been to university. I didn’t finish any proper job education – I was just lucky.

[MJS] I guess that’s cool. And it’s interesting, too. I know a lot of people that didn’t get a degree. And then they ended up working on the web, so and I hope that keeps up.

[CH] I love that a lot of people come sideways into the market and not like in a normal “You become a Web developer by doing this course. Here’s your degree, and then you get a job” way. I’m now interviewing a lot of developers in Africa where we just opened new offices. It’s amazing how hungry people are and how wonderful the web is as a first career for a lot of people that would not get any other job that easily. A job that is exciting and that flexible.

[MJS] Yep, absolutely. I’m curious. A lot of people who got into the web a while back started with a backend language, or HTML, and then they wound up moving more toward the front. Was that your experience? Or have you always been mostly focused on JavaScript in the front end?

[CH] Well, seeing that I was so excited about building things, I was always about visual things. JavaScript was a very early thing that I was interested in, and it was also a good, easy start. It was a good career move at that time, as I was doing DHTML. DHTML times were basically writing pop-up windows that wrote frame sets with document.write inside those pop-up windows and then three windows had to talk to each other because we simulated apps that way back then. And luckily enough, sooner or later we got W3C standards, especially the DOM standard, to get rid of all these horrible, horrible hacks we had to use.

But it was exciting for me as well, cause I was a lot on public transport and trains. You basically didn’t have access to the servers and JavaScript was something that for me always worked offline and on the file system or on a local server. I also started with Perl. Then, later on, I did a little PHP development. I wrote a few PHP CMS like, I guess, everybody did. And then I realized that JavaScript is becoming more and more interesting to me, but I’ve always been more fascinated by the UI part of JavaScript. To do things with it to make it easier for end users to use systems and avoid having a reload of the page while still being accessible. The first tutorials that have written and published was “Unobtrusive JavaScript” to explain to people how to use JavaScript, that is just an enhancement rather than relying on it. Because a lot of solutions back then relied on JavaScript and you had links that pointed to “javascript:” so you click on them and if some problem happened, there is no functionality. From the very beginning, I wanted to make sure that people use JavaScript in a nice way for the end user and to use it as an enhancement instead of asking them to upgrade their browsers. Flash was a big thing, the message was that “Everybody has Flash”. Turns out it didn’t any more when the iPod and the iPhone came out. So that was a bet that was great for quite a long time to make money. JavaScript is still here, but I still think it’s up to us to keep using it in a sensible manner and not just like because we can.

[MJS] Yeah, I agree. I’m curious. So you get into JavaScript. You said you’ve been fascinated by the UI part of things. I’m curious, you know, as your career progressed, how did that play into things? Because you mentioned before we got rolling that you had worked for Yahoo. And, um, you know, a few other companies and people have heard of and you know, now you’re a Microsoft. So yeah, how is that all translated into your career?

[CH] Very much. I mean, we always need interfaces in the end. Something has to be there and actually run. And the more we can do on the end user’s machine, the less server traffic we have. Nowadays, it’s much easier with the fast connections that we have and how cheap hosting is. But when you worked, for example, in Yahoo and you had, like, 3,000,000 users using the front page, every byte that you can safe is a good idea. So, being a good JavaScript engineer in these companies made a difference in the performance of the thing and also in the traffic.

Yahoo was a very interesting one because I used JavaScript professionally for years and years, and I got money for it. People thought I know what I was doing and I thought, I know what I was doing. I wrote my first JavaScript book in 2006 about DOM Scripting and AJAX - the first AJAX book actually – and it came out. And luckily enough, a few more came after that. When you start writing a book, you realize you actually cannot fake it any longer. You have to actually know what you’re doing, and you have to explain it to people. So you have to explain it to yourself first. In Yahoo, I was super excited to work with people like Douglas Crockford and he was one of my first code reviewers in the company, which is scary, but turned out he was actually quite okay with what I’ve been writing. And then I worked on the Yahoo User Interface library (YUI), which is now kind of like “farm sourced”, you know, it’s out on the farm with the other open source libraries where somebody maintains it, but we don’t know who. But the team that was on YUI was just an incredibly amount of colleagues that were super intelligent. What they were doing was one of the best documented libraries at that time. Everybody that I worked with back then is still a big number in JavaScript, like Nicholas Zakas. A lot of people went to other companies like Salesforce, where they do component libraries. I also worked with the Flickr team, which innovated a lot of great stuff in 2006. They are now at Slack. It basically shows that when you’re interested in building interfaces for end users, you have to talk to so many more people than when you just build back end code where you have to talk to a database and the server. And hopefully you get a spec from the business analysts that the product manager and you have to turn into something.

It is different when you build interfaces. It’s already a conversation, and that means you have to talk to more people in the company. And that is actually good for your career. Because sooner or later we have to interact with humans.

[MJS] Ultimately, remember what you are building has to help someone with solving problems. You have to be aware of the interface, even if it’s some level out from your work.

[CH] I am always annoyed about the fight we have between front and back end and fullstack development. Whenever there’s an argument between CSS and JavaScript, it just fascinates me. To me, a good product on the web uses JavaScript, HTML and CSS, and all of them to their best degree. All of those technologies for what they’re good for. I find it depressing that over the years, CSS and JavaScript have become kind of like parallel technologies to do the same things. And JavaScript is always the one that gives you more granularity and actually more responsibility. So it’s very easy to build a broken interface with JavaScript. It’s much harder to build a broken interface with CSS if you know what you’re doing. And the main thing people complain about CSS is that it is not like JavaScript then I think “Well, yeah, that’s by design, that’s a good idea”. So if you’re not interested in how a technology works, why do use it and become unhappy? This market is big enough for us to collaborate with other people and in essence, that’s what you want to do if you want to build a product that is sustainable because sooner or later you will be sick or you have to get out and somebody else has to do your bits. You want to be interested in the things that you do so dragging that whole stack with you. If you keep saying “I’m the JavaScript developer, but I also need to do the CSS and I hate doing it”, then don’t do it. That’s the main point, cause you will not do a good job. You will basically use the technology in a fashion that it was not meant to be much like when, when back in the jQuery days when I interviewed people for JavaScript jobs and they’re like, “Well, I only know jQuery, I thought you needed that”. And I’m like, “Well, no, we don’t write a browser in jQuery”. This is not how it works, right?

[MJS] So how did you get to a place where you were actually working on browser technology instead of building Web applications?

[CH] Well, I build Web applications for a long time, and I found that the browser is a lot of times the reason for issues we’ll see. Most of the blockers and the confusion moment to me was browsers issues. Browsers were black boxes, when you didn’t work for the company, you had no access to know what’s coming or what they’re doing. I was really excited when Firefox came around. And when other browsers followed suit and all the browser makers worked in the open. Out of a sudden, they’re available on the Internet for you to give feedback to and in some cases contribute back to the browser. And I thought, OK, “I’ve done the building products thing, someone else can take that away from me. I’d rather go where the problems happen and where documentation is needed and where information flow is not as good as it should be”. And that also included developer tools like course. When browsers started building developer tools inside the browser, I realized there is a great opportunity there to help developers, and I wanted to be part of that. That’s why Mozilla and Firefox was a great company to work for. Everything is open and you have to work in the open. You learn to contribute and you learn how to deal with contributors and with demands from people.

I found that for my career, it was not necessarily the most amazing. I could have started my own company, become a CTO and get VC funding. But I I’m very happy, having contributed that much back through these products to the people to empower anybody to become that. I found the next interesting step for me forward in technologies to support were browsers, developer tools and developer environments like Visual Studio Code. And these kind of things are all written in the language that I learned back then. I don’t know C++ so I couldn’t contribute in the past. Now that most of these things are written in TypeScripy, it got much more interesting for

[MJS] I’m curious. What projects have you worked on that you’re particularly proud of or you’re excited to have been a part of?

[CH] I’m super excited about Visual Studio Code. I haven’t worked that much on it directly but I’m helpful with the documentation. I wrote a few and add-ons to the operation of the system itself. I also worked with Adobe people on Brackets before, one of the other editors that run in the browser. I think that was the big breakthrough for front-end technologies in the developer space. Visual studio code has taken the market by storm and with good reason because it gives you the functionality of a huge IDE with the lightweight environment of a text editor. And I’m very excited we have this kind of product. I also thought YUI was a breakthrough in the library space back then because it was highly documented. It was backed by a large corporation that actually put a lot of money and effort into it rather than a product that then grew wild in the open source space. So that was a really good one as well. Firefox OS was really exciting to work on as well because I think what we have in HTML5 space now across browsers like, camera access, media access, starting off things like web workers and service workers and local storage came from that research. Mozilla took the took the stance of saying “We want to build an operating system on HTML. I know it sounds crazy, but we’re going to do it”. This was this was a exciting time to work there. I think there’s a lot of products that over time changed the web and this was one of those that kickstarted it. I wish I had worked more on Chromium when it started. I wish I had worked more on a few other things, but I mean, you could only do so many things.

I always got more excited about the documentation of things and the making it available to people and write the training tutorials for other people to get into a certain technology that necessarily work on the technology itself. I think that skill set is not as common. It’s really hard to find somebody who is technical, can write the thing but also document and explain it to other people out there. Make it available for people and understandable to people. And I wished our community would appreciate that a lot more as well, because that’s a great way to get our community a bit more diverse. If we gave people who wrote documentation and make things understandable to other people the same respect we gave to the original developer, I think we would have a more diverse and interesting market to play in.

[MJS] Yeah, I love the idea of just opening up more things to more developers. It seems like every time we have a breakthrough where you know, some capability comes out, people find new and interesting ways to take advantage of it.

[CH] Yeah, and the Edge thing, of course, was a huge one for me. Microsoft tried to hire me for years and years, and I was never that interested. Then, they offered me a job working on a new browser, that was just a secret back then. They were going to re-write the browser from scratch, and get rid of Internet Explorers as the main browser. And I’m like, “Yeah, I’m happy to help you with that”. Because I want to go where the change is needed. And when Edge came out, it was a much needed change because IE 11 was basically on a maintenance mode. And as much as we despise it, there is a big opportunity of having a browser that’s part of the operating system. People don’t want to understand and don’t want to download another browser. There’s a lot of people that are happily going to the office at nine o’clock in the morning, turn on the computer and click on one icon to open the 10 websites that they have to work with and maybe a news website out there. And we might think that those people don’t contribute to the Web, but a lot of them work on products that are incredibly important. I just helped an insurance company shift 70,000 machines from Internet Explorer to a modern browser. That’s 24.5 million end users that now that will get richer and more interesting interfaces because the developers of that company can now rely on a better base to work off from.

[MJS] Yeah, that makes sense. Is that primarily what you’re working on now, or do you have other projects?

[CH] I’m working on the browser as my main job and I am on that team. I’m working with the Enterprise team to do a lot of outreach for customers like that, because it’s also quite useful for me sitting in Europe when the rest of my team is in America. I got a lot of especially German and French companies that don’t necessarily want their data to go somewhere in the US. They’re super excited having somebody local to explain to them where their data goes and how to work with them. I’m also a part of a W3C discussing group where we’re trying to get machine learning into the browser, creating a native API to do machine learning and to also use pretrained models in the browser. So that’s something I’m actually very excited about because I think machine learning is to me the next evolution of development. I gave talks about this and I really believe it as well. We always get excited about, that as a coder, we’re never replaceable. We’re not automatable. But then when you look at what we’re doing, what we’re building these days, there’s a lot of websites that all look the same. There’s even a lot of apps that look the same, and these could be done by a program. A program could write or generate these things. Companies like Wix and SquareSpace, who I’m working with, are actually using machine learning in their interface builders to see what their end users want. They then build code on the fly, without somebody having it to code it by hand. When we think about the node environment, most people use lots of NPM packages and then put a little code on top off that. An algorithm could choose and pick packages and even make sure it is the right package and not something with the wrong name that just tries to be the on. I don’t think that hard core programming will stay relevant for a long time, cause machines have become clever enough. Re-use in development has become intense enough that we can actually cover 90% of what we need to do for end users with computers. We then can use 10% in a very creative fashion, which we should be thinking about what to do next. And I think bringing machine learning to the world It’s a very important part because a lot of “artificial intelligence”, as we call it is basically sold as dark magic and we don’t know where the data goes. We don’t know where the data is retained. Democratizing that and bringing that more into an open source environment like the web is a very important step for new technologies.

[MJS] Yeah, I’d love to see. I mean, what you’re talking about makes a lot of sense. And yeah, you know, if it’s just data and data out, you know, displaying it, there’s no reason why an AI couldn’t just do that.

We’re all we’re all super excited about re-use. But then we always claim we will always have to write everything by hand. “Don’t repeat yourself”, should probably something we do with our tools as well. Cause as much as it sounds boring to me to use other people’s code to stick it together and put something there, it’s quite impressive to see what people are doing. It was just at some conference where this 11 year old kid used Tensorflow to do hand gesture recognition on his camera. For him was just a normal way to build things. He didn’t even know, he didn’t even think about building something from scratch. It’s like “Oh, there’s all these cool Lego bricks that I can put together and make something out of it” instead. I love that because it means that people can build products. They don’t need to be a hard-core programmer to build any a simple product like a mom and pop shop or a little app for your friends to actually meet in.

[MJS] Yeah, absolutely. So when we brought you onto this show we brought you on, I think was episode 3 32 or something close to that. We talked about, ”you learned Javascript, now what?”. How long have you been blogging?

I’ve been blogging since 2006, so, yeah, it’s been a while.

[MJS] And how do you decide what to cover in your blog?

[CH] Oh, it started as a scratch pad for myself. Every time I found something out, I just wrote a blog post about it, explained it to myself and share that with the world. And that was a really successful way of writing a blog. People are really, really thankful for that. And I find myself whenever I forgot something and type it into Google, I find my own blog from, like, five year. It’s an interesting thing, but I think your excitement should run your blog. Not like what gives you the most click-throughs and what gives you the most ad revenue. I gave up on ad revenue on my blog. I used to get some good money from my blog. There was a good secondary income. It wasn’t amazing, but at least it was four digits per month. Nowadays as most people have ad-blockers, it just wasn’t worthwhile for me. I didn’t want some third party code on my blog that actually might do things to my readers that I don’t know. So I don’t care. I turned off the ads and my RSS feed has the full block posts in it and no “please come to my site and subscribe to it”. I see the Web still as a wonderful collection of destinations and not like something you go and you have to stay in.

[MJS] That’s cool. Where can people find you?

[CH] Christianheilmann.com It was interesting because I cross post a lot on Medium as well. Medium has a beautiful interface for people giving feedback in context. A comment option I don’t have to maintain and delete spam and malware links in. A lot of people got angry when Medium changed to the model to a paywall as they can’t read my posts there. Well, there’s no free. Sorry, how many times do we have to go for the bait and switch to understand it? I got a free account for medium cause I wrote for them. So they asked me “Here’s your free account. Can you keep writing for us?” Every time when somebody complains about the paywall I explain that the thing’s on my blog as well. Because nobody stops me from that. I write on my blog first, and then I publish it somewhere else. Nobody can stop me from doing that. If I get paid to publish something at a certain channel, of course, I shouldn’t put it for free on the blog. People need to make the money back that they gave me, but that doesn’t happen that often. There’s more money in video courses.

[MJS] Yeah, that makes sense. I remember seeing the, um there was a little bit of drama out there about freecodecamp moving off of medium. You know, who owned the articles and things like that, but you know, I think everybody has to make their decision based on what’s important to them. That’s just business. That’s life.

[CH] And it’s weird, isn’t it? We always complain about ads, and then we put that blockers on our browsers. We then complain about ads becoming more intrusive. Well, they’ve got to make money somehow. I’m spending about $100 a month on patreon on where I support different products online. And I think it’s okay, I can afford this. And I think that makes sense. I don’t want the things that I love being covered in terrible ads.

[MJS] Yeah, that makes sense. And it’s interesting because I mean, I haven’t gotten a complaint for a while about the ads in the podcast, but yeah, it’s the same thing, right? I’ve had some people come to me and basically tell me what I should do it with the ad revenue. I’ve had people come to me and tell me I should get rid of the ads, and it’s like, well, if you want me to spend the time on this, I have to be able to he pay, you know, electricity to my house things for my kids and stuff like that. So, yeah, it’s almost like opinions are cheap, right?

[CH] I organized one event in my life, but I helped a lot of events and help the events in my company. And I’m getting very tired of people publicly accusing events for doing something wrong rather than doing something about it. If you know better and you want to contribute, most of them want you to contribute. It’s easy to criticize after the fact. I just wrote a blog post about that: We’re super excited about pointing out flaws in technology and flaws in products, and we don’t even know what led to that fault. Most of time, it’s not the developer. It’s not the JavaScript person that wanted to use that horrible pop up or modal. It was third party code chosen by some marketing or sales person added on top of what you build. We’re not in control of the products that we put on line as soon as they get a certain size. There’s a lot of other people involved. And when you talk to people Harry Roberts and other people who do performance tests they say horrible things are often not the original code. They’re actually the third party things that get put on top of your products. And that means you as the JavaScript person should start looking who else is actually maintaining that thing above you and undoing all the good that you’ve been doing in your performance environment.

I love that we have a different environment for testing these days. I worked with webhint and we worke closely with the people who create lighthouse now that we’re on Chromium as well. It’s just fascinating how well documented and how wonderful our development environments are. Now, when I have Visual Studio Code, I don’t even make silly mistakes anymore. The editor tells me when I’m making a mistake before I save it and put it to my server. And that’s just so much better than learning to be the debugging god. Teaching people best practices or even like proper syntax while their coding, rather than like while they’re debugging, is a wonderful way to become much more effective. With environments that we have right now, you could do all kind of testing on the fly. We have headless browsers. You can use the command line to do automated tasks and automated testing. Crazy things like doing screen shots with headless browsers and then overlaying them and getting the pixel distance of different renderings with different browsers. It’s just a wonderful thing to see, and we never been more effective. People are always trying to find the next exciting thing. Here is a really exciting thing for you to look at. The automation of the web that we do right now is not quite there where it should be it. And there’s a lot of stuff to be explored in this environment.

[MJS] Yeah, I agree. And it’s funny because I talked to people that have been programming for a long time. I remember even 10 years ago where the tooling was at and the situation. You know, where the browsers were at. Some of the issues people don’t even think about anymore because they’ve just they’ve been solved.

[CH] People coming from other environments as well are interesting to talk to. People whose use Visual Studio, like C# or Java developers. They show me how they’re using the environment and what they expect from a development environment to cover before they even start writing code. Where’s we’re like, yeah, text editor and browser. That’s all I need. But we’re building very complex things these days and people’s identity, security and money, in the long run, are dependent on how much quality we put out on the we. People are relying on us to actually do something amazing. I think it’s not right if we get super excited about what we could do for us, as developers, to do things faster, and don’t care about the quality. In essence, it boils down to privacy, security, accessibility and maintainability. These are the four things that make a product interesting. The rest is just nice to have, and the rest is actually more and more in the hand of marketing and the design department to do it right. To keep it secure should be one of our main concerns. And most of time we don’t even know what we’re using. We’re like, “Okay, I got this 150 PM packages that most likely haven’t been updated for half a year. But I don’t want to think about an update. I don’t want to make it easy to update. I got the thing done I want to move on to the next one”. This just a very cowboy way of coding, I think.

[MJS] I need to move us into the next segment of the show, and that’s picks. But before I do that, how do people find you online? You already mentioned your blog.

[CH] Yes, ChristianHeilmann.com. I’m also on Twitter as @codepo8 and I hang out on a few channels. You can also reach me with the @msedgedev and @webhintio accounts, but @codepo8 is the best.

[MJS] Cool. All right. Well, do you have some picks? You have something you want to chat about?

[CH] Well, VSCode is my fave, but I don’t have to shout about it anymore. Just stay up-to-date, there is cool stuff happening. Webhint.io is something I’m working with the team, especially right now. That’s also something that is now an extension for the browser. It is basically like lighthouse, but it’s much more configurable. You can actually turn things on and off that you won’t don’t want tested, that are not necessarily applicable to your product. And also it means that you can write your own test. If you need to check that every website has a picture of a leprechaun in the footer you can write a simple JSON object to test that in a continuous integration environment. This is something that gets me really excited. I also want to say that I’m just amazed how far some of the publications online have com. CSStricks.com do amazing things these days. Dev.to is a super interesting little channel for throwing out little blog things. If you want to be part of that environment, they’re super nice people. I’m learning a lot from from codepen.io. They’ve been around for quite a while, but it’s just such a creative environment and not just a resource like JSbin or JSFiddle. It’s not something where you just put up code and see if it works, people are creative with technology there much like how they used to be with Flash. They do a lot of stuff on code pen right now, and write articles around it on how they’ve done it. So that’s something that I find really fascinating to me. And when it comes to channels where to go to learn things. Every conference I go to releases the videos, and I’m always fascinated by how few views those videos have. There’s a lot of money being spent on producing talk videos on mixing the slides in and then publishing them on the Web. I think it’s worthwhile to a lot of people to watch these things if they don’t have the money or the opportunity to go to events like that. Most of them are available for download as well if you’re in an environment, where streaming is not a thing for you. I put them actually on my mobile phone. I download a lot of mobile phone. I watched them in the gym, so on a cross trainer 40 minutes JavaScript talks are like 600 calories and it’s better than watching two more episodes of a stupid TV show you’ve already seen.
:

What I didn’t mention, which is terrible as I am clearly not a good sales person, is microsoftedgeinsider.com. There you can try the new Edge that we’re working on right now. On Windows and Mac. There is a nightly Canary build, a dev build and a beta build. We need other people to kick the tires and give us feedback. There’s as a wonderful little smiley button in there. So if you find any problem on any website, you could just click the smiley button. It automatically generates a screen shot off the website that you been at . All you have to do is describe the problem that you have and it goes directly to the right people. And I think that’s a feedback mechanism I wish more products offered that directly to the end user.

[MJS] Nice. Well, um, we’re pretty much out of time, but thanks for coming and talking to me for the last 45 minutes.

The last weekend sucked and made me reconsider a lot of things in my life. Instead of being on stage at the landing festival talking about great web things I had to go see my family for an emergency.

On Saturday we put the urn with my father’s ashes in the ground. That was a bad thing, but at least it was foreseeable. My father was a fighter. He survived two bypasses, and three rounds of chemotherapy. His bladder was gone and he was on oxygen support because of his failing lungs. A life full of hard work as a coal miner and factory worker took its toll. Smoking three packs of cigarettes a day didn’t help either. Still he prevailed for a long time, but he had no joy in life any longer. He had no hobbies, he had nothing to do once work was over. He spent his whole life working and providing for the family.

The more devastating thing me to see is that my mother is rapidly going through the different stages of dementia. Standing next to her as the remains of her husband got lowered into the earth and having her ask why we are there was a kick to the gut. Seeing the person who taught you Math and how to read and write fail at basic addition and substraction scares the hell out of you. Having to explain the clock to that person and reminding them that they already had food and that it isn’t the time for medication yet is also gut-wrenching. Especially when that person still is under the impression that the pills will make everything well again.

Everything will not be well again. How can it? Maybe there will be a bit of an improvement if the right chemicals rewire that wonderful brain of hers again. But, all in all, this is a downward spiral.

And while there is an overwhelming amount of information online telling us that dementia isn’t hereditary, it makes you think. A lot, in my case.

I am now 44 years old and I have had quite a ride. I’ve traveled a lot, I lived in many different places. I got sloppy, fat and lost the weight again. I was a vegetarian for a long time until my doctor pointed out that I lack a lot of things in my blood that a carnivorious diet can help with. I now go the gym whenever I can, I am a non-smoker, but I drink. Leisurely, of course, and I don’t like drinking at home. I am on no medication with the exception of hayfever pills in the summer. I am actually pretty lucky.

Seeing the two people who made me fade before my eyes still scares the hell out of me. What will I be like at that age? I am financially covered and the German health system has provided well so far for my parents. But what will stay of my thoughts and memories? What will I do when the things that make me excited now don’t mean anything any longer?

There are no answers, but there are a few things I want to do much more of and maybe it helps sharing those.

• I will live even healthier than I do now. I will be pickier with my food, say no much more often to alcohol and unneccesary sugars. I will take the stairs and go to the gym with a proper plan.
• I will have more checkups and look into a few things that feel askew with my body. Men suck at going to the doctor, I won’t be that guy any longer.
• I will find a physical hobby. Seems muscle memory is the last thing to go, so that’s a good plan. Don’t worry, I won’t write about it and flood you with instagram updates.
• I will live even more. If memories will fade, I want to have a truckload of them to start with.
• I will keep publishing what I do as open source and creative commons. Because if this brain is mush, others can keep the outcome alive
• I will do less and more sensible things. Maybe write a book again instead of presenting every week. Definitely focus more on my company and team.
• I won’t waste my time with toxic and overly needy people any longer
• I will start collecting more positive thoughts and tell the negative voices in my head to shut the hell up.

About the last bit. Two things that impressed me lately were a book on the matter and a talk. Let’s first have the talk.

Guy Winch’s “How to practice emotional hygiene” is a great, short talk reminding ourselves that cleaning up our thoughts is as important as keeping our bodies germ free. This is often as easy as distracting yourself when a dark thought of self-doubt comes and does help.

The book I enjoyed is Gary John Bishop’s “Unfuck yourself”. I am not a big fan of self-help books. Often they are too rah-rah for me and very “American” in a “you are a tiger, go and maul the world and your bad feelings” fashion. This one is much simpler. I managed to read it in a day on vacation and it comes with seven simple affirmations that aren’t only “you can do this”, but more of a “why the fuck are you doing this”. Gary has been a coach for decades and helped a lot of people with more problems than you and me and this short book has some good, practical advice.

So, anyone for collecting some good memories?

Under the intriguing titles Productivity Confidential: Artificial Intelligence – Friend or Foe? Fast Company just released a podcast where Ted Brown interviewed me.

You can listen to the podcast here:

I work as a remote employee with most of my team being 8 hours time difference away. Here’s a few things that help me a lot and I helped people with to ensure our working together is most effective.

• Keeping meetings with people in the same time zone as you to the middle part of the day allows people to meet with you in sensible times on their end. Often they need to contact you in your morning or evening.
• Shared online documents are an amazing way to get feedback and empower others to work on them when you are not available. Sending a document as an attachment to an email is just asking for trouble. All doc suites have tracking enabled, so you can see and undo changes.
• Things you need input on need to be accessible to the people you want it from. A shared document that requires the person you want to collaborate with on to request access is at least an 18 hour loss. When sharing, it is imperative to ensure the share is available.
• Any meeting should have notes of the most important points and action items for the people involved and the ones who couldn’t make it. It’s adorable that we have video recordings of meetings but nobody wants to scrub through and hour of video without changes.
• Anything only mentioned in conversation might as well be lost. Ensuring that there is a written proof what was said and done is a great way to avoid confusion. Having a note taker in meetings is incredibly useful.
• Keeping the banter to a minimum is great. There is nothing cute about sitting at 10pm in your office listening to your colleagues talk about the latest local sports event or any other thing only applicable to your office.
• Explaining acronyms can help avoid a lot of confusion. Having a resource to point people to what certain acronyms mean in your company is excellent. Things can lose meaning across different cultures.
• Connection requests are only working when they are detailed. “Contact Jessica in the $xyz team for more info” is so much more useful than “The $xyz team does that, you should contact them”.
• Communication requests should be as detailed as possible. “There was a date and time missing for the meeting and where should we host the document” is useful when you get it at 8pm. “Can you quickly jump on a call” is not. It is terrifying.
• Anything vague can easily sound ominous and sinister when you get it in the morning or late in the evening. Keeping the need for a meeting without a doubt and explaining expected outcome helps people start the meeting calm and focused.
• Having fallback contacts is a godsend. “Hey, I need this from you. If I am not available, Jeff (email) or Jessica (email) know about this, too, so I copied them in here in case I am not available”
• Setting an OOO and your status on Teams/Skype/Slack makes sure people don’t get a false hope that they could ask you something.

One of my favourite parts of CSS is the !important exception. It is a wonderful metaphor of the oft cited problem between CSS and JavaScript developers.

• As a CSS developer, you know to avoid using it. It makes things too important and hard to overwrite.
• As a developer that has to write CSS and doesn’t want to look deeper, it is the way to make CSS do what you want it to.
• As a CSS developer finding it in a code base, it means someone wrote it that probably shouldn’t have.
• As someone who doesn’t know CSS as all, !important means “not important”.

And this is what I want to write about today. What is important and what isn’t? I feel we lost our ::focus.

I’ve spent the last 20 years on the web as a professional. I built products, contributed to libraries and tools. I wrote my blog, talks and recorded screencasts. I helped others do the same. Through all this time, I thought of my efforts worth-while as the open web is an amazing thing to support. I love the web. I love how it empowers people and gives them a voice. I love how it gives people a new chance for a second or third career when things didn’t go as planned.

But I am tired of the constant bickering and false sense of importance we still have as web developers. When you open any social media channel these days you encounter all kind of fights:

• JavaScript vs. CSS
• Frameworks vs. VanillaJS
• Brevity vs. maintainability
• Tooling vs. low barrier of entry
• Client vs. Server vs. Isomorphic
• Mac vs. PC
• Native vs. Web
• Mobile vs. Desktop

We love to bicker about what people use and how they build things. We discuss what colour scheme they have in their editor of choice and which one is the most professional. We stay in our bubble and poke at each other and its walls from the inside. Not realising how petty and weird this is. Sure, it is rewarding to talk to your peers and find flaws to improve. It is also easier than talking to people who aren’t us. Or doing a reality check on what people use the web, mobiles and computers for. What is driving people? What do they expect from our products? What is a real issue, and what is a straw-man we keep erecting to tell people off for not following “best practices”? And – even more important – how much of an impact do we as frontend developers still have? Are we trying to optimise our own little world to the n-th degree as we don’t want to admit that we are not running the show?

Let’s recap how amazing the frontend world has become:

• We have evergreen browsers, many based on the same open source engine
• We have evergreen web views that allow us to build apps with web technologies
• We have open sourced, customisable editors and IDEs
• We have spaces to share code examples when we get stuck
• We have live, collaborative coding experiences that help us fix issues without lots of emails back and forth
• We have a version control system that is not terrible (remember SVN, CVS, Mercurial, Bazaar, Visual Source Safe, StarTeam…) and comes with hosting and collaboration tools
• We have dozens of events each month, many of which release the videos of the talks for free
• We have hundreds of online learning resources and interactive workshops
• We have superb documentation on all the tech we use and we even have in-depth documentation if something is safe to use across browsers
• We have dozens of hosting options, much more affordable than in the past. Many even come with automated setup of tools and CMS
• We have best practice documentation, design systems, style guides and component libraries

We should be high-fiving and congratulating each other on how far we’ve come since we wrote in textpad and FTPed our files to a live server. We should be concentrating on making this community better, more inclusive and welcoming. We should improve the tools we use and contribute great ideas from the past. Sure, it is frustrating to seeing a repetition of old mistakes. But didn’t we also learn by trial and error? It seems presumptious to expect people to learn our wise ways before creating something. And it is downright deluded to think developers hired to create a product get the time to really learn the craft first.

Instead of celebrating how far we’ve come we seem to be still in some weird competitive mode. When people release the smallest amount of code they use, we rejoice in throwing out truisms at them:

• “This doesn’t work if the data you put in isn’t perfect!”
• “This doesn’t perform when you have a lot of data!”
• “This could be written much shorter!”
• “This doesn’t work in old browsers!”
• “This should be done in technology x and you use y!”
• “This is not accessible!”

These are all excellent points and a perfect product should have considered them. On closer inspection these are knee-jerk reactions designed to make us feel good. Do any of these stay applicable when you look at the context of the product? Or are they a perfect scenario we keep chasing as our end goal? Shorter code that is harder to read and maintain might not be the best idea. What does “this is not accessible” even mean? To whom? Under which circumstances? You can easily remove one barrier for a certain disability or condition and involuntarily create a barrier for others.

There are no winners

If you zoom out far enough, you can always make a true statement that makes the original creator look bad. And you look clever and caring about the web and people. You win. But who loses?

We all lose in the long run. The original creators lose as they get painted as people who don’t care or didn’t think it through. Spectators, especially people new to market, also lose. Their first impression is that anything public is ripped to shreds. That can discourage them to show their work – something we always cherished as a part of the open web.

I’d go as far as saying that even you don’t win anything. Yes, you appear the better person, but you also get discouraged by everything you see. You don’t feel like a part of a group of professionals that evolve over time. Instead you feel like you keep having to repeat the obvious as people don’t listen or try to get better.

The odd thing is that we don’t even realise how much time we spend complaining about the work of others. Time we could use to do things, to create things, to learn things. Time to encourage others and to give feedback to prevent mistakes from happening. It is a spiral of unhappiness and “it could be so much better” thinking. It is not fun being the person who knows better and sees mediocrity wherever you look. It is also called being a snob.

The web is a mess

There is no doubt that something, somewhere goes wrong. It is baffling to see that even with the amazing stack of tools and development products the web is a total mess.

The web is slow and big. According to a research by Katie Hempenius based on HTTPArchive, 90% of desktop web sites load 5.8MB of data.

Page Weight Percentiles: overall & by resource type

If one of these categories is super high for a site, it's often an indicator that there's "low hanging fruit" performance wins to be had by optimizing that resource type.

(Data source: @HTTPArchive, Desktop Oct'18 data) pic.twitter.com/JSEsEUejE8

— Katie Hempenius (@katiehempenius) March 5, 2019

To make matters worse, this is an upward trend.

How many sites* are getting larger?

Over 1 year:

70% of sites got larger.
47% of sites increased JS by 100 KB+.
18% of sites grew by 1 MB+.

* Alexa Top 10K sites, July 2018 vs July 2017, via @HTTPArchive pic.twitter.com/nhiW8Mzd19

— Katie Hempenius (@katiehempenius) May 28, 2019

It doesn’t look rosier when it comes to accessibility. A research by WebAim that the one million most visited sites have glaring accessibility issues.

Add to this the almost weekly reports of data leaks and security problems on the web and we have something we should be pretty angry about. This is not the web we want. This is not the web we talk about when we bash “best practices” around each others’ heads.

Where do things go wrong?

A lot of talks and publications currently lament the over-use of frameworks. We talk about developer convenience overruling quality and performance of the final product. And there is of course something odd about using a 2MB JavaScript framework when the final product is a static page.

This is most of the time not the fault of the developers of these products, though. We love to paint the picture of the arrogant code-bro. A person who wants to always use the newest and coolest with plain disregard of the end user. But I am not sure that this group is as big as we make it out to be. Or maybe the few that are there are loud and annoying enough to become a distraction.

We actually don’t have much insight into what caused a product to be the way it is right now. And often we over-estimate the value we as web developers have in this. Yes, in 2001 it was up to the web developer to care about browser compat and clean markup. But even then we didn’t have full control over what ends up in the browser. Often we didn’t have to battle the browser, but the shortcomings of the CMS or framework used to render out HTML.

And this has not changed. When we talk about the web at events, in magazines and blog posts we often make the assumption that we control our stack.

In almost all projects I worked on in my career things looked different though. Many other players are part for the creation, deployment, publication and maintenance of our products.

A third party web

This is obvious when we see that one of the biggest offenders when it comes to performance of web sites are third party services. Often these aren’t added by the original web developer, but by all kind of other players. Marketing, DevOps, SEO, everybody has a special toy to add to the page. As Paul Calvano of Akamai discovered 27% of web sites are 90-99% third party content.

Patrick Hulce has an excellent interactive visualisation of this data at third party web today.

How much do different 3rd party scripts affect page performance? Based on HTTPArchive and Lighthouse data the median is 199ms extra, the minimum 47ms and in the worst cases third party code add up to 3 seconds of delay to the page rendering.

An assembled web

The web of today isn’t crafted by hand but assembled from existing building blocks. I’d go even further and say that this has always been the case, and many enterprise sites running on non-optimised framework and CMS output back me up there. Now have more sophisticated building blocks and they tend to get hungrier on resources year over year. If it runs on our fancy phones and laptops on fat connections, it is good enough to ship. This should worry us – and it does – but the market has moved on.

Sadly the focus of many a web product these days isn’t accessibility, performance, security and interoperability. It is getting the thing out as soon as possible. First to market beats quality and maintainablity on any ledger. As we assemble our products from building blocks, they become discardable and replaceable when the next cool toolchain comes around.

We have a plethora of packages, libraries and frameworks to choose from that make our lives easier. If your focus is to cut down on engineering cost and to roll out your product as quickly as possible, using them is a no-brainer.

A victim of it’s own design

The web is a great platform to not care about quality. It is defined as forgiving to developer error – it is one of the main design principles of HTML.

In case of conflict, consider users over authors over implementors over specifiers over theoretical purity.

Browsers aren’t allowed to break the web. We have decades of ill-advised browser competition on platform rather than UX features that created non-standard APIs live products rely on. That’s why browsers render non-standard code and will have to keep doing so. These are not only cruft, but also security attack vectors. Browser makers are busy keeping the web from breaking. And we can’t stop developers from being sloppy.

The dire state of the web, however, is affecting the business model of web based companies. And the solution, it seems, isn’t to ask the wise old sages of the web for advice. It is piling on more technology solutions. Most end users have some blocker running that gets rid of unwanted trackers and ads. Chrome is considering a never slow mode. Webkit has a similar idea considering limiting the amount of JavaScript a site can load. And, of course, there is AMP as the nuclear option to replace the slow web with a set of components.

Maybe the important thing is contributing to what people use?

I am not giving up on the web. It is too good a thing to waste. But it is time to face some realities that we’ve become disconnected from what the state of affairs is when it comes to the creation of web content. I love that we have fire and brimstone talks and publications about how horrible we are to the next users of the web with the things we create. But I want to see more sensible contribution and communication to the outside. I am currently working a lot with enterprise developers, people who have a 9-5 job and don’t have time to stay up-to-date. What they do, however, is build products millions of people rely on. It is pretty rewarding to introduce these people to simple tools and workflow optimisations. As Chris Coyier put it, we have a lot of tools in our editors and browsers to create a make it hard to screw up driven development flow. Most of the tools we blame for making the web horrible are open source. So let’s talk to the maintainers of these products and contribute a few small things that can make things better.

It is not anymore about knowing everything about the web and define best practices nobody follows. It is about understanding that the web is a rendering target and getting there as quickly as possible with the least effort is what sells it. I see the web as plumbing these days. We don’t care how the pipes in our houses work, as long as there is water when you open the tap. Only when things are utterly broken, we start wondering what happened. Then you call a plumber to fix it. Web developers are not the creators and drivers of the IT world. Maybe being a good plumber is a thing to consider. And this means we don’t only deal with clear water, but have to start wading through other things to make sure people will get things safe to consume.

When it comes to our online communications, I deliberately step away from in-fighting and Twitter threads. There is much less gain there than going to the source and comment where people write re-used components, libraries and products. We have the channels to make things better at the source. And that’s important.