Javascript is all you need

). While keeping all app logic in JS. This is the approach of react native. Along with expo it gives you a complete framework for building native apps (for whatever that means) with JS.

If you think this is an obscure way if making apps, just look at the more well known ones like: vscode, desktop versions of slack, signal, figma, whatsup, spotify and many more

Servers/cloud (back-end)

Then there is the server side of javascript. The concept is quite similar to the previous case, but instead of the whole browser, only the JS engine from a browser is used. This is of course NodeJS, and its newer siblings Deno and Bun. There are many ways to bundle the engine with your js code, from docker to creating a single js+runtime executable file.

Conceptually you run nodejs and give the path to your js app and voila. NodeJS (and the rest) implement many APIs useful for headless (gui-less) operation, for example reading and writing files, connecting to databases and creating http servers. The later is the most common use case.

A relatively new technology is the use of server-side for creating dynamic html. Relatively because NodeJS html templating engines such as handlebars have been with us for more than a decade. But with React server components, the use case gained a massive mindshare boost.

Static web

Driven to extreme, for content that does not change often, javascript frameworks such as Gatsby and Astro offer static-site-generation or build-time-rendering. Gatsby will turn your react app into a fully static and highly optimized web, that does not need javascript once deployed. Pushing your web into production means copying the build output to a cdn. Or (for example) you can use github+azure static web site for a fully integrated development process.

Scripting and tools

The file apis of NodeJS (and its siblings) and the wide array of packages, made it (not just) my favorite tool for scripting and data cleanup and transfer.

Embedded

Finally a rather specific usecase is embedded js. Using javascript either as a scripting language within a larger app, or securely running third-party js within your app. (No, we dont mean eval;) again, there are multiple options to choose from. JSinterpreter is nice, since it allows to run JS within JS. This makes it a great fit for running untrusted javascript

Then there is QuickJS. Why would anyone use this? Have you ever used Figma?

Language

Because of backwards compatibility JS is quite a quirky language. There are many concepts that are unique not shared by any other languages. Such as prototypes, null and undefined. Then there are concepts that work very differently from most other languages, comparison and value coercion being the most obvious example. These days, you can ignore the arcane features, but you do need to know about them, because they do come up from time to time. Also gotchas such as if(0) being false and if(“0”) being true can bite you if are not careful.

Apart from the few gotchas, JS is a modern language of the C family of dialects, with classes, garbage collection, optional typing (with typescript) and optional asynchronous computation model. These days modern frameworks such as react promote the idea of data immutability and functional programming. Thus we see functional style features being included in the base language (library) such toReversed, toSorted.

Compared to other languages, JS does not come with a “first party” or “standard” library of common functionality. Sometimes functionality is provided by the browser environment (such as image manipulation, networking, xml). But most often you have to look for a 3rd party package in the massive npm catalog. We do like the spirit of collaborative development, but managing a zoo of packages (of which most have further dependencies) is an extra job role that is not optional.

Development process

VScode is the JS environment, for front end (eg app) or backend (server, cloud) or even both at the same time. Yes yes some hermit programmers that come out only at night will tell you tales of the ol’ days of programming in Notepad. Just because you can, doesn’t mean you should.

Project management (building, testing, launching, dependencies) is usually handled by npm. The package.json file is the conceptual equivalent of your VS project file or very roughly a make file. As the file extension suggests it is just a json file, which can be edited by hand.

Most frameworks provide bootstrap scripts that will create an initial package.json file for you, with all the dependencies and management scripts included. Create-react-app and Vite are the more widely know tools, Gatstby and Astro come with their own bootstrap and build tools.

A great feature that is automatically enabled by most frameworks is hot code reload during debugging. What this means. is that you start your debug session (npm run start) and qny code changes are automatically build and pushed to the browser. We cannot stress enough what a productivity boost this is and it is very hard to go back to the more traditional write build debug repeat cycle.

The ghost of Javascript Past

Now let’s look back on how we got to this Cambrian explosion of javascript ecosystem projects. The history itself is interesting enough, and we think it is crucial to understand where we came from to ensure the progress continues.

The prehistory of browser wars, netscape and internet explorer is fairly well documented. Let’s recap quickly. Http and html (www) started with Tim Berners-Lee at cern. A bunch of startups understood the groundbreaking potential and built “browsers”. The most well known one being netscape navigator. Microsoft quickly embraced the idea and integrated a browser deep into its Windows OS. Combined with Windows dominance this effectively killed any browser competition, and thus slowly also the evolution of web technologies.

Nevertheless the first browser wars brought javascript, the document object modal standard and the XmlHttpRequest. All the major building blocks were in place in 2001, but thanks to virtually no competition, javascript (and the web) remained slow, incompatible, unfinished and standard-based only in theory.

Third party browser plugins - Flash - tried to work around the stagnation. Interestingly Flash used JS internally. Continuing with the successful tradition Microsoft created a clone of flash called silverlight hooking into the c#/.net environment. This story might have ended here, was it not for the smartphone wars.

Two things happened around 2007. Microsoft completely missed the smartphone boat and Apple’s iPhone dropped with the force of a megaton atom bomb. Apple embraced the open web and bundled a high performance fully featured web browser with its OS - Safari (webkit engine). Remember, smartphones and pda-s only supported some version of watered down web. Either missing most features or relying on a server to dumb-down the web pages for phones (Opera). For the first year of iPhone there was no app store, and no third party sdk for iPhone apps. Apple actually expected developers to build apps with web technologies!

To be fair, Apple was not the first mobile vendor betting on web, it was Palm with its WebOS. However Palm tried to play the embrace-extend game, instead of going with the open - standards-based web.

With the smartphones conquering the world, the browser wars restarted. It took Microsoft 8 years to actually do a meaningful upgrade of Internet Explorer with version 9. (Version 6 was released in 2001). By that time it was too little too late, Google’s Chrome integrating (later forking) webkit technology began its meteoritic rise. It felt like new web features arrived daily, along with ever faster performance.

On the heels of progress in the browser technology came another interesting development. Chrome or more specifically the Javascript engine became the core of NodeJS, allowing javascript to rule both the browser and the server.

In the more past, after an attempt to build a new engine (chakra) Microsoft gave up and integrated google’s blink (the webkit fork) into its edge browser. Catching up to today, we live in a webkit world. With IE dead and Firefox largely on life support (2.6% share) there are only Safari and Chrome (and its myriad of skins such as Edge).

Future

The Javascript world continues to innovate at a breakneck speed.

With server-less being the newest cloud buzzword we have Amazon embracing the QuickJS with https://github.com/awslabs/llrt

Then there is Bun, that tries to integrate build, runtime and the kitchen sink for even higher productivity.

But, there are also clouds on the horizon. With the effective Chrome monopoly, US authorities are deciding whether to break up google and turn Chrome into a standalone company. Since Google is effectively bankrolling the development of the browser and Firefox too, it is difficult to see how the web progress will be financed.

Thankfully there is not only bad news. After a decade there are multiple new browsers racing to version 1 and their turn to claw marketshare from Chrome. Will Ladybird and Flow restart the browser wars?

We certainly hope so!