This is part of the web truths series of posts. A series where we look at true sounding statements that we keep using to have endless discussions instead of moving on. Today I want to tackle the issue of JavaScript and how much we should rely on it.

JavaScript is the love/hate topic of the “modern web”. People who have been around for a long time have learned the hard way not to blindly rely on it. People who just started don’t even know how you could turn it off or why it could be a problem.

This gives us an endless opportunity to rant in one direction or the other. The old guard points out that the new builds fragile products that demand too much of the users. The new guard points out that a web without JavaScript is neither fun for users nor easy to maintain. A lot of times, this argument is about developer convenience trumping sturdiness of the web. And we keep going in circles viewing it from both ends of the spectrum.

When we got JavaScript, it ran in the browser and made a lot of things possible that HTML and CSS alone could not do yet. We could react to things our users were doing without reloading the page. We could read out and react to the environment the script was running in. JavaScript was the interactive glue of the web. We could make less able browsers do things others could. We could create interaction models that HTML forms didn’t provide. And we could create a consistent experience across browsers and platforms.

And this is where the main issue came up: for many, the web isn’t meant to look and work the same everywhere. Instead it should give a working experience for all users and get fancier the more able the user agent is. By relying on JavaScript in our solutions we put up a barrier for the sake of control. This was especially bad when we didn’t deliver any functionality when JavaScript failed.

And JavaScript can fail in many ways. From non supporting environments to coding errors and connectivity issues – anything can break.

JavaScript isn’t like CSS or HTML. Both these building blocks of the web are fault-tolerant. This means when you write invalid HTML, the browser tries to fix it. If you use bleeding edge CSS in an old browser, it ignores it. Not so with JavaScript. Syntax errors or accessing an unknown object cause the interpreter to give up and say no. Even the most capable environments don’t support JavaScript until the first script loaded and ran without a problem.

Stuart Langridge explains what can go wrong until your script does what you wanted it to do in his Everyone has JavaScript, right? site.

The main power of JavaScript was that it executes on the fly and in the browser. It didn’t need any compilation, it didn’t need any fancy development environment. That was a huge part of its success. Compared to other languages that have similar power, it is much more approachable. And it seems easy to fix a problem you have with JavaScript that seems complex in CSS if you’re not used to its syntax. JavaScript can do everything: it can load extra information, it can create HTML and it can change styles and images. It is the jack-of-all-trades of the web.

When something is easy to apply there is always a danger that people over-use it. It is tempting to see your well-connected development device as the world. And to expect the same speeds and computing powers of your users. In this scenario loading a few megabyte of JavaScript is not a high price to pay to allow for easy maintenance. When you’re on a metered, slow or unreliable connection or on a low-end device this convenience can soon turn into frustration. This is an even bigger problem as it is hard – if not impossible – to detect these conditions.

So, yes, JavaScript is a fair-weather friend and can break in many ways. You may also block out a lot of users because you crave more control over things you aren’t meant to control.

There is a flip-side to this truth though. JavaScript has evolved from a scripting language in the browser to a development environment in its own right. The rise of Node and other server-side and embedded systems put JavaScript on the map as a key skill of our market.

JavaScript isn’t a client-side problem, it is a whole bigger set of offers these days. I talked about this beginning of the year at ScriptConf in Austria

Universal, isomorphic JavaScript – or whatever other buzzword we come up with – is the answer to the lack of fault tolerance of the language. We can run the JavaScript in a space we control like the server or a build process and we render out plain HTML. We can use client-side JavaScript in a fair weather situation. If that fails, we can rely on a JS based API and routing mechanism to still give the user the content they came for.

The real, pragmatic approach to the flimsiness of JavaScript though is much easier: people use it anyways, let’s concentrate on keeping it safe and reliable.

Whilst we still complain that JavaScript breaks in the client, we have a huge group of developers who use JavaScript in everything. While we worry about support for a certain new browser feature, people rely on hundreds of package dependencies to build very basic functionality. Whilst we worry about DOM bugs, people use libraries with virtual DOMs and scripted routing instead of HTTP.

JavaScript is a given and a language that empowers and inspires hundreds of new developers each day. Our job as lovers of the web is not to tell people that they are wrong using it in the first place. Our job is to allow these developers to be as creative with this new use of it. Much like we were when a standardised DOM was still a dream to come.

We’re not here to call the shots. We’re here to embrace a new use of a valid technology and help with our knowledge to not repeat age-old mistakes. But we need to make sure that we learn in that process, too. It is far too easy to find glaring mistakes in new applications of old technology. It is much harder to help people solve new problems they face with guidance of past experience. But it is much more rewarding as it doesn’t create a “us old sages vs. those new cowboy-coders” world.

With more defined and controlled environments, JavaScript becomes much easier to trust. The thing we need to worry more about now is to ensure that it doesn’t get too complex.

Instead of worrying about the non-fault-tolerance of JavaScript, here are some other things to worry about:

• How safe is it to rely on a loosely curated package repository for our projects? How can we make sure that in the dozens of NPM modules we use none of them is malware? How can we ensure people use packages safely, keep them up-to-date and not face disaster when one of them breaks?
• How can we reap the rewards of abstractions without creating an unhealthy dependency? The vue.js of tomorrow may well be the jQuery UI of today. Yes, we create faster and more with an abstraction. But we miss out on understanding how what we create works. We don’t want to have a lot of developers and products that become ineffective once an abstraction is out of fashion.
• How can we create a professional development environment for JavaScript without overwhelming new developers? Back in the days we needed a text editor and a browser. Now we need to have command-line knowledge, toolchains, unit tests, continuous integration and heavily customised editors. Each of these things make sense, but can look daunting to a new developer.
• How can we move the language itself ahead without relying on transpilation? JavaScript is finally standardised and new functionality should be used by anyone, not only in a compilation step.
• How can we still reap the rewards of the just-in-time compilation of JavaScript when we use it like a compiled language?
• How can our tooling help new and experienced developers without overwhelming one group and boring the other? Is linting the answer or is it expecting developers to be experts in browser tools?

This is part of the web truths series of posts.

Every few months there is an article claiming that CSS is not real programming. That CSS is too hard and broken. The language used in these can get creative:

People have some ... um ... intense feelings about CSS. pic.twitter.com/dDspAM8i2F

— Dave Rupert (@davatron5000) September 18, 2017

There is truth to the fact that working with CSS is not traditional programming. There is also truth that CSS has its language faults and that some things are much harder than they should be. That is the case with any standardised language, though. CSS is a way to describe what an interface should be like. It is not the implementation of said interface in a programmatic fashion, like, for example, the Canvas API. That CSS is not like a traditional programming language is by design.

CSS is a great idea when it comes to creating an interface for something as complex and unknown as a user on the web. I talked about the difference of CSS and JavaScript in detail at GOTO Amsterdam where I called it a decision between trust and control.

As a CSS developer, you trust the user agent (in most cases a browser) to do the right thing. You can’t control that it happens, but you also don’t need to sweat the details like performance, paint time and responsiveness. This ball is in the court of the user agent creators and the OS it runs on. And that is a great thing as it allows to fix those important things in one place – where they get applied. If you create interfaces or animations using JavaScript, you have much more granular control. But you also need to ensure everything works. Using CSS means giving up control for the sake of having more time to build a responsive interface catering to the users’ needs. Users need and can mess with your interface settings. CSS is OK with that. Pixel-perfect, defined interfaces are not.

CSS development isn’t programming in the traditional sense where you have loops, conditions and variables. CSS is going that direction to a degree and Sass paved the way. But the most needed skill in CSS is not syntax. It is to understand what interfaces you describe with it. And how to ensure that they are flexible enough that users can’t do things wrong and get locked out. You can avoid a lot of code when you understand HTML and use CSS to style it.

If you don’t consider an interface as an agreement with your users with various levels of fidelity depending on their technical platform, CSS isn’t for you. It is by design a forgiving language, that doesn’t throw any errors when something can’t get applied. Thus it is amazing for progressive enhancement. You don’t even need to worry about adding a line of unsupported code as the parser skips what it can’t apply. What causes a JavaScript parser to throw in the towel and give you an error message, the CSS parser shrugs off and moves on. That can feel odd for a developer – I for one like to know when something went wrong. But it frees you from needing to test on all possible user agents and put “if” statements around everything. Want to use a gradient on button? Define a background color, then override it with a gradient in the next line. If the user agent can’t render gradients, you get a simpler, but still working button. And you didn’t need to worry about gradient support at all.

A lot of “CSS is not real programming” arguments are a basic misunderstanding what CSS is there to achieve. If you want full control over and interface and strive for pixel perfection – don’t use it. If you want to build an interface for an inclusive and diverse web, CSS is a great tool. Writing CSS is describing interfaces and needs empathy with the users. It is not about turning a Photoshop file into a web interface. It requires a different skillset and attitude of the maintainer and initial programmer than a backend language would.

In any case, belittling people who write CSS and considering them not real developers is arrogant nonsense. Especially when you don’t even spend the time to understand what CSS tries to achieve and how amazing it has become.

On the other hand, CSS is not and should not be the solution for everything. Yes, you can create pixels with drop shadows, but you also punish the browser rendering engine with this.

CSS is an integral part of the web to me and whilst the syntax is weird for someone coming from a different programming language, it proved its worth over the years. It should and will not go away for quite some time. So if you don’t like it, pair with someone who does. If your managers demand you to do it, we don’t have a technical issue at our hands, but a project/staffing one.

Instead of having discussions if CSS is broken and needs to be replaced, it is healthier to have different discussions about CSS:

• What CSS can do and where it isn’t enough
• What CSS can do these days that needed other technology in the past and how to apply it
• How to write CSS in a maintainable fashion
• What can you do to make the life of the CSS developer easier?
• What CSS hacks we used and why we should not use them anymore
• What can we do to make CSS richer and better?

Every few months there is a drama happening in the blogging and social media scene. We seem to need that to keep ourselves occupied. It allows us to get distracted from the feeling that the people who pay us have no idea what we do. And keep praising us for things we are not proud of, cementing our impostor syndrome.

For an upcoming talk, I analysed the recurring themes that we get fired up about. I will post one on each of these over the next few weeks.

• CSS is not real programming and broken
• JavaScript can’t be trusted
• We need granular control over web APIs, not abstractions
• The web is better than any other platform as it is backwards compatible and fault tolerant
• The web is broken and backwards compatibility is holding us back
• Publishing on the web using web standards is easy and amazing
• The web is world-wide and needs to be more inclusive
• Mobile is the present and future

Each of these topics can spark thousands of reactions, dozens of blog posts. Many will get you a speaking slot at an event. They are all true, but they are also all not necessarily yielding the amazing insight we expect them to. I’ll try to explain why they are endless loops and what we could do to get past discussing these over and over again. Maybe it is a good time to concentrate on solving other, new, problems instead. And recognise that a new generation of makers and developers may not be as excited about them as we are.

Yes, these will be my opinions and they may spark some discourse. That’s fine. You can disagree with me, and I promise to keep this to the point and civil. I’ve done this for a very long time, I’ve heard many people talk and discuss these. Hopefully my insights will hit a mark with some of you and make us reconsider rehashing the same old discussions over and over again.

I am currently on the train back to London after attending the first two days of Reasons.to in Brighton, England. I need to go to pick up my mail that accumulated in my London flat before going back to Berlin and Seattle in a day, otherwise there would be no way I’d not want to see this conference through to the end.

I don’t want to go. Reasons.to is an amazing experience. Let me start by listing the reasons why you should be part of it as an attendee or as a presenter. I will write up a more detailed report on why this year was amazing for me personally later.

Why reasons.to is a great experience for attendees:

Reasons.to is a conference about creative makers that use technology as a tool. It is not a conference about hard-core technical topics or limited to creating the next app or web site. It is a celebration of creativity and being human about it. If you enjoy Beyond Tellerand, this is also very much for you. That’s not by accident – the organisers of both shows are long-term friends and help each other finding talent and getting the right people together.

As such, it demands more of both the presenters and the audience. There are no recordings of the talks, and there is no way to look up later what happened. It is all about the here and now and about everyone at the event making it a memorable experience.

Over and over the organisers remind the audience to use the time to mingle and network and not worry about asking the presenters for more details. There is no Q&A and there is ample time in breaks to ask in person instead. Don’t worry – presenters are coached that this is something to expect at this event and they all agreed.

There is no food catering – you’re asked to find people to join and go out for breaks, lunches and dinners instead. This is a great opportunity to organize yourselves and even for shy people to leave with a group and have a good excuse to get a bit out of their shell.

This is a getting to know and learning about each other event. And as such, there is no need to advertise itself as an inclusive safe space for people. It just is. You meet people from all kind of backgrounds, families arrive with children and all the people involved in putting on the show know each other.

There are no blatant sponsored talks or holy wars about “framework vs. library” or “technology x vs. technology y”. There is no grandstanding about “here is what I did and it will revolutionise our little world”. There is no “I know this doesn’t work yet, but it will be what you need to use else you’d be outdated and you do it wrong”. And most importantly there is no “this is my showreel, am I not amazing” presentations that are sadly enough often what “creative” events end up having.

The organisers are doing a thorough job finding presenters that are more than safe bets to sell tickets or cover the newest hotness. Instead they work hard to find people who have done amazing things and aren’t necessarily that known but deserve to be.

If anything, there is a very refreshing feeling of meeting people whose work you may know from advertising, on trains, TV or big billboards. And realizing that these are humans and humble about their outrageous achievements. And ready to share their experiences and techniques creating them – warts and all.

The organisers have a keen eye on spotting talent that is amazing but not quite ready to tell the world about it and then making them feel welcome and excited about sharing their story. All the presenters are incredibly successful in what they do, yet none of them are slick and perfect in telling their story. On the contrary, it is very human to see the excitement and how afraid some of these amazing people are in showing you how they work.

Reasons.to is not an event where you will leave with a lot of new and immediately applicable technical knowledge. You will leave, however, with a feeling that even the most talented people are having the same worries as you. And that there is more to you if you just stop stalling and allow yourself to be more creative. And damn the consequences.

Why reasons.to is a great idea for presenters

As a presenter, I found this conference to be incredibly relaxed. It is an entity, it is a happening that is closed in itself without being elitist.

Not having video recordings and having a very low-traffic social media backchannel might be bad for your outside visibility and makes it harder to show the impact you had to your manager. But it makes for a much less stressful environment to present in. Your job is to inspire and deal with the audience at the event, not to deliver a great, reusable video recording or deal with people on social media judging you without having seen you performing or being aware of the context in which you said something.

You have a chance to be yourself. A chance to not only deliver knowledge but share how you came by it and what you did wrong without having to worry about disappointing an audience eager for hard facts. You can be much more vulnerable and human here than at other – more competitive – events.

You need to be ready to be available though. And to spend some extra time in getting to know the other presenters, share tips and details with the audience and to not be a performer that drops in, does the show and moves on. This event is a great opportunity not only to show what you did and want people to try, but it is also a great event to stay at and take in every other talk. Not to compare, but to just learn about people like you but with vastly different backgrounds and approaches.

There is no place for ego at this event. That’s a great thing as it also means that you don’t need to be the perfect presenter. Instead you’re expected to share your excitement and be ready to show mistakes you made. As you would with a group of friends. This is refreshing and a great opportunity for people who have something to show and share but aren’t quite sure if the stage is theirs to command.