As a programmer, it is the abstraction you live in the most that you will perceive as the platform.
Web developers live in the Browser, it’s their platform. Rails developers live in Rails, it’s their platform. And, as we are discovering, node.js developers live in node.js.
We build applications. Applications may initialize, create, hold, mutate, and eventually persist state. When examining an application you can discover the boundaries of working with state and from there you can identify the platforms it’s built on.
There has been a tendency to dismiss comparisons of Rails and node.js as apples and oranges. While each one is built at a different layer of abstraction, both are platforms and so this comparison is actually quite fair.
The way Ruby and Python tend to be run at scale for a web application is incredibly different from node.js. You can assume that a node.js process will stay up and serve thousands of HTTP requests. If you need to initialize global state for the application you will do it when the process starts, not when the first HTTP request comes in.
In Rails you would initialize all of your application when Rails is initialized. You cannot depend on a Ruby or Python process being up for longer than an HTTP request/response cycle so you use your preferred web framework’s init hooks to guide you.
Frameworks like Rails and Django have stepped up and addressed all the needs of an application, including state initialization, because they needed to. Application developers cannot depend only on Ruby/Python because the process model of their application is dictated by incoming HTTP requests so it is the job of Rails/Django to help them. They do a fantastic job, but this means that you can define the platform for an application as these web frameworks and they tend to be large because they have to be.
A web framework in node.js can, and should, do far less. It’s a much easier task than Ruby/Python because the process model will never be dictated by HTTP requests. This means that web frameworks in node.js can limit themselves to providing API that helps users work with incoming HTTP requests and only resolving state contained in that request’s headers & potentially its body. An application’s use of databases, templates, etc., are already provided for by node.js as long as a web framework follows standard node.js conventions.
This means that decisions a web framework might make, like using fibers or building its API entirely on a Promise abstraction, will severely limit its ability to integrate with other modules in node.js and also drastically increases the amount of work it will need to do for application developers because they can no longer rely on standard node.js.
I’ve argued that node.js is a better platform for modern web applications because those applications are no longer just websites with REST APIs; instead they have many inputs, outputs, and state mutations that happen outside of the HTTP request/response cycle. It is not the job of express, strata, geddy, or any other node.js web framework to tackle this larger problem, node.js is already doing that. They just need to stay out of the way, to become a component of the application rather than thinking of themselves as the platform. This is a blessing, the task being so much smaller means web frameworks can focus much more on a single task, and many of them are.
The biggest baggage we’ve taken with us from Ruby/Python into the node.js community is a misplaced demand for “middleware.” A web framework might provide simple APIs for extensibility but middleware assumes the web framework is the platform and that the place to build value is on top of the web framework rather than in node.js. This also leads to overly modular web frameworks that provide almost no value except a middleware system and a handful of plugins. Define the problem, solve the problem, don’t box yourself in from the rest of the value being created in the node community.
We’ll get through it, but we’re going to suffer through a lot of misplaced effort before we move past our preconceptions of where the platform is.