Socket — A New Runtime for the Web

— Written by heapwolf

The Web has the largest, most active, and fastest growing developer community. It has the best documentation. It has a massive ecosystem of frameworks, libraries, and well-known design patterns. The Web also has the most companies invested in it. It’s very much a public commons and a labor of love.

Unfortunately, browsers can't or won't do everything we need. Beause of this this, we’ve seen projects like Electron and PhoneGap welcomed over the years. While the harsh criticisms about them are entirely valid, there is clearly a demand to use the web stack to write software. Right now it takes extraordinary effort to get right, but some of the most popular software to emerge in the last 10 years has been built this way — Visual Studio Code, Notion, Signal, Slack, and Figma, to name a few.

Evolving the space

To evolve this space, we needed a new runtime built entirely from the ground up. Some of the guiding principles and key ideas are...

  • The same plain old HTML, CSS, and JavaScript should run on desktop AND mobile. This means people can bring their favorite front end frameworks to the party.
  • The runtime should use the operating system's WebView component. Operating systems use it to build portions of their own UIs, so it's actively developed, and these days it renders quite consistent across platforms. This also means we can output a binary that's about ~1Mb on desktop.
  • The "backend" process should allow any language, and be entirely optional.
  • This project should be as small and maintainable. Resit abstractions and almost all 3rd party dependencies.
  • Introduce as few new ideas as possible, leaning on web standards where ever possible.
  • The CLI should be learnable for any web developer.
  • Plug-ins should be possible, but core capabilities need to work in concert so the ideal runtime is batteries included. Packaging, Code Signing, Notarization, Networking, Bluetooth, etc. all need to "just work" out of the box.

Beyond client-server

Another key motivation for building this runtime, is that we want to create more than just client-server apps.

Client-server is a many-to-one relationship, so servers are naturally bottlenecks. Scaling them turns into an incredibly complex distributed system of shared state. Cloud providers employ an army of highly paid plumbers to pipe together and unclog a tangled maze of eventually consistent black-box magic. The fact is, client-server becomes more complex and less reliable with growth. Client-server may start out cheap to incentivize you, but as your project grows, so does the cost.

All of that has changed. We're entering the era of ubiquitous computing. We're surrounded by hardware. And even though it's less reliable and less powerful hardware — small, frequent contributions form massive, and robust networks. Apps can connect directly, reducing expensive and unnecessary round-trips to the cloud. To take advantage of this, we expose the posix-like primitives as JavaScript APIs, i.e. UDP, Bluetooth, and FileSystem IO that p2p libraries need.

Getting started

All of this culminates in a small codebase and an even smaller CLI tool that builds a distributable binary with the runtime and your code.

$ ssc init
$ ssc build -r

This is project is pre-release stage, check out the docs and the repo. Over the next 3 months we will be heavily focused on stabilzation. This is the first post in a series, so follow us here and here as we release a new technical post each week.

P2P & Community News
Subscribe