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 use blvd start. This is the primary purpose of the script - it sorts the arguments provided into a proper arguments object. blvd develop just wraps index.dev.js or whatever script you set in the package.json for develop.

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.