Christian Heilmann

You are currently browsing the archives for the General category.

Archive for the ‘General’ Category

Javascript vs. CSS – More control means more responsibility (video interview)

Thursday, April 11th, 2019

A few weeks ago I was in Paris, France to visit Prismic and they interviewed me about the JavaScript vs. CSS debate. In 10 minutes we covered a lot :).


Here is a verbatim transcript of what we talked about:

So I’m here at Prismic, with Chris Heilmann. Chris, can you introduce a little bit yourself what you’ve been doing?

I’ve been web developing for 20 years, now I’m a Principal Software Developer for Microsoft working on all web tooling there and the browser.

Right. You are working on EDGE, right? – Yes.

So there’s a question that comes quite often is like JavaScript vs. CSS, you know when to use one, can we do everything with JavaScript? Should we do everything with CSS?

It’s a massive topic at the moment and it’s actually splitting our market into two camps or three camps or four camps. And I find it kind of depressing because the technologies have always been there. JavaScript was always, a technology that allows you to do everything on the web, but you also own everything. You own the performance of it and you’re on the rendering of it and you own the accessibility of it. Whereas a standard, like HTML already gives you a lot of accessibility benefits from the beginning. A button works like a button and the button is also available to somebody who can’t see it because they get it read out as a button. In JavaScript, I can make that button work perfectly the way I want to, but I’d also have to control everything that is necessary to be done that a blind user can use that thing, that it works on a mobile device and that it works on these kinds of things. CSS is the same thing. It’s too easy to do everything with JavaScript. That’s why people get very excited about it.

This is the feel of control, right? You can control every little detail.

And to do it fast as well. You can do it in one goal, you can do it, you could control everything yourself. You don’t need to talk to other people who are experts in that. But this is not how interfaces for the web are being built, because it needs experts that know about the problems of different end users, of different environments, of different ways where your application will run. Blindly trusting a technology or a framework to actually do that for you, it’s not a good bet to me. So one of the main things that a lot of JavaScript people that basically the new kind of jobs people say everything JavaScript is necessary, keep saying that CSS isn’t good enough. That CSS is a weird standard and it’s not the way we learn programming. And that’s totally true. It’s not meant to be JavaScript, it’s meant to be a different technology. But it has come into its own over the last years immensely, CSS is not as confusing and weird than it used to be in the past where browsers didn’t quite support them. All browsers that we have now, are evergreen, all of them support the CSS that we expect them to support. So it’s not only about changing colors, it’s also about animations that actually get accelerated by the machine for you, by the browser for you. There’s transitions and there’s a finally a proper layout environment in CSS. With grid layouts we can create page layouts that are highly complex, and the browser does the rendering for us, we don’t have to do the calculations in JavaScript ourselves and to write in-line styles and these kinds of things. Flexbox gives us the opportunity to have little components, that are actually flexible and are taking up as much space as we want to. So the holy grail of like centering something in vertical and horizontal is now two lines of CSS. It’s not about knowing how browsers do it wrong. It’s not about putting in extra elements.

So it what the case, right? It’s by block align, all the kind of thing, yeah. You had to kind of always know exactly how the browsers are behaving and now it’s a standard, there’s Flexbox, you express what you want and it’s implemented.

Exactly. I think the big problem with CSS is that people see the big failures of old browsers as a part of the heritage of CSS. And it’s not the case any longer. CSS evolved as much as JavaScript did over the last few years as well. So JavaScript now is a standardized language finally, with ES5, we finally had an ECMAScript standard and not just like something that, that browser does this, that browser does that, we hope that browser does this, so we now have a standardized way there. So, I think both are as powerful as they can be. JavaScript, is the only one that allows you to do everything in one go. That’s why it’s very tempting to do it. But what we do with it is we lock out a lot of people, that could be efficient people working in our market by asking them to do a technique to learn one technology, where they actually are excited about doing other things.

That’s a cultural problem, right? Like you, what you mentioned is that you feel like if you don’t know JavaScript, then you are not fit enough for doing web development.

And that’s a very arrogant and stupid statement to make because if you don’t know CSS, are you then as incompetent? And most JavaScript people that just know JavaScript and don’t wanna touch CSS cause it’s kind of different. You know what? Different people work in teams together to build interfaces. So let people specialize on the different parts that make the most sense in your interface, where the browser can help us rather than we have to fight against the browser.

So the browser will help us with what? in CSS?

In CSS it helps us with the rendering of different interfaces, if you use grid, if you use Flexbox, it also helps us with the animations. So it’s helps us with the coloring. It helps with the fonts, all the things that you actually want to have. And it helps us with caching as well. A CSS file can get cached and can get reused by the browser. Whereas if you render something, every single time on every single frame differently, because you want to have full control of your animation, it cannot get cached and it will have to download the whole bunch every single time just because you want that control.

Right. So like for instance, here’s an example, why is it problematic to have a SPAN? And you know, kind of put a link, an action on it, an event on it and make it look as a button? What could go wrong?

A SPAN does nothing. A DIV has no semantic meaning. A DIV could be anything. It’s a placeholder. If think about it, it’s a variable, it has been undefined in CSS, so to say. Not really, but it’s nothing. Whereas a button already when you tell a button in HTML, the browser renders it as something clickable, it tells somebody who is blind that this is something clickable as well. It gives you a depressed state. It gives you a state that is invalid. It gives you a state where it’s greyed out that you can just control with an attribute as well, Like all the different UX states of a button that you have to define if you use a , are already given to you in the browser because it’s built-in. Of course, it might not be to your liking the way it looks, but in the past we couldn’t style it. Nowadays, styling of buttons is completely possible, across all the browsers that we have nowadays as well.

Another example is that in input fields for select for instance, it’s like the first time, I noticed it, a long timeago, whenever you click on a select box instead of trying, in your mobile phone, to kind of find the actual state that you want to select, it opens something down, which is much bigger, which is like much more visible.

All form elements have an operating system defined look and feel like; an input type date gives you a calendar, that you don’t have to program yourself, How cool is that? It’s even localized to the environment. So it will be an American date picker, with the date the other way around that we have. And these kinds of things. That is already built for you into the browser if you use these things. Even more importantly if you use a proper input element with an input type=”email”, input type=”URL” and so on and so forth. Input type=”password”, the browser can do the storing, can store the data for you and fill it out. So every single time I use my mobile phone to order something, I don’t want to enter my address. If the address field has been properly marked up in HTML, the browser says like, “Hey, shall I auto fill these things for you?” And I’m more likely to buy things from you if I can use that auto-fill, then if you give me that perfectly rendered JavaScript controlled input element that is not an input. –

*Right. Completely. Okay then, when does it make sense actually to use frameworks and JavaScript
frameworks and components instead of using like CSS and HTML What is the right decision? Is it the size of the team, the size of a project?*

It’s more an architectural decision than anything else. If your environment, if what you build is consisting of lots of little changing parts, that are not interacting with each other and are not and cannot interact with each other, then the component framework makes so much more sense because that’s what it was built for. The web was not built as a platform to do these kinds of things as of yet. We’re working on standards to think about it in that direction as well.

Just like – Web component of course—- Web component

But not everything needs to be Facebook, not everything needs to be Twitter, not everything needs to be LinkedIn. If your website is more or less static pages, then using a component framework makes no sense, but if you’re a website is something where you have 12 different departments controlling 12 different parts of the interface, and they all wanna have to a different look and feel and they want to have their own data consumption and data going back and forth to directional without interfering with the others, then a component framework, it’s the right way to use it. So it’s the right thing for the right job. So in this case, the complexity, that a framework allows you to do is something that not every time is applicable to a normal web environment. But if you do it, it makes no sense to actually, demonize frameworks and say like, you should never use frameworks as well. In the case of React of course the other part, the other part is that it also allows you to render out binaries for iOS and for Android, If you don’t wanna play on the web and you wanna play into those markets. And that’s a great thing because you built it once and you deployed it in three different environments. You can do the same thing with HTML and PWAs nowadays, but it’s much, much easier to have one controlled environment. You have to think about the cost. You have to think about what I want to do, what can I do that the browser does a lot of stuff for me or the web does a lot of things for me already, that are accessibility, that are about accessibility, that are about the rendering in the browser, or do I wanna have full control over it because I need to violate some of those ideas, I need to make them differently. Then your reliance on something like a framework makes total sense. You also have to think about like what’s happening in three, four, five years time. And that every of your end user needs to download that whole framework before the first thing renders on their device. So it’s a matter of architecture. I really, really don’t think that there’s a space where only HTML CSS is applicable. JavaScript gives us a lot of benefits. But it should not be the case that you’re not a full developer if you don’t know JavaScript, cause on the web, that doesn’t make any sense.

It makes sense. Thanks Chris

Common accessibility issue: moving to a page section without shifting keyboard focus

Tuesday, April 9th, 2019

Disclaimer: the following is not a dig at JSFest, I just used their website as a demo at the event. It is a common problem many people have on their sites, so it is a good example to use.

One feature you see on a lot of “modern” web sites is that activating the menu items smoothly scrolls to the section you chose. It is good UX, as people see that they are going to another section. It also feels much smoother than simply jumping to it. When there are any JS errors, you still have a full page you can scroll. If you properly linked your navigation items with links pointing to fragment identifiers, it even works without JavaScript and as a bookmarking feature.

  <li><a href="#cakes">Cakes</a></li>
  <li><a href="#cookies">Cookies</a></li>
  <li><a href="#desserts">Desserts</a></li>
  <li><a href="#remedies">Remedies</a></li>
<h2 id="cakes">Cakes</h2>
<h2 id="cookies">Cookies</h2>
<h2 id="desserts">Desserts</h2>
<h2 id="remedies">Remedies</h2>

However, we can really make it hard for keyboard and screenreader users when we forget to set the focus to the element we scrolled to. Just because it is in the viewport, doesn’t mean the keyboard focus moved there.

What does this mean? Let’s take a look at this screencast. As a keyboard user, you need to hit “tab” seven times to reach the “prices” link. Activating it does scroll the correct section into view. However, if all you can do is hit tab and you can’t see the change, it needs an additional 107(!) “tab”s to times to really reach the section.

The remedy is easy:

  • Ensure that your target sections of your menu are keyboard accessible landmarks in the document with IDs. This also has the benefit that anyone following a “” link will get to that section
  • After you scrolled to the section, move the keyboard focus programmatically from the menu item to the target section using focus() and – if needed – by setting a tabIndex.

If you want to test this on your own sites, install the accessibility insights extension for Chrome or (new) Edge.
You will get a heart icon in your browser and a choice of tools to run on the current site:

accessibility insights extension options after install

Select the “Ad hoc tools” to get the extension to overlay accessibility issues on the current document:

Ad Hoc Tool options of accessibility insights

Once you turned on the “Tab Stops” option you get a confirmation that the extension is running:

tab stops enabled

Hitting tab now will start showing you the tab stop journey across your document, which helps you find issues like these. Often these are easy to fix, and make a huge difference.

Hinting at a better web at JSFWDays in Kiev, Ukraine

Monday, April 1st, 2019

Two weeks ago I went to Kiev, Ukraine to speak at the JavaScript FWDays conference. I gave the closing keynote talking about what matters on the web and how we can create a better one by moving our best practices into our development flow.

presenting in the huge room

The video is now available on Youtube

The slides and resources mentioned in the talk are available on

View Hinting at a better web FWDays edition on Notist.

Talking to prismic about performance

Wednesday, March 20th, 2019

A few days ago, I flew to Paris to meet with Prismic and record a few videos on web topics. Today they released the first video where I talked about web performance, mistakes to avoid and tools to use to make your apps faster.

Here are the topics in detail:

  • 0:59 Managing performance on a browser, things we do wrong
  • 2:35 Improving your performance: image optimization and tooling
  • 5:27 Optimizing JavaScript download and execution time
  • 8:45 Using CSS instead of JavaScript
  • 9:51 Tooling advice for better performance
  • 11:58 How can GraphQL help for optimizing queries, download only what you need
  • 13:40 Perspective: Opportunities in the new standards of the web with HTTP2, Service workers

Discussed tools:

GitHub Toggle – a bookmarklet to toggle between repo and GitHub Pages

Monday, March 18th, 2019

And in the “things I always wanted to have” camp, I just wrote myself a small bookmarklet that switches from a GitHub repository and its Pages back and forth.

You can get it on its GitHub repo: GitHub Toggle

It is not clever, and for now only works with index.html pages, as I didn’t want to use any storage.

Here’s a GIF showing it in action:

Installing and switching with GitHub toggle