APIs, MDE, React.js

Why I no longer use MVC Frameworks?

Creating beautiful dynamic Web apps has been the Holy Grail of our industry for as long I can remember. I first saw  a “web app” when Steve Jobs introduced WebObjects at the Moscone Center in 1995, which he claimed was the first dynamic HTML app server to go to market (followed by a few others like Kiva, WebLogic…). It was quite something to see for the first time a Web page dynamically constructed from a database query . If I remember correctly it was a list of cars (Chrysler may have been a client of NeXT). The HTML was crude, the performance was ok, but as always, Steve was at the bleeding edge of our industry.

I don’t know about you, but that twenty year journey has been frustrating, from JSP/Struts to ASP.Net, or your average MVC framework like Angular or even React.js which is in itself an incredible piece of engineering. The bottom line is that nothing I have tried in these twenty years would allow me to claim the “Full Stack Developer” status, not even close.

When I see Web templates like that one, I gasp and think, some day I’ll have enough time to write an Angular or React app that looks exactly like that. Over the last few years, it even felt that jQuery, HTML5 and CSS3 made it even more inaccessible for server-side developers like me to create a decent Web app.

For instance, if you look at the markup of the Brando template, you’ll see that there is some bad ass CSS/JS work behind it:


Writing some decent HTML5 and CSS is hard enough, now try to programmatically generate that kind of code. That… is hopeless.

It’s hopeless until you turn the problem around and you start with the template (fat fingers guys like me can even create decent looking HTML templates with ImCreator).

The key is to create a thin javascript wrapper to your favorite template, and code your Webapp pages as calls to these plain and simple wrapper functions. You’ll see that the HTML/CSS concerns vanish completely from your code, as they are completely contained in the wrapper functions:



This is what a wrapper function looks like:


These functions are trivial to write, just a simple parameterization of the HTML template with some default values to make calling them elegant. That simple task should integrate readily with any designer-developer workflow. I bet most Web designers could actually deliver those “theme wrappers” without a sweat.

Last step, you serve the pages of your application directly from node, for instance, using express.js. Ideally, you would describe the content of your pages in json structures, as metadata:


Creating a page is merely a set of simple function calls:


Which you can finally wire onto an Express route:


… and voila, this is what the result of my code look like. A good looking app/site with ** No (MVC) framework **. Combine that with the power of node.js to fetch and mash up any data you’d like, and you are *just* a few lines of javascript away from becoming a full stack developer.

A natural extension of that pattern would be to create standard Web apps/Website components (wrapper function) such that you could replace the underlying “theme” as needed, as the interface would remain the same. For instance, after changing the template’s metadata (the home json), the site just looks like what I needed. You feel like changing the template? as long as the theme’s functions are roughly the same, your site will continue to look pretty good. Compare that to a wordpress template change …

This pattern feels like a great way to modernize any kind of web app or web site.

I know, it sounds like one of these “duh! moments”, but I can’t think of an instance where I saw this pattern explained in some article, that kind of functional pattern is not common at all. I would also expect if it was widely used, there would already be a collection of interchangeable themes with standard wrapper functions/interfaces.


  1. Isn’t that essentially just ordinary templating? A handlebars template pretty much has the same function of one of these little functions with a standard form. I think that’s the same thing, right?

    I agree with you sentiments though. Many frameworks are overkill. Not always the best starting point.

  2. Great write-up, always nice to hear other designers/developers’ thought processes.

    Taking a “markup-first” approach makes things much clearer to me personally, especially when I am building out CMS themes and templates (a big reason I don’t love wordpress or drupal, but prefer CMS’s like Concrete5, ProcessWire, Craft and Perch — because they don’t dictate how your markup needs to be formatted or split up into components).

    And I agree with @Jovanni that it seems like what you’re doing is rendering a template. I think the method you outline here is even more complicated than it needs to be (it’s very hard to make edits to markup if it’s split up amongst javascript strings). Handlebars is one approach… I’m personally a big fan of underscore.js templates ( https://underscorejs.org/#template )… they are just stupid simple and don’t even require compilation on the server.

  3. Well, that’s the question I am trying to answer. I get the point of everyone, saying that I just invented my own MVC framework. The difference I see here though is that the wrapper functions creates an interface that:
    1/ hides the markup entirely from the developer, to construct a page I just call functions
    2/ enables interchangeable themes

    I have any number of themes written by different designers that all conform to the same interface. I understand that’s pretty trivial stuff, and again, I am not a front-end developer, so I may have misused all these frameworks over the years, but I have not generally seen 1/ or 2/ in many of the code samples I have looked at. I did quite a bit of work with React earlier this year, and again, I didn’t land in place where the code was as isolated from the markup.

    Am I missing something?

  4. So you put output (html template) code into controller code. Sure, you can do that if your application demands are simple enough (you can even do that in Rails or any MVC framework, simple example is outputting JSON directly on a controller endpoint directly from an ORM model object), but there’s a reason people break out templates into views. One, your view templates shouldn’t be including any calculation, so that you can test those calculations in an automated test suite that talks directly to the controller and model without having to render the view first (You don’t have much calculation here. I’m guessing you don’t have a test suite? You’ll break something if you ever refactor this code, I guarantee you…). Two, if you’re ever on a team, you will typically have frontend people and backend people, and the file separation becomes useful then.

    > now try to programmatically generate that kind of code. That… is hopeless.

    The problem there is that that’s not actually a good use of CSS. Someone just created classes that map directly to attributes, instead of actually creating an intelligently-named hierarchical set of CSS classes. That’s why you have those long class attribute values.

    1. Peter,

      the main point of the post is not so much to come up with a revolutionary Web app architecture, but rather to help occasional front end developers to do a much better job at what it is they need to get done. So I can appreciate that I have not properly applied the MVC machinery , but so far the amount of ceremony required gets in the way of getting simple things done.

      Now, the second point, perhaps equally important is the question of the integrating the designer-developer workflow and so far most MVC frameworks I have seen, including React, seem to simply ignore that workflow altogether. Once you built your Webapp (again, I am not a specialist), but I have not seen simple ways to change the “theme”.

      I actually would like to make that question front and center of my post: what is the best way to align the designer-developer workflow and hence, what is the best way to package a Web app template?

  5. @jj There are a few things that JS MVC frameworks give you that your string-concatenation-based system would not: the most essential is a property known as “retained mode”, i.e. you can write dynamically changeable templates declaratively, instead of having to manually write special case DOM manipulation code for every case of interactivity on the client-side.

    The property of having a function-based developer interface and interchangeable themes are, in fact, also achievable with existing frameworks. Here’s an article for the Mithril.js framework that explores that idea: https://lhorie.github.io/mithril-blog/better-templates-with-fp.html

    Another problem of string concatenation is that it’s naturally weak at maintaining structural integrity of the DOM tree. This means it’s vastly easier to run into issues with missing close tags, or even security attacks (see also: every sql injection attack ever).

    Using a virtual dom based framework allows you to use functional composition instead, which not only strengthens the structural integrity of templates, but also allow you to do advanced template refactoring (here’s an example: https://lhorie.github.io/mithril-blog/when-css-lets-you-down.html )

    1. Leo,

      thank you for the point, yes, I would say that I landed in a place near Mithril. I am not claiming that this is rocket science, but certainly a pattern worth to be part of any casual front-end developer.

      I appreciate the comment on virtual DOMs, and I certainly fell in love with React earlier this year but I view the designer-developer workflow as something that needs to be addressed in a more deliberate way. So far, I have not seen a good factoring that would make that transition seamless.

      1. The point on designer-developer workflow is a bit open-ended since workflows vary from team to team. I’ve seen teams where designers are web-stack-savvy and perfectly comfortable hacking on Angular/React/whatever templates, and I’ve seen teams where designers know no CSS and throw Photoshop files over the fence to a dev team (I’d say the latter is more common, from my experience)

        In both cases though, I haven’t really seen a major impediment, since w/ a web-stack-savvy design team, designers are comfortable enough to work with the actual codebase, and with a Photoshop-centric team, the work of translating a mockup to HTML falls on developers who do know how to deal w/ javascript syntax, be them string concatenation or nested function calls. I do see many superficial comments about how one syntax variation looks more pleasing than another, but if we’re talking about keeping it simple and getting stuff done, I think that’s a bikeshedding #FirstWorldProblem at best.

        The main pain point I’ve seen is to actually get an app up and running for a new team member (you know, installing nodejs, npm, a database and whatever else happens to be needed by the app), and testing UI edge case states (e.g. that little message that shows up for 3 seconds after you deleted a user project, which takes going through 2 forms to create).

        In that sense, I think React and Mithril do provide a vastly improved workflow than less-component-centric frameworks like Angular, since they allow you to easily mock data to render widgets in isolation and in specific states. The amount of work for a developer to expose code to a designer using those virtual dom frameworks is probably comparable to the amount of work to do the same using your system, though.

        I think the interesting take-away is that you, coming from a somewhat different angle than most frontend devs, and trying to make a simple (in the good way) system for yourself, have come up with something that very closely resembles the current state of art in javascript frameworks.

Leave a Reply

Your email address will not be published. Required fields are marked *

5 + 5 =