The Philosophy of Boulevard
This document isn't a vendetta against rails, more an outline of my thought process when building a program designed to replace it. If I'm out to build Yet Another (MVC/MVVM/etc) Framework, I've got to justify it. Hopefully, this document makes my thought process clear and also gives you a good case to prefer it over the alternatives.
Killing Merlin and Banning Magic
One of the primary features of Ruby on Rails I dislike is a degree of abstraction which makes the meaning and purpose of code unclear. Boulevard aims to make code less "magical" in this way.
This difference in philosophies is seen in the presence of an index.js
file in the root of any Boulevard project. If we look closer at this file, which is generated by scaffolding but can change at any time, we see our applition clearly defined:
// The Client class wraps around the path provided to allow you to define
// Compilers, like webpack or an uglifier or such.
import { Client } from 'blvd-client'
// The Server, on the other hand, inherits from the Server object defined
// in blvd-server and you define it, defining the contexts and models
// and such used in the application.
import Server from './server'
// We export a function, which is passed arguments and run when you
// start the application using blvd start.
export default (args) => {
// We create a new client, giving the path of the client.
const c = new Client('./client')
// We pass the client to the server, so that the server can serve the
// client in response to HTTP requests.
const s = new Server(client)
// Then, we tell the server to listen on a port, like servers
// generally do.
s.listen({ args.port })
}
The
args
object represents the arguments passed on the command line when you useblvd start
. This is the primary purpose of the script - it sorts the arguments provided into a proper arguments object.blvd develop
just wrapsindex.dev.js
or whatever script you set in thepackage.json
fordevelop
.
In rails, this is arguably much easier:
$ rails server
So... why prefer this approach? Simple:
It's instantly understandable. A lot of what rails does is unclear. Digging into the source of the CLI is not fun just to understand a small bug in your code. rails server
does a variety of complex tasks across packages, and blvd develop
or blvd start
just run a single NodeJS function. That you defined! (Or some boilerplate defined, but, well, it's really easy to understand.)
Magic is difficult to learn and understand, and "shortcuts" often build up technical debt in unexpected ways.