In 2005, DHH showed how to build a blog engine with his framework, Ruby on Rails. That demo spurred a movement in web development and changed the industry. Today, I would like to revisit the “Whoops!” video from an opposite approach. While DHH was calling the viewers to “look at all the code I’m not writing”, I would like to explore the possibility of writing it all. Yes, let’s write S-expressions from the presentation layer down to the SQL one, and contemplate the gains of being forced to understand the stack.
This is great. I really like the concept for this series.
Loved this:
Developers often don’t master all the moving parts in web applications and web development. A framework can brige the gap between that lack of expertise in all the moving parts and being able to accomplish something in that field.
I think this captures pretty well the value proposition of a framework. I think sometimes you could say, even if you have mastered all the moving parts as well, it might be they have become a redundant ceremony from project to project, and a framework could help reduce that verbiage.
In a way, it feels similar to the “repairability” of a device. The downside to a framework is in what happens when you need to do something it doesn’t support or if you need to fix an issue you are having with it? It can make doing such repairs or making such changes yourself be too much work or too fragile, because of the complexities the framework brings.
15 years ago? Wow, time flies. I remember this video lighting a fire under the CFML (ColdFusion) community and at least one response video showing how to do the same thing in CFML even more quickly than the Rails version. CFML had loads of frameworks, dating back to its fairly early days with a very simple MVC framework called Fusebox (based on a wiring analogy) and then in the early aughts there was an explosion of OOP MVC frameworks, as well as several ORMs and a few IoC/DI frameworks as well. And, yes, all of those filled a gap caused by lack of expertise because CFML’s main draw was that it was “easy” and that “anyone” could pick it up, even with next to no programming experience (both true).
I contributed to nearly all of them as part of my OSS work and even wrote a few of my own (FW/1 – Framework One – a deliberately “simple”, convention-based MVC framework, and DI/1 which was a deliberately “simple” IoC/DI framework). I even ported FW/1 to Clojure but it wasn’t very idiomatic and as I tried to refactor the design to align more closely with Ring’s architecture I realized just how little value it added on top of Ring.
That was an important realization for me: the simplicity and abstraction level of Ring actually meant that a lot of MVC framework machinery I’d “needed” in CFML (and other languages targeting the web) just wasn’t needed in Clojure. Mapping from /section/item to the app.handlers.section/item handler function and the views/section/item.html template was about the only “benefit” that FW/1 ending up providing in Clojure, over plain Ring/Compojure, and even that was just a couple of simple functions…
It’s a bit like when “Design Patterns” are mapped over to Clojure: almost everything collapses down to simple, consistent abstractions and the use of higher-order functions.
This is why I try to encourage Clojure beginners to avoid any of the “frameworks” in Clojure (including the Luminus project template) and start by writing a “simple” Ring app, then adding routing, then template handling (or Hiccup for HTML) etc…
Very cool video series, I’d like to follow along with these once I’ve finished the book I’m using to get started with Clojure and I like learning in depth like this.
