Post-AmsterdamJS Thoughts: The Shape of Web To Come

Amsterdam JSNation was a wonderful experience that shone light on not just how the web technologies available to engineers are aiding existing day-to-day development, but how web experiences may look in 5, 10, or 15 years.

Here’s a non-exhaustive list of the topics touched on to various degrees during the conference talks: programming paradigms, PWAs, mobile, brain-computer interfaces, TypeScript/Flow/typing systems, WebXR, WebSpeech, software architecture/patterns, QA, e2e testing, IoT, isomorphic JS apps, team structure, graphics, game dev, service workers, reactive programming...

For a one day conference, AmsterdamJS had something for everyone. If you were looking for ways to improve your software practice in well-established dimensions such as end-to-end testing, Jenn Voss’ presentation included a good breakdown and recommendation of Cypress and approaches to structuring your team with respect to QA.

But while bread-and-butter topics such as testing/QA and specific frameworks will always be helpful, what stood out to me was the number of potentially revolutionary technologies rearing their heads and being explained or demonstrated for the AmsterdamJS audience.

I thought it would be fun to go over these technologies and do the ill-advised: try and predict their impact/adoption/timeline, and the larger picture of what the future of the web is. I’m ordering these roughly in order of less unknowns/less risk to more unknowns/risk, as some of these are already further along in adoption and specification than others.

Serverless/Static

Serverless technology has been underway for a while now, so it’s almost unfair to evaluate it in terms of feasibility, but it has significantly picked up steam as an idea within the dev community with the release and support of tools such as AWS Lambda and equivalents. Check the link if you’re unclear on what it is, but the tl;dr is that serverless technology frees developers from managing some of the lower-level sub-application pieces that might reside at the server level/in the DevOps bucket.

Unlike most of the other items on this list, Serverless patterns seem to affect the end UX less, moreso serving as tools to reduce development costs/increase velocity/increase simplicity. Most devs, especially back-end/full-stack devs, will know or have used a serverless pattern very soon or already have (even if they don’t call it “serverless”).

PWAs

Progressive web apps are next-level web apps that utilize design and implementation methods such as service workers, json-based manifestos, and “application shell”-based UIs to bring the user native-like behavior such as adding an icon to the phone’s home screen and a more stable experience. A web-based approach in this way can help by reducing the up-front data cost and overall investment required from users.

I expect a high rate of adoption within 2 years from many large corporations or other organizations with models that stand to benefit from increasing their mobile user-adoption rates and brand effectiveness on mobile web. To me this is an obvious, incremental push towards increasing the web’s identity as a first-class platform for applications of all kinds. Examples of progressive web apps.

WebAssembly

WebAssembly is one of the most exciting and hyped technologies to appear in recent years. It’s tough to explain succinctly, but the tl;dr is that it will allow you to compile languages like C++ and Rust into a target that will run in JavaScript environments and allow for debuggable, highly performant native-like applications.

The promise here is that WebAssembly will allow browser apps, Node, and presumably other js runtimes like Deno to run compute-oriented code ranging from AAA games to image recognition and offer the developer features like threading and more direct access to memory in the js environment.

Need more proof of the power of WebAssembly? Click here and change the number of skeletal models to 100. Compare it between WebAssembly and JavaScript using the dropdown and maybe you’ll get a more intuitive sense of what is possible with this technology.

The MVP of WebAssembly is already complete with many further features in active development like threads, garbage collection, and ECMAScript module support. Currently its much easier to find proof of concepts and demos out in the wild using WebAssembly, but as this article from Figma details, the benefits are quite material. That being said, there are still browser implementation issues and I expect another 1–2 years before it’s easy to find high-profile production applications and highly-used libraries implemented using WebAssembly (partially or wholly).

WebXR / Gamepads API

One of the most contentious topics of our time is the viability, timeline of adoption, and platforms involved in XR interface technology. At AmsterdamJS Diego Gonzalez demoed how browsers like Samsung Internet are already supporting WebXR, and the complementary browser-based Gamepads API. WebXR (aka the WebXR Device API) would enable you to navigate to websites that functioned as XR apps. (Here is a video I made on the differences between VR, MR, and AR)

Although the APIs mentioned are still in flux regarding their implementation details, they’re experimentally adopted by most major browsers, and dev frameworks like A-frame are receiving plenty of open source attention. I am quite bullish on the importance of 3D in the web going forward, and WebXR helps solve one of the biggest obstacles in XR right now, which is distribution of content (by leveraging the browser and using the web as a distribution platform).

That being said, I think there are still numerous obstacles in terms of developer/designer mindshare, consumer adoption, and hardware. I would look for adoption of WebXR for specific applications within domains such as architecture/AEC, gaming, and 3D modeling/art in around 4 years.

Final Thoughts

I think the question we should ask ourselves is, long term, why shouldn’t everything run in the browser? That is to say — why shouldn’t every application be reachable by a URL (or browser app) and quickly executable in a portable, OS-agnostic JavaScript/WebAssembly driven virtual machine? There are and will be reasons, but the default blocker “browsers just can’t do that” is fading more every day.

I estimate in about 5 years, the limitations of the browser will be (and will be perceived to be) considerably less significant than they are today; frameworks and patterns for developing 3D, compute-heavy, and otherwise richer native-like applications will see increased adoption, especially where it makes sense to leverage the distribution pattern of the web.

Furthermore, incremental improvements to the bread-and-butter technologies that are already important to the web, such as testing frameworks (like Cypress), programming paradigms (like reactive/async programming), and PWAs will increase the dev experience, user experience, and quality of web development in general.

It is an exciting time to be writing browser software; if you are interested in leveling up your career for the future, I suggest making time to study tech that relates to the points above that you may not be using already, such as WebAssembly or WebGL. Becoming familiar with 3D interface design patterns and interfaces may also prove useful.

What do you think, am I way off of the mark? Let me know on Twitter. Or, I’ll see you at AmsterdamJS next year!