I used to hate JavaScript.

For a year or so in my career, I attributed most accessibility crimes to developers using JavaScript. During this time I was working in a split role as a full-stack developer and QA tester. For a few months of the year, my job involved QA testing digital educational content developed for publicly funded technical schools. This content consisted of websites packaged onto CD ROMs. There were stringent accessibility requirements for the content to pass QA, and it was my responsibility to catch any failures and report them back to the development teams to fix.

JavaScript was still slow, and both Chrome and its fast V8 engine did not exist yet. But with the surge in popularity of jQuery, a library designed for productivity and compatibility, more complex and impressive websites became possible. Tabbed interfaces, accordion-style animations, and modals exploded onto webpages seemingly overnight. In order to organize the large amount of information contained in these educational websites, UI designers and developers resorted to these techniques often. However, dynamic page content can add complexity to ensuring good accessibility practices, particularly when it comes to focus management and keyboard control. It was in this role that I first observed how easy it is to break expected behavior for many users on the web. Instead of blaming a lack of developer awareness or other human-related causes, I laid the blame solely on JavaScript. An entire language condemned.

At the time, I never would have believed you if you’d told me that JavaScript would become a hugely popular language that developers would use to redefine traditions and push technical and community boundaries. (Over the last decade, the JavaScript community has set a high bar for conference inclusivity, including offering live captioning, child care, and codes of conduct; TC39, the steering committee for JavaScript language progression, has worked to reduce the red tape and bureaucracy that often serve as deterrents to wider-spread community involvement.)

Several jobs later, I inherited a very large JavaScript-heavy frontend codebase. My stubborn refusal to learn much JavaScript prior to this moment was a rather frightening disadvantage, so I began to put in the effort to pick it up. Over time, I realized that JavaScript-driven dynamic UIs on the web can still be accessible when care is taken and teams are empowered to design and develop with best practices. This journey from loathing to enlightenment has been one of the more impactful ones in my career. It taught me that struggles with a language are not always about the language itself. I have not actively disliked a programming language since.

The ease with which JavaScript enables developer productivity and flexibility is notable. Outside the browser, JavaScript has become the popular choice for building command line applications and backend services, thanks to the Node.js runtime. In the browser, the language is augmented with a glut of powerful APIs it can access. Network requests, storage, worker threads, canvas, video, audio, and many more are all within reach. The asynchronous nature of JavaScript shines when it comes to reacting to direct user input and other events. It is no coincidence that web developers are constantly pushing the language to new limits. We’re seeing innovative projects such as Electron and now React Native that help build applications for the desktop. I believe this came about because JavaScript, coupled with a browser (along with HTML and CSS), has enabled the development of user interfaces that are fast to prototype, easy to patch, cross-platform, and accessible.

That’s not to say that other languages and platforms do not provide these conveniences, or that there are no drawbacks to building certain applications this way. Shipping and running an entire browser shell, as required with an Electron application, chews up both download quotas and CPU cycles once installed. React Native applications can run into performance bottlenecks, particularly when communicating with native modules. But there is promise in these early explorations of using JavaScript for things it wasn’t meant to do.

On that laundry list of things that JavaScript wasn’t designed to do, we can find some delightful surprises, including new uses involving hardware devices. I’m not talking about responding to your mouse and keyboard input; the hardware devices we’re considering here go beyond your standard peripherals. Think 3D printers, sensors, custom peripherals, gaming consoles, hobby microcontrollers, and, yes, robots!

For many years now, an ecosystem of JavaScript developers called the Nodebots community has flourished.Nodebot” is short forNode.js Robot,” and describes any device that can be interacted with and controlled by JavaScript. This community has achieved a fairly lofty goal: to bring down the barrier to entry for folks interested in learning how to write applications for hardware devices. Traditionally, code written for devices tends to be in a much lower-level language, such as C or C++. While learnable, these languages can be harder to work with and also tend to intimidate folks, especially those who are new to coding.

TheHello World” of a Nodebot is as follows:

const five = require('johnny-five');
const board = new five.Board();

board.on('ready', function() {
  const led = new five.Led(13);

The above code uses robotics library Johnny-Five to create a new board instance for a plugged-in device microcontroller and, when ready, blinks a light connected to pin 13 on the board.

The JavaScript syntax probably feels very familiar to you. That might be in part because the author of Johnny-Five, Rick Waldron, envisioned a robotics API that was as simple to use as jQuery. The developer empathy and cross-compatible nature of jQuery is easy to spot within Johnny-Five. jQuery-inspired robotics as a concept convinced me that there’s value in building bridges in unexpected places to see where it takes us as a whole. To that end, a language can be a jumping-off point for new ideas.

The traditional tools available for creating user interfaces for device applications are subject to difficulties when it comes to creating a high-quality user experience. As a developer, creating a cross-platform application for a device that looks good while remaining productive has long been my white whale. This frustration led me to explore leveraging web interfaces to solve my robotics-related problems. Writing hardware drivers in JavaScript feels much like writing them in lower-level languages, but with JavaScript, you get much better dependency management and some garbage collection thrown in.

One of the best examples of a rich and delightful device web interface is Arduino’s Arduino Create platform. The Arduino Web Editor within the Create platform is a truly magical experience for interfacing with their microcontroller boards. There are no complicated toolchains to install and no need for a command line. The UI is gorgeous. JavaScript is at the heart of what makes this possible.

Programming languages extend beyond their syntax, and take on a life of their own when people start using them. JavaScript is living proof of this.

I see enormous potential in the idea of using web interfaces for devices in order to offer better user and developer experiences. The Progressive Web App paradigm is a step in the right direction towards ensuring that developers produce high-quality applications when building with JavaScript and accompanying web technologies. With the recent proposal and first implementations of the WebUSB specification, it seems that potential is being taken quite seriously.

At the very least, the use of JavaScript with hardware is pushing us to rethink old and clunky tools. No matter how things turn out, we’re finally seeing some innovation in the space to challenge tired assumptions.

The fateful choice by browser vendors to adopt JavaScript as the programming language of the web guaranteed its stubborn prevalence to this day. But programming languages extend beyond their syntax, and take on a life of their own when people start using them. JavaScript is living proof of this. If robots can find a home in it, then it truly is remarkable.