Hello, World

TLDR; Socket Runtime gives Web developers the ability to build apps like Figma or Telegram, with absolutely no backend or Cloud services required.

Browsers are no longer the only client-side runtime

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 its success. It’s very much a public commons and a labor of love.

The Web has come closer to Write once, Run anywhere than any other platform since Sun championed the concept in the 90s. Unfortunately, browsers can't and won't do everything we need. The Web is caught between commercial incentives and technical innovation. Because of this this, we’ve seen projects like Electron and Cordova welcomed over the years.

The argument for Universal Apps is strong. It's unreasonable to hire and retain experts who can build, debug, and maintain codebases for iOS, Android, MacOS, Linux, Windows, and ChromeOS. Most of us already have Web developers, DevOps engineers, SREs, etc.

Some of the most popular software to emerge in the last 10 years has been built with non-browser runtimes — Visual Studio Code, Notion, Signal, Slack, and Figma, to name a few. There is a clear demand to build universal apps.

Evolving the client-side runtime

We heard harsh criticisms of the solutions in this space, and thought most of them were valid — none were designed to run on desktop AND mobile. They produce enormous downloads, use significant memory, require learning a new language, and casually diverge from web standards. Their organically evolved APIs can lead to a fractal of complexity. The list goes on.

We saw other opportunities in taking the Web outside the browser.

Almost every app wants to help people communicate. Directly or indirectly. But Cloud services are so complex that you can literally spend an entire career learning how to glue them together — countless hours debugging and optimizing them. The complexity is a big risk, but so is the cost; as demand for your app scales up, so does the cost of cloud services.

Outside of the browser we have been able to introduce the necessary primitives needed to give Web Developers a new class of network connectivity that doesn't require the cloud, or any infrastructure at all. Now we have UDP on every OS, as a JavaScript API!

A new class of software

What if you could write one code base that ran on any OS, and it could connect everyone, with and without the cloud? What if you had more autonomy? What if there was no middleman? What if you didn't have monthly bills? What would you build?

Introducing The Socket Runtime

To evolve this space, we created a new client-side runtime. It was built from the ground up and designed for web developers to create apps for any OS, desktop AND mobile. It was designed not only for client-server, but also P2P and local-first design patterns. This is how it fits into the ecosystem.

Key Features

• 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. For example, instead of React Native, you can just use React.
• The runtime makes the OS's WebView component consistent for web developers. All major operating systems use it to build portions of their own UIs, so we don't need to ship an entire copy of the browser with each application, and we can output a binary that starts at about ±1Mb on desktop, and ±12Mb on mobile.
• The "backend" process allows any language, compiled or interpreted, and it is entirely optional.
• APIs that accommodate Peer To Peer networking and Local-First design patterns.
• Custom protocol registration for interlinking between the Web and socket apps (in progress).
• We try to resist inventing new paradigms. We try to lean on web standards where ever possible. For example, using CSPs, etc.
• Plug-ins should be possible, but core capabilities need to work in harmony. So most everything you'll need is batteries included. Packaging, Code Signing, Notarization, Networking, Bluetooth, etc. all need to "just work" out of the box.
• The project itself is as small as possible. We want to optimize for maintainability. We want to resit abstractions and almost all 3rd party dependencies.

As of today, this project is leaving the alpha stage and entering beta. Visit the project on github, give it a star if you want to support it, and join our community!

This is the first post in a series, so follow us here and here as we release a new technical post each week.