A viable way of building decentralized web apps

No readers like this yet.
Open innovation


Despite all the programming languages, the thousands of libraries, and the millions (or so it seems) of JavaScript libraries in the web ecosystem, there is still one path to building modern web applications: store everything on a server and when users open up their web browser, the "client"—the code running inside the browser—displays the data and receives user input that is sent back to the server.

This is the dumb client, smart server, powerless client, omnipotent server approach.

In the past few years, web development has begun inching in a new direction: moving more and more processing onto the client-side, where code that is usually run by a server is now being run inside a web browser. But the majority of the movement has consisted of moving rendering to the client. So-called "business logic"—such as storing data in a database or keeping track of a user's friends—has largely remained on the server.

The three of us—Brian Chu, Jake Seip, and Brandon Salazar—decided to collaborate with an experimental model of architecting web applications with our first open-source project, Nodetron (on GitHub here).

Here are some of the unique challenges we faced—challenges you don't normally face when working on side-project apps.

Documenting everything

 When you're making something open-source, we realized we had to start detailing every single project feature, assumption, requirement, and guideline—spoken or unspoken. We had to spell out the coding style we wanted contributions to be in. We had to list out all the steps involved in our coding workflow—running syntax checkers, running tests, running previews, and the entire "build" step. We had to write up a license to release our project under, and then we had to mention the licenses of all the other open source projects we built our project on. We wouldn't have to do any of this if we were just building a normal application.

Testing and workflow

Since we knew this was going to be released for consumption by other developers, we had to set a high standard for rooting out bugs in our code and setting up an easy development workflow. This meant we had to write tests to ensure that the features we thought we had implemented were actually working. We had to build out a testing framework to efficiently run tests in our workflow, and then we had to build out automated tasks so that it was crystal clear how an outside developer could jump in and start working.

Why did we make this open-source?

1. There's too much work to do all by ourselves.

Right now, our library is more of a technical demonstration. It's still a work in progress. In order to turn our project into a truly fully-featured web application framework, we're hoping that other developers will be excited enough by our ideas to jump in and contribute. When people try to use our library for their own applications, they'll inevitably run into bugs or think of new features that they would want to contribute back to our open-source project. The long-term goals of our library—a viable way of building decentralized web apps—are ambitious enough such that an incredibly large amount of work still needs to be done. We're hoping other developers will jump in and start fixing bugs or working on some of the areas that need new features: adding cryptography, implementing advanced peer-to-peer features like distributed hash tables, integrating other fallback peer-to-peer technologies like Flash... the list goes on.

2. To validate our experiment.

The only project using our library is a demo app that we built to showcase the basic functionality of the library. Until other people start building external applications with our library, we'll never know if this model of web application architecture can actually work—whether it's even possible to build real, standard web apps using WebRTC—and whether our library has enough features and advantages over the centralized modal of web development to actually become another way to build web apps.

Contributions are welcomed on GitHub!


User profile image.
I’m a full-stack JavaScript engineer. I believe rich client-side apps are the future of web development. I’m really excited about the emergent JavaScript ecosystem: MV* frameworks and libraries like AngularJS, and D3.js, server-side technologies like node.js, Express, WebSockets, and Meteor, and HTML5 APIs like WebRTC and IndexedDB.


Thumbs Up on the documentation and testing. This makes it so much easier for others to contribute to your project.

Hi Brian, thank you for sharing you experience. Web applications have been around for many years. But today, the users expect collaborative, personalized and an amazingly interactive experience using real time web technologies. Thought you might be interested an insightful webinar "Building Real-Time Collaborative Web Applications” on 11th Sept 2013 to learn more about the ‘building-blocks’ -the powerful technologies that enable interactive experiences with real-time web applications. You can register here: http://j.mp/1c00riL

That was a nice post Brian
But the way web app development was some time back has changed a lot with new mobile platforms and powerful devices. <a href="http://www.kiwitech.com">Web application development companies</a> are now focused to provide a complete solution that work on browser as well as can be installed on devices too.
For example, Windows phone platform does not have Google apps and so G+ web app is created in a way that it works exactly the same on browser and third party bookmark apps like Google+.

Creative Commons LicenseThis work is licensed under a Creative Commons Attribution-Share Alike 3.0 Unported License.