The Future Of Browser-Targeted Development

Welcome to another Knowledge Drop!

As longer-ish time readers know, I’ve been heralding the need to get up to speed with modern web development. I herald this since I’m fairly convinced much of what we expect to be done on traditional “servers” is quickly migrating to both “the edge” and the browser you’re reading this post in. WebAssembly (WASM) is a big part of this shift, but an even larger, emerging part is something called “WebContainers”.

You won’t be a WebContainer expert after reading this Drop, but you should have sufficient familiarity, and sufficient external resources to dig in and be prepared to embrace this latest advancement in how we build and engage with web-based applications.

WebContainers: The Future of Web Development

Yes, this section has an oddly brazen title for one of my tomes, but I think I’ll have you convinced by the end.

Web development practices continue to rapidly evolve, and both local compute + increased browser capabilities are now sufficiently powerful enough to enable a bona fide revolution to take place in the form of something called “WebContainers”.

WebContainers are lightweight, isolated environments that run directly in your browser, enabling you to develop, build, and deploy web applications without the need for a traditional server or back-end infrastructure. They are powered by something called “WebContainer Core”, an open-source project from StackBlitz that aims to bring the power and flexibility of what we traditionally consider “containers” to the web.

These “web” “containers” leverage modern browser APIs and WebAssembly to create a virtualized environment that can run Node.js applications directly in the browser. This, effectively, means that you can develop, test, and even deploy your applications without ever leaving your browser or relying on external servers.

I gots 99 problems. Which one(s) do WebContainers solve?

Fair question, since we humans are pretty good at creating technology for technology’s sake.

WebContainers address several pain points in web development, including:

• simplified setup: with WebContainers there’s no need to install and configure complex development environments or back-end infrastructure. Anyone that’s tried to play along at home with my WebR machinations likely has felt this pain in real time.

• instant collaboration: Share your projects with others in real-time, making it easier to collaborate and iterate on your code. No server auth. No privilege management.

• reduced latency: Since everything runs in the browser, there’s no need to wait for server responses or deal with network latency. Living in rural Maine means I have frequent internet downtime. I already appreciate the local freedom service workers have provided, and WebContainers aim to do that for the whole app stack.

• enhanced security: WebContainers are isolated environments, reducing the risk of security vulnerabilities and data leaks. I will never use the term “bulletproof security” for anything, but you’re far less likely to be pwnd with WebContainers unless you use one that’s already been compromised.

OK, fine. But, what’s in it for me?

It’s always about you, isn’t it?

Again, fair point.

WebContainers open up some new avenues for web development, including serverless web applications (i.e., you can build and deploy web apps without the need for traditional server infrastructure; Jeff Bezos will just have to find some other way to afford a new yacht); and ultraportable development environments, letting you develop your apps on any device with a modern web browser, without the need for local installations or configurations.

Um…This sounds far too good to be true.

Always the skeptic, eh?

While WebContainers do offer some obvious benefits, there are some real (potential) downsides to consider:

• browser compatibility: WebContainers rely on modern browser APIs and WebAssembly, which may not be supported by older browsers or certain mobile devices. Yes, this will leave out some fraction of the developing world and those in worlds 1-3 who may be running with old kit. All I can offer is that those folks won’t be left behind for too long, but it is a real consideration.

• performance: running Node.js applications entirely in the browser may lead to performance limitations, especially on lower-end devices or slow internet connections (you have to load the content from somewhere). The WebContainer APIs lean heavily on the compute power of your local CPU and browser, and the folks noted in the first bullet will be impacted by any choice to use WebContainers for your apps.

• presently limited use cases: WebContainers are ideal for tasks such as interactive coding experiences, production-grade IDEs, programming tutorials, next-generation documentation, AI applications, and, perhaps, training new team members in a safe environment. However, they may not be suitable for all types of web applications or projects that require more complex/traditional server-side processing.

• dependency on third-party services: If you’re using the managed WebContainer service provided by folks like the aforementioned StackBlitz (again, the creator/main purveyor of this tech), you may be dependent on their infrastructure and support. However, the WebContainer Core technology is open-source, allowing you to self-host and maintain control over your development environment.

Having noted some of those very real potential downsides, it is important to also note that WebContainers have been “battle-tested” by scads of users and continue to gain traction in the broader web development community.

You kind of glossed over security concerns that, I thought, might be important to you. What gives?

Forgive me, I’m just rather excited about this tech.

While WebContainers provide several benefits, there are 100% definitely some potential security concerns to consider:

• isolation: sure, WebContainers run in isolated environments within the browser, which reduces the risk of security vulnerabilities and data leaks. However, it is essential to ensure that the isolation is maintained and that no sensitive data is inadvertently exposed to other parts of the application or third parties. You are more likely to cause a security issue with the data you expose vs inherent security flaws in the tech.

• dependency on third-party services: if you choose the easy (lazy) route and use managed WebContainer services, you are 100% dependent on that infrastructure and support, which could introduce security risks if not properly managed by the provider.

• browser security: WebContainers rely on modern browser APIs and WebAssembly, which are designed with security in mind. However, browser security is an ongoing concern, and it is crucial for you and your users to stay up-to-date with the latest security best practices and browser updates.

• user code execution: WebContainers enable users to execute Node.js applications and operating system commands in the browser. While this provides a powerful development/app experience, it is essential to ensure that user code execution is properly sandboxed and does not introduce security vulnerabilities.

Starter resources for WebContainers

WebContainers as a topic are far too large to cover thoroughly in one Drop edition (even a Knowledge Drop).

• WebContainers.io: This is “the” official website for WebContainers, featuring documentation, examples, and community resources. Honestly, to get familiar with this tech, just tap “Getting Started” once you hit that link. It’ll all be super clear. I had the “Vite” default app up and running, in-browser, in less than sixty seconds.

• StackBlitz blog: StackBlitz started this craze, and their blog provides in-depth articles and tutorials on WebContainers and related technologies.

• WebContainer Core GH repo: this is the self-hostable open-source project behind WebContainers, where you can find the source code, contribute to the project, and report issues.

  Share

FIN

WebContainers represent a significant leap forward in web development, offering a more streamlined, efficient, and secure way to build and deploy web applications.

A big reason I chose to do this Knowledge Drop, now, is that WebContainers finally work in WebKit. This means anyone with a modern iOS phone or iPadOS tablet can dive right in and start creating without the need for a fancy server.

I’ll be cranking on examples over the coming weeks/months, so stay tuned for ☮