can’t

Web Truths: JavaScript can’t be trusted

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.

Good vs. eval()

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?

View full post on Christian Heilmann

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Don’t tell me what my browser can’t do!

Chances are, your guess is wrong!

you are obviously in the wrong place
Arrogance towards possible customers never pays out – as shown in “Pretty Woman”

There is nothing more frustrating than being capable of something and not getting a chance to do it. The same goes for being blocked out from something although you are capable of consuming it. Or you’re even willing to put some extra effort or even money in and you still don’t get to consume it.

For example, I’d happily pay $50 a month to get access to Netflix’s world-wide library from any country I’m in. But the companies Netflix get their content from won’t go for that. Movies and TV show are budgeted by predicted revenue in different geographical markets with month-long breaks in between the releases. A world-wide network capable of delivering content in real time? Preposterous?—?let’s shut that down.

On a less “let’s break a 100 year old monopoly” scale of annoyance, I tweeted yesterday something glib and apparently cruel:

“Sorry, but your browser does not support WebGL!” – sorry, you are a shit coder.

And I stand by this. I went to a web site that promised me some cute, pointless animation and technological demo. I was using Firefox Nightly?—?a WebGL capable browser. I also went there with Microsoft Edge?—?another WebGL capable browser. Finally, using Chrome, I was able to delight in seeing an animation.

I’m not saying the creators of that thing lack in development capabilities. The demo was slick, beautiful and well coded. They still do lack in two things developers of web products (and I count apps into that) should have: empathy for the end user and an understanding that they are not in control.

Now, I am a pretty capable technical person. When you tell me that I might be lacking WebGL, I know what you mean. I don’t lack WebGL. I was blocked out because the web site did browser sniffing instead of capability testing. But I know what could be the problem.

A normal user of the web has no idea what WebGL is and?—?if you’re lucky?—?will try to find it on an app store. If you’re not lucky all you did is confuse a person. A person who went through the effort to click a link, open a browser and wait for your thing to load. A person that feels stupid for using your product as they have no clue what WebGL is and won’t ask. Humans hate feeling stupid and we do anything not to appear it or show it.

This is what I mean by empathy for the end user. Our problems should never become theirs.

A cryptic error message telling the user that they lack some technology helps nobody and is sloppy development at best, sheer arrogance at worst.

The web is, sadly enough, littered with unhelpful error messages and assumptions that it is the user’s fault when they can’t consume the thing we built.

Here’s a reality check?—?this is what our users should have to do to consume the things we build:

That’s right. Nothing. This is the web. Everybody is invited to consume, contribute and create. This is what made it the success it is. This is what will make it outlive whatever other platform threatens it with shiny impressive interactions. Interactions at that time impossible to achieve with web technologies.

Whenever I mention this, the knee-jerk reaction is the same:

How can you expect us to build delightful experiences close to magic (and whatever other soundbites were in the last Apple keynote) if we keep having to support old browsers and users with terrible setups?

You don’t have to support old browsers and terrible setups. But you are not allowed to block them out. It is a simple matter of giving a usable interface to end users. A button that does nothing when you click it is not a good experience. Test if the functionality is available, then create or show the button. This is as simple as it is.

If you really have to rely on some technology then show people what they are missing out on and tell them how to upgrade. A screenshot or a video of a WebGL animation is still lovely to see. A message telling me I have no WebGL less so.

Even more on the black and white scale, what the discussion boils down to is in essence:

But it is 2016?—?surely we can expect people to have JavaScript enabled?—?it is after all “the assembly language of the web”

Despite the cringe-worthy misquote of the assembly language thing, here is a harsh truth:

You can absolutely expect JavaScript to be available on your end users computers in 2016. At the same time it is painfully naive to expect it to work under all circumstances.

JavaScript is brittle. HTML and CSS both are fault tolerant. If something goes wrong in HTML, browsers either display the content of the element or try to fix minor issues like unclosed elements for you. CSS skips lines of code it can’t understand and merrily goes on its way to show the rest of it. JavaScript breaks on errors and tells you that something went wrong. It will not execute the rest of the script, but throws in the towel and tells you to get your house in order first.

There are many outside influences that will interfere with the execution of your JavaScript. That’s why a non-naive and non-arrogant?—?a dedicated and seasoned web developer?—?will never rely on it. Instead, you treat it as an enhancement and in an almost paranoid fashion test for the availability of everything before you access it.

Sorry (not sorry)?—?this will never go away. This is the nature of JavaScript. And it is a good thing. It means we can access new features of the language as they come along instead of getting stuck in a certain state. It means we have to think about using it every time instead of relying on libraries to do the work for us. It means that we need to keep evolving with the web?—?a living and constantly changing medium, and not a software platform. That’s just part of it.

This is why the whole discussion about JavaScript enabled or disabled is a massive waste of time. It is not the availability of JavaScript we need to worry about. It is our products breaking in perfectly capable environments because we rely on perfect execution instead of writing defensive code. A tumblr like Sigh, JavaScript is fun, but is pithy finger-pointing.

There is nothing wrong with using JavaScript to build things. Just be aware that the error handling is your responsibility.

Any message telling the user that they have to turn on JavaScript to use a certain product is a proof that you care more about your developer convenience than your users.

It is damn hard these days to turn off JavaScript – you are complaining about a almost non-existent issue and tell the confused user to do something they don’t know how to.

The chance that something in the JavaScript execution of any of your dozens of dependencies went wrong is much higher – and this is your job to fix. This is why advice like using noscript to provide alternative content is terrible. It means you double your workload instead of enhancing what works. Who knows? If you start with something not JavaScript dependent (or running it server side) you might find that you don’t need the complex solution you started with in the first place. Faster, smaller, easier. Sounds good, right?

So, please, stop sniffing my browser, you will fail and tell me lies. Stop pretending that working with a brittle technology is the user’s fault when something goes wrong.

As web developers we work in the service industry. We deliver products to people. And keeping these people happy and non-worried is our job. Nothing more, nothing less.

Without users, your product is nothing. Sure, we are better paid and well educated and we are not flipping burgers. But we have no right whatsoever to be arrogant and not understanding that our mistakes are not the fault of our end users.

Our demeanor when complaining about how stupid our end users and their terrible setups are reminds me of this Mitchell and Webb sketch.

Don’t be that person. Our job is to enable people to consume, participate and create the web. This is magic. This is beautiful. This is incredibly rewarding. The next markets we should care about are ready to be as excited about the web as we were when we first encountered it. Browsers are good these days. Use what they offer after testing for it and enjoy what you can achieve. Don’t tell the user when things go wrong – they can not fix what you messed up.

View full post on Christian Heilmann

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)