Often we want to have an interface where we have a container with overflow: scroll with a header and a footer.
One problem with that is that when we add new elements to the container, they do get added to the end of it but the element won’t show up before the user scrolls down.

In the past we hacked around this issue by comparing scrollHeight and clientHeight and setting the scrollTop property of the element. This is error prone and seems overly complicated.

Enter scrollIntoView. Using this API ensuring that a new element shows up to the user is as simple as calling it on the element itself.

Say we have the following list of characters and a button to add more of them.

HTML:

<div class="scrollbody">
    <ul>
        <li>Billy Butcher</li>
        <li>Hughie Campbell</li>
        <li>Mother's Milk</li>
        <li>The Frenchman</li>
  </ul>
</div> 
<button>Add new character</button>

In the CSS, we limit the body to scroll and set it to overflow.

.scrollbody {
  height: 6em;
  overflow: scroll;
}

With a bit of JavaScript, we can now add new characters every time we click the button:

let characters = ['The Female (of the Species)',
'Lieutenant Colonel Greg D. Mallory','The Legend','The Homelander',
'Black Noir','Queen Maeve','A-Train','The Deep','Jack from Jupiter',
'The Lamplighter','Starlight','Mister Marathon','Big Game',
'DogKnott','PopClaw','Blarney Cock','Whack Job',
'Gunpowder','Shout Out'];
 
let count = 0;
document.querySelector('button').addEventListener('click', (ev) => {
    if (count < characters.length) {
    let item = document.createElement('li');
    item.innerText = characters[count];
    document.querySelector('ul').appendChild(item);
    count = count + 1;
  }
  ev.preventDefault;
});

Now, if you try this out, you see that the new characters are in fact added, but not visible until you scroll down to them.

That’s bad. To remedy this, you all you need to to is to add the scrollIntoView call after adding the new list item:

/* list of characters */
let count = 0;
document.querySelector('button').addEventListener('click', (ev) => {
    if (count < characters.length) {
    let item = document.createElement('li');
    item.innerText = characters[count];
    document.querySelector('ul').appendChild(item);
 
    item.scrollIntoView();
 
    count = count + 1;
  }
  ev.preventDefault;
});

As an extra bonus, you can define the behaviour of the scroll to be smooth, which scrolls it in slowly and not as jarringly:

/* list of characters */
let count = 0;
document.querySelector('button').addEventListener('click', (ev) => {
    if (count < characters.length) {
    let item = document.createElement('li');
    item.innerText = characters[count];
    document.querySelector('ul').appendChild(item);
 
    item.scrollIntoView({behavior: 'smooth'});
 
    count = count + 1;
  }
  ev.preventDefault;
});

Another reminder to keep looking into what’s in the standard these days rather than finding an old solution on StackOverFlow and keep too complex and not browser-optimised code alive.

Update: there was a simplification about Custom Attributes being not supporting concatenation, thanks to Sime Vidas, Brian Kardell and Greg Whitworth to set this straight.

Over the last few iterations of CSS the boundaries between CSS and JavaScript started to blur. CSS was a static language, meant to define colours, look and feel, but not interactivity. You could use percentages in dimensions as sort of interactivity to the enviroment, but reacting to things changing was the job of JavaScript.

In the days of old HTML was there to give structure, CSS look and feel and JavaScript interactivity. Or, as I put it in my book in 2006, if your website were a movie HTML would be the script, CSS the cinematography and direction and JavaScript the special effects.

Nowadays, CSS is much more powerful. We have animations, transitions, calc() and much more flexible values like em, rem, vw, vh and more. We also have interactivity with pseudo selectors like hover, focus and states of interactive elements like buttons. We can even hack with checkboxes to write full games in pure CSS.

This is great! CSS aficionados are much more likely to have the patience and knowledge to make an animation or interaction look and behave exactly right. And CSS engines are responsible to perform well and not clobber the interactivity or battery life of the end user device. Browser makers can concentrate on optimising the engine rather than competing with the developer on who has the job to keep things smooth.

However, there are still boundaries and use cases where CSS is not enough, and you need JavaScript. Often these are about reading the current state of something happening to the browser window or an interaction not considered in the CSS spec.

Switching fully to JavaScript in that case feels like a knee-jerk reaction and it makes more sense to me to find a way for JavaScript and CSS to interact. JavaScript to read the value and to make it available to CSS in some way.

In the past, the only way to do that was to store classes on parent elements or remove classes when certain conditions were met. But with Custom Properties (“CSS variables”), it has become much easier to interact between JavaScript and CSS.

Custom properties allow you to set “variables” in CSS and use them later. For example:

::root {
  --company-blue: #369;
} 
 
h1 {
  color: var(--company-blue);
}

Custom properties are somehow limited and are not strings like they are in CSS preprocessors, so you can’t readily concatenate them Custom properties work differently to CSS variables in preprocessors. You can concatenate them, but there are limitations.

Thanks to Šime Vidas who showed a working demo on Twitter and to Brian Kardell pointing to the discussion on the CSS standards group .

As my colleague Greg Whitworth explains:

This is not actually true regarding custom props. The issue I think you’re primarily referring to are potential limitations in CSS in general, although I noticed that Sime already showed you that concatenation can be done but probably not in all scenarios where the only desire is to join actual strings (eg: “bar” calc(5 + 8) will get converted to \”foo\” calc(58) since it isn’t a valid calc and thus those are converted to a string as well but with escaped quotes. Everything within the variable is tokenized, so it can be a string or not depending on what the value is determined by the tokenizer. If it isn’t an invalid ident but isn’t one that can be matched, then it is converted to a string for use within CSS. Anything passed to JS is converted to a string. You can see this in this JSBin

The simplest way to alter CSS custom properties is to use calc() to multiply them with a value:

::root {
  --startwidth: 200;
} 
 
h1 {
  width: (var(--startwidth) * 1px);
}
h2 {
  width: (var(--startwidth) * 0.5px);
}

Now, as you can also define custom properties in JavaScript and add them to the styles collection of any element, this is a great way to only use JavaScript to read a value and leave the rest to CSS.

For example, if you wanted to know how far the document has scrolled, you can read this in JavaScript with an event handler and modify a CSS custom attribute:

JavaScript:

window.addEventListener('scroll', (e) => {
  document.body.style.setProperty('--scrolly', window.scrollY);
});

CSS:

h1 {
  position: fixed;
  width: calc(var(--scrolly)*1px);  
  background: #339;
}

You can try this out in this JSBin

By no means, this is a sensible demo, but I really like the fact that you can use JavaScript to reach where CSS can not, and still allow CSS to be the main driver and definition of interactivity.

I realised this week that I’ve been presenting at technology events for about 13 years now. The latter years were more or less dedicated to this and in some cases I covered 30 conferences a year.

Painting by Anke Mehlert

It is exhausting, but also fun work. And it brings a lot of extra opportunities. Both professionally – making contacts, meetings with companies and exposure. And on a personal level – seeing the world, trying out new places, meeting friends.

At a certain stage of your career speaking at a lot of events is great. You get outside validation, you bring back insights to your company and you make a name for yourself. If you are your own boss or you make money by speaking and giving courses, it is of course a no-brainer.

There comes a time in your career though where being on the road all the time becomes counter productive. And, even worse, it can become a barrier for others to engage and make their mark. I don’t want to be in the way – I want to pave a path.

Currently, my job is to empower others and to aid communication between departments. And to help coach and mentor people to become more visible inside and outside the company. This takes a lot of time and effort. But it is also rewarding to use your experience to help others avoid mistakes you made and follow best practices you discovered.

This is why I will take a step back from covering lots of conferences myself. I am lucky to know a lot of people that I can help fill in the spots, so please keep the offers coming. I hope that there is a great opportunity to get other people to make your event a success. I will try especially hard to ensure that the people I connect you to:

• are reliable and great at their job
• are new and different faces with more diverse backgrounds than me
• get all the help they need to ensure that working with you is easy
• find their own unique voice and get channels to get heard

On a related note, I am impressed about some of the talent that cropped up the last years on the speaking circuit. There are a lot of incredible people to choose from and it is exciting to find and support new people with different ideas.

I understand that there are harsh realities of having to sell tickets for your event. I also understand that picking well-known headliners make this a safer bet. I hope that there is a middle ground though. I can help get new people on stage and amplify their presence at your event on my communication channels.

I’m seeing a lot of new talent burn out and people who have been around for ages becoming repetitive. I don’t want to become either and I’d prefer helping new voices get onto the circuit without burning out.

I’m looking forward to hearing from you and try to make that happen.

Open Source is an excellent idea. It proved itself to create large and complex products with a shared workforce. It also allows products to follow the input and guidance from several players. Products don’t have to follow the demands of one company or their stakeholders. We build for the platform and the community, not for the next financial quarter.

Open source is a win for companies

For companies, open-sourcing their products means throwing them out to the scrutiny of the masses. People can contribute and build functionality the company hasn’t considered as it didn’t have that need. It is also an amazing opportunity for recruitment. Hiring people is hard and expensive. Cutting down on the time you need to ramp up a new employee is a real business benefit. Contributors are potential hires that already come with expert knowledge. It also is a way of ensuring quality. It is much harder to hide flawed code in plain sight than in a company internal repository.

Open source was my way in

I owe a lot of my career to Open Source and similar ideas like Creative Commons. That’s why I keep contributing and publishing. Without shared, open, free knowledge I wouldn’t have started working in web development. I couldn’t afford Frontpage and couldn’t find a cracked version. Instead, I downloaded the HTML and CSS spec from htmlhelp.com, opened a text editor and got on with it. This was a time where I didn’t have any connection at home, so I needed the docs offline.

Starting with this, I always felt that being open from the get-go is the right thing to do. To pay forward what I enjoyed, so to say.

When I started, releasing open source and using open source products was not the norm. As a professional, you had to use professional tools, and why give away for free when you could make people pay for it?

Open source is now front and center

Now, things look different. Open Source has become a household phenomenon and it is not a small group of enthusiasts any longer. It proved its value and the size of communities and open source releases exploded.

The problem with open source is the same problem with many other things: people. Communication is hard and considering what you say and do before doing it seems too much to ask. I was pretty naive about this in the beginning, too. I thought that people who share things would be nice and open people. I assumed a lot of them would also be in on my liberal views on other topics. I was wrong. People are people and they come with their flaws and ideas, biases and prejudices. They also come with their own issues they deal with. Those influence how they communicate with others.

And communication is the life blood of open source. It is not about writing some code, throwing it out there and letting people deal with it. It is about building a community around your code. It is about triaging requests and features to other people. This ensures the product can grow and prosper when you are bored of it or your company stops sponsoring it. It is about making it easy to share, to contribute, to use and to tweak to your needs.

This doesn’t gel with the image of the 10x developer and the drive for constant change and growth in the market. With lots of money and opportunity comes a lot of greed and arrogance. And thus, I keep hearing open source horror stories:

• The lone, burned out OSS developer crushed by millions of requests without empathy for his time.
• The arrogant coder who doesn’t bother with documentation and rejects any contribution. Giving anyone the feeling of not being good enough to use the code as they don’t understand it.
• The first time contributor drowning in an avalanche of negative feedback.
• The willing contributor shut out by overzealous code style and contribution guidelines
• Possible contributors failing to help out because the product’s build process.
• Fierce competition amongst contributors with personal attacks and automated rejection of pull requests.

The problem reaches far. Open Source is getting a reputation for being arrogant, aggressive, hard to get into. In its most extreme way it gets as far as recommending OSS being a Code of Conduct violation.

Recently, I spoke at a local meetup about my experience breaking into tech and things I did, that people can do too. The fact that I said contributing to OSS can be a great thing to do, I got flagged for breaking CoC because it was a "microagression." I am absolutely appalled. pic.twitter.com/fSSXxczeiW

— Katie? (@KatieFujihara) June 26, 2019

Disregarding the questionable argument in this case, there is a problem. It is frustrating to see that an open, collaborative idea like Open Source is getting a bad reputation. One of being exclusive and discouraging, no less. The very thing it set out to disrupt and change.

Open Source should bring a positive experience

I’ve worked in OSS for a long time, and I have on the whole had a great experience. I also am a white man who comes with a lot of credibility because of what I have done in the past. So my personal experience isn’t a universal one – by a long shot. I also had bad experiences. I’ve seen bigotry, arrogance and straight up malice. I’ve seen a lot of “play by those rules or leave the sandbox”. I’ve experienced far too much “are you better than this other person?”. I have experienced blocking by association and acts of other people affecting my reputation.

To a degree, things were much better before social media and the cult of the “persona”. Things were better before we compared each other by our number of products. And before our online presence became a way to land a job or get sponsorship.

It might be time to move away from releasing for the sake of visibility and go back to the more human and collaborative ideas of OSS. Hiring a person who shows great communication skills and empathy in their OSS dealings is a great investment for your company. These are the people who will power long-term growth and stability. Hiring the loudest, most active and aggressive people is a good short-term boost. The tech press and shareholders love a “go-getter” and “innovative and disruptive” story. Keeping those people happy in a company is a different task though companies often fail at.

The same applies to open source rockstars taking their product to the next level by starting a company around it. I’d love to see great stories around that. Instead I see explosive growth with a rushed human side of an employment relationship . It is tough moving from coder to employer and company owner. You need to deal with a lot of human issues and being all about the “hustle” is counterproductive to that.

Disregarding OSS as an amazing evolution of software development and great idea based on the actions of individuals is unfair and makes no sense. The very fact that the human interaction is part of the process is what makes open source interesting to me. Consider the opportunities:

• You can learn a lot by contributing to open source
• You can build on the work of others and learn a lot by seeing what they do
• You can contribute from whereever and whenever
• You can contribute in many ways: code, documentation, bugfixing, testing…
• You learn about tools of the trade by contributing (build processes, linters, compilers…)

Of course, this comes with a flipside:

• You work for free. This shouldn’t be a thing only for people who can afford to work for free. Open Source should be the thing to choose because you want to, not because you can afford to.
• Your contributions’ currency is impact and feedback. If what you spent a lot of time on and effort results in a “this is not good enough” or “we don’t work this way here” you feel short-changed.
• The quality of OSS products is so high, it can be daunting. It doesn’t help to feel inadequate when you look into contributing.
• The sheer amount of contributions and length of communications around products is overwhelming.

That means we have to play by rules that run any human interaction. If we do that, Open Source might get a better reputation again.

• Assuming that people know what you know is never a winning move. Explaining what you did to others makes you learn a lot. You learn by teaching. So, instead of throwing out code and hoping it prospers, taking an extra step and documenting it is a big winner. You can collaborate on that.
• Moving our stance from “here is the solution for this” to a “here is a way to solve this, what do you think” invites participation.
• It is OK not to have time for people’s contributions. It is not OK to snap at them or leave them hanging. A simple “sorry, I am not available right now” and asking for people to help you out with that is much better.
• We should consider the setups of possible contributors. Adding to a JavaScript package shouldn’t mean downloading gigabytes of files or having a $3000 computer.
• Personal attacks are never OK. This is about people working together. You have no idea what’s happening in the life of the person you try to “win” against. We all felt down and horrible at one time, remember that time and how you would feel is someone attacked you personally then.
• Just because it is easy to contact someone, doesn’t mean it is OK to. Especially not when why you contact them isn’t related to the project.
• Just because someone releases some code, they don’t automatically become your help desk. They put a lot of effort into releasing this, it is fair that you are expected to put some into using it. Instead of demanding better docs, why not document your journey and contribute it?
• We all have different levels of skill. If someone isn’t as “good” as you are, doesn’t mean that person couldn’t become a great contributor with time. That won’t happen if you discourage them upfront. Yes, they may do things “wrong” from your point of view, but having someone else explain the why is more helpful than you venting.

I’d hate something that impactful and great being taken down by the actions of a few bad or deluded actors.

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.