Christian Heilmann

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

Thursday, April 11th, 2019 at 1:12 pm

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

Share on Mastodon (needs instance)

Share on Twitter

My other work: