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!
3 Comments