The Reasoning

The internet is a wonderful network. Despite being built on nothing but aging hardware and infrastructure not designed to withstand the use we are now putting it through, the advantages of it as a platform far outweigh the cons. It’s (mostly) global, so your information can reach the largest audience imaginable. It’s built of semantic building blocks designed for computers to understand, so building assistive technology to expand that audience even further to visually impaired or compromised people is entirely possible, and the vast majority of that technology is compatible with most major web browsers. The languages we use to build the content are all relatively high-level and surprisingly resilient, able to handle broken code that would refuse to even compile into an executable on lower-level languages. And finally, and this is a relatively recent development, as all of the browser vendors continue to move towards a solid agreement on how the web should be rendered, the content available on it can be a quality experience regardless of the platform your users use to access it.

Or to reduce that idea to its core principles, largest possible audience, potentially lowest development cost. Companies have long seen those two principles together and wondered why we couldn’t mix the beauty of the web with more traditional desktop software. Why couldn’t you do your spreadsheets and image editing online, where you could access your work from any web-accessible device, and get the same productivity anywhere? It’s an appealing idea, and it’s been hounding us for more than 20 years now.

1990 – 2008

Remember This?

The whole dream started in 1995, when the web browser Netscape (some of the developers would go on to create the Mozilla Foundation and Firefox) introduced a client-side scripting language called JavaScript. Famously, JavaScript was prototyped in only 10 days. It was designed to match Java in syntax as closely as possible because of a partnership with Sun Microsystems, but it is otherwise unrelated to the other language. JavaScript brought with it the ability to dynamically change web pages based on user input and activity, but at this point, it was confined only to the browser. Under normal circumstances, JavaScript only has access to the webpage and the server that loaded it. It doesn’t have full access to a user’s computer; so, it can’t do things like save files or access dedicated pieces of hardware for things like rendering 3D graphics, networking, or printing—except in very limited ways, all controlled by the browser.

This was a good state for security, but it put a bit of a hamper on the dream of sprawling web apps replacing traditional desktop software, so a number of methods were implemented. In 1996, Macromedia introduced Flash. Its original intention was to play back vectored animations, which could deliver high-quality animations with comparably small file sizes, and also came with its own scripting language. Since Flash was its own application that ran outside of, but integrated with, your browser, it had access to your computer; and depending on what your settings were, it could allow web pages to run the gamut of that access. This meant it was easier to do things like draw a vectored image online, and then save the result to your computer; however, it also meant that an unscrupulous developer could do things like, drop and run malicious software directly onto your computer—all without your input.

In 1999, JavaScript’s older cousin, Java, started using “Web Application” as a concept in its documentation and features. There were also general advances in browser technology, like the introduction of the underlying structure we know today as AJAX as an ActiveX object. This allowed webpages to communicate back and forth with the server, without the user having to reload the page, allowing things like online chat systems or infinitely scrolling webpages. Both Java (Cross Browser) and ActiveX (Internet Explorer) added support for websites to host online “applets” written in more robust languages capable of accessing more of your hardware, and potentially adding more functionality to these websites, but also opening them up to more abuse.

Time went on, and concepts like AJAX were integrated into JavaScript and browsers as standard, rather than relying on external applets to enable them. Silverlight came onto the scene to compete with Java, Flash, and ActiveX, which were all being de-emphasized due to security concerns.

2009 – 2019

Node.JS, the serverside JavaScript framework.

Around 2009/2010, a number of developers started to get the idea that maybe their failing had been trying to extend web browsers specifically. Trying to run code, hosted by a website, directly on a computer can create all sorts of security issues; but, what the developers really wanted was the huge audience, the ease of updating, and the low development cost—and all of those could be brought to the desktop without relying on the web browser to do all the heavy lifting. This is when Node.js was born, itself building off of the work done by Netscape to bring JavaScript to server-side applications in the 1990s. Node wasn’t originally created to make desktop applications, but it was created to make front end and back end website and server development as close as possible to each other. By replacing other languages, like Python or PHP, Node hoped to make web development even simpler by making the primary scripting language, JavaScript, the same on both sides of the interaction. But giving JavaScript direct access to things like the filesystem and server shell meant that even more complex things could be done—and, if you think about it, a server is nothing more than a specialized computer, so why couldn’t you port Node.js to a normal desktop environment? But why stop there? Why couldn’t you just pull over HTML and CSS and simplify the process of creating User Interfaces (UI) as well?

A number of projects in this vein were introduced. The most successful of which (for now) seems to be a project called Electron. This project takes Node.JS and integrates it with an embedded Chromium browser (the open source portion of Google Chrome) so that an entire desktop application can be written in web languages. Its largest benefits include decreasing development time, making cross-platform applications incredibly easy to create, and the same level of access to the hardware that you might get with a native application. The major downsides are that because it is cross-platform, it carries with it everything it will need to run, even if the operating system already has tools available for it to use. This makes Electron applications much larger than similar applications written in more traditional ways. Additionally, while it has access to the hardware, because JavaScript has to be parsed first, then the underlying Node.JS implementation has to do what the JavaScript requested, it cannot be as fast as a well-coded application that can compile directly into a binary executable. This is the same reason that for the first couple of generations, game consoles were capable of doing much more graphically than dedicated computers could. Computers had far more layers between the application and the display hardware, and they could not apply the same sort of direct control that a PlayStation or an N64 could, meaning that things that ran fine on those consoles took much more horsepower to work on a home computer.

While these are large downsides, a number of well-known commercial applications have been developed on or ported to Electron because of the popularity and benefits. From code editors like Atom and Microsoft’s Visual Studio Code, to long-lived projects like Skype, to new applications like Discord and others.

There are a lot of developers who are unhappy with the compromises that Electron makes as a platform, but it seems like a logical evolution of the concepts that JavaScript, Java Applets, and ActiveX were all created to serve. And by hosting all of the code locally on a machine, it means the computer’s own security systems can scan the code before execution, and the user can lock down permissions based on their trust of the application, without a worry that other applications on their machine will be impacted because of it. It’s still not a perfect solution, but it does mean that now is a great time to start thinking about desktop and mobile apps to better serve your business. We are already hard at work on making platforms like Electron work for us; let us make them work for you.