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.

Last weekend I went to Munich to give the opening keynote for the Azure Saturday hosted in the Microsoft office. I was asked to give an overall intro about AI, what we should be worried about and how to embrace this new technology without locking people out or endangering them.

The video recording is on YouTube:

The slides are available on noti.st :

View Creating Human interfaces with AI on Notist.

I’ve collected all the resources I talked about in this Gist :

I’ve spent the better part of the last seven years presenting at all kind of conferences, meetups and client meetings and I’ve learned a lot along the way. I learned about different needs of different audiences and how to prepare your talk to make it as easy as possible for organisers to work with you. More importantly, though, I learned how to ensure that my presentations can be understood, don’t offend and work in even the worst organised environments.

In order to share this knowledge, and to remind myself of the necessities I put together a checklist to fill out before my talks. Not all of these bits are applicable to the talk you may give, but it is a good reminder of what you can do to help others understand what you do. And to make sure you can show your company what you did.

• You can read and use the checklist here
• You can also download, fork and contribute to it on GitHub

I hope this helps!

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 :).

Transcript

Here is a verbatim transcript of what we talked about:

Hi, Chris. We are here at Prismic, very happy to have you there. Could you maybe first introduce yourself?

Hello, I’m Chris. I’m a principal software developer at Microsoft, and I’m dealing with all matters web there, ‘cause I’ve been doing it for 20 years, and I love the web.

Okay, you also love JavaScript, I know that, and I’m sure you interact a lot with JavaScript developers, so I’m curious to know, like, where would you recommend someone who wants to learn about JavaScripts, to go and learn more about it?

The problem is, nowadays, there’s far too much JavaScript it’s overwhelming and everybody has a different opinion of it, so you actually have a lot of resources that are outdated, some of them that seem to be simple, so there’s a few things that source of truth that I love to use. One of them is the Mozilla Web Docs, MDN Developer Network, used to work on that one when I worked at Mozilla. That one is an up-to-date information that is actually everything about web technologies, is it CSS, JavaScript? And every time you wanna lookup some JavaScript that is a great way to look up. You can even do that in browsers when you do MDN and space and then the JavaScript that you wanna look, it automatically gets the results from MDN back so you don’t have to go through the website and do it there. Another very interesting thing is caniuse.com. Caniuse.com is a website that allows you to say something, technology that you heard about, and say which browsers and which environments support them.

So if it’s safe for you, in your case for your product, to actually use these already and also links through the documentation of these things links through the problems that they may have and links through the W3C standard that is actually their source of truth for everything but it’s not as easy to understand. So these are the main resources that I think are a great way for people to get started. And of course look around for videos on YouTube and conference videos because all of them are available for free. Every conference spends a lot of money producing these things and giving them out, so it’s kinda weird ‘cause people watching this right now so this kinda matter. But look at these resources and make sure you look at the date as well ‘cause some of them get outdated rather quickly, but something like MDN the great thing is it’s not a Mozilla product, it’s basically an independent product that people from Microsoft, Google, Apple, Samsung, whoever is doing something on the web are contributing to that one. We realize this is the one resource. We want to keep up-to-date, so this is a great place to start.

Okay, cool. So once they have looked this knowledge, where should they start, which tool should they use?

Once you have all this knowledge you would in the 70s and you don’t have to work anymore because it’s a lot of knowledge to take in. But knowing where to go is always a good opportunity. I find the most important thing right now and the most biggest change for me as well, is that how tooling has become so much better than it used to be in the past. In the past we had an alert to basically say when something went wrong in our JavaScript and that was not fun. Nowadays every browser comes with developer tools. There’s Chrome developer tools, there’s F12 developer tools, Safari’s, Firefox’s, they all differ a bit to a degree but they all give you lot of insight of what you’re doing and what you’re doing wrong. So instead of getting the old error messages, undefined is not defined which is not as helpful. You nowadays have a console in every browser that tells you what went wrong. And sometimes it’s even crosslinked to the MDN documentation that you can click on and know why something went wrong. So knowing these developer tools in the browsers, in and out or at least basically, is a very very good start for you because you know what you’re doing and you don’t need to go anywhere else. You can actually start writing JavaScript directly in those. Another great thing to get into is using interactive playgrounds on the web like: JS Bin for example, JSFiddle, CodePen, just a few others, StackBlitz and these kind of things. CodePen is a beautiful beautiful example because it has documentation, it has articles and it has code examples. So what these things allow you to do is write a code example when you run into a problem and send it to other people and they can then see what you’ve been doing and help you fix the problem in context rather than you having to explain to them what you did wrong. You can do live coding together with each other in these kind of environments. So for trainings and for schooling courses that I do, these things are beautiful to see. So getting to know these kind of environments and CodePen is full of very creative code examples so that’s a beautiful thing. If you’re just a visual learner, this is something to get very excited about. When it comes to setting up your environment I think Visual Studio Code is the editor that, of course I’m kinda biased because I work with the thing and on the thing, but it’s also a product that allows me to write code and learn what I’m doing wrong while I’m doing it. So there’s linters built into the systems, so linting means, while I’m typing something it tells me By the way this is wrong and here’s why. So much like the squiggly lines in Word when I’m writing something telling me I mistyped this, it’s the same happening in JavaScript. And the other thing it does for you is a lot of code insight so you don’t need know every keystroke but you actually tells you, you wrote these three letters, you probably want to write that long word now. and auto-completes it for you and the only one that can come after that is that one and so on and so forth. So it made me a much more effective developer and it’s lightweight, it’s open source, you can install it on Linux, on Mac, on Windows and you don’t have the problem that you had before like the editor had some similar functionality were like 12 gigabyte downloads and that’s not fun to do as well. So that’s one of the things I would be considering because it’s a beautiful experience of learning to become a better developer while you’re programming. Not reading up on it and having to know everything before you’re doing it. The tooling we have nowadays with developer tools and the browsers and editors like Atom or Visual Studio Code is that they do this auto completion things for you so it teaches you new things while you’re typing and you’re actually experiencing code as an adventure.

Okay, and one last question is, what would you start with like as your first project?

Whatever tickles your fancy, whatever makes you happy. I think products that come out of passion, things things that are something that you always wanted to build for yourself are the best things that are out there. You don’t want to start writing Facebook, that’s probably not a thing you’re gonna do in the weekend. But something you’re already excited about and you always wanted to play with is a great thing to get started with. One of the main things that I think are education space is not built on that kind of environment yet, it’s like, here’s a very very weird thing to do, Let’s find an algorithm to do that kind of thing. Solve your own problems and if that’s a to-do list for your things, if it’s organizing your kitchen, if it’s something you always wanted to do, if it’s finding out why the planes are not right at this moment. Friends of mine live on an island where there’s lots of ships coming in and they actually wrote themselves an app to learn code, to know when a cruise ship is coming in because then it doesn’t make no sense for them to go to town because it’s gonna be full of tourists. I guess Paris has similar things so that might be an app to start with kind of thing. Programming is there for us to do tasks that we are bored of as users. Computers are there for us to do the things that we humans would be bored doing. So find something like that that makes you happy and that way go out there. If you wanna learn new programming as well, you wanna learn JavaScript, there’s lots of good courses out there to get started with. But don’t get overwhelmed by the seemingly complexity of it. You can have tools nowadays that get you every step on the way and it’s in an interactive fashion and not, oh, you’re stuck here because you don’t know. The information is free and the tools are free and that’s why this is a wonderful world right now to learn web development.

Okay, cool. Well thank you very much for being there.

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 :).

Transcript

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