Everyone has heard, “if all you have is a hammer, everything looks like a nail”. It’s an old adage that almost feels like cheap, dime store philosophy; especially in an echo chamber like Twitter where everything is a sound bite. But the cautionary tale it’s so famous for is profound and important to appreciate in the abstract world of software engineering.
Node.js by design is a very sparse platform. It’s primary purpose is to bind javascript to some parts of the operating system. It’s largely doctrine agnostic. And ultimately, users are left wondering where to start when they write a program.
You first need to consider the scope of Node.js. It's much larger than that of a Web Server. Remember, it was made for easily building fast, scalable network applications. And Web Servers are a subset of network applications. Developers are coming from platforms where they spent almost 100% their time inside a Web Server. They want a nail, we can give them that. Express is an excellent nail, you can hammer the shit out of it and it will hold fast. But if you have complex requirements that may go outside the conventions of a typical web server, we should talk about frameworks.
Aside from dependency injection, interfaces, configuration and the usual aspects that define a framework there are two fundamentally different types of frameworks, both with distinct benefits.
A monolithic framework is characterized by its majority being integral to its functionality. It solves a particularly narrow set of problems very well. This isn't a bad thing. This is an excellent solution for developers looking for a more "hands-off" solution.
The deficiency occurs when the interests of the developer’s program go outside the original design of the framework. Since monolithic frameworks don’t decompose well, it can become a nightmare for evolving scenarios such as rolling requirements.
Rails is an example of a monolithic framework. It's built on the philosophy of convention over configuration, effectively transferring the engineering concerns to the framework and the operational concerns with the developer.
A Composable framework subscribes to the unix-philosophy. It is made up of discrete components that work equally as well independently as they do together. It will break apart routing, middleware, templating, configuration, etc. into completely isolated components.
Doug McIlroy, the inventor of Unix pipes summarizes the unix philosophy by saying “Write programs that do one thing and do it well. Write programs to work together. [...]” Here are some of the relevant ideas;
- Make each program do one thing well. To do a new job, build a new component rather than complicate old ones by adding new features. Expect the output of every program to become the input to another, as yet unknown, program. This is the concept of black box programming.
- Design components should be tried early, ideally within weeks. Clumsy parts can be tossed out and rebuilt. This expedites the life cycle of the framework, which has historically been difficult with monolithic frameworks.
- There are a lot of compelling ideas here. you can research the rest of them on your own =).
This type of framework is not without it’s own deficiencies. Although more flexible, it’s obviously more complicated for a developer to take the building blocks and understand how to fit them together.
Flatiron is a composable framework. It has all the makings to roll your own framework. It's components takes the higher level ideas from the unix philosophy into consideration (as in, communicating through JSON rather than text streams).
Consider the impact of the emerging technologies. Take for instance new communication protocols. When Sinatra was conceived, RESTful AJAX was the nucleus of Web 2.0. A very short time later we’re seeing libraries like node-SPDY or Socket.IO, libraries that multiplex bi-directional streams involve different design patterns. Your framework's ability to interface with new technologies, ones that potentially become the center of attention will have a big impact on the life span of your product.
Would you build a next generation trading platform for a major financial institution using Rails? No. The more complex your application is, the less an out of the box solution is appropriate.
There is no one-size-fits-all framework. Stop looking for it.
Although there are no unicorns or magical frameworks, you can be a part of the natural selection process that determines the most usable ones. The entire ecosystem of Node.js is immersed in the Github revolution. Find a framework that you think has potential, and get to know it. It’s more difficult to grok someone else’s code than it is to write your own from scratch. Even harder to grok large code bases. But when you make a contribution to an open source project, you not only contribute code, you aid consensus, validate an initiative and gain arbitrary internet points.
Can I use some of it in my talk?