
Why I no longer use MVC frameworks - jdubray
http://www.ebpml.org/blog15/2015/12/why-i-no-longer-use-mvc-frameworks/
======
Lazare
"Why I no longer use full MVC frameworks to build sites that have no need for
models or controllers." The better question might be why you ever started?

As a bonus, the article discounts React out of hand as one of those "average
MVC frameworks" that does too much, then reinvents an incredibly crude version
of hand-rolled JS components rendering DOM...the one thing React does.

The takeaway from the article, I think, should be:

1\. If you only need some simple React components being fed by a basic Sinatra
or Express server, just do that; it'll be ten times easier to develop and
maintain. (Edit: Although frankly, the example is so simple I think the author
might be better off with a static site generator...)

And:

2\. Do your research before reinventing the wheel badly.

~~~
tracker1
In addition, I find it funny, that TFA's final solution isn't really much
different than static server-side rendering using react, mercury or a number
of similar tools already invented. Not to mention that using babel you get jsx
and es6 template string support... even if not using react/jsx I'd still favor
string templates for my code.

------
quasse
This article has kind of occam's razored me, because I can't actually tell if
the author is serious. Do the inline HTML strings common to this style of
programming remind anyone else of the good old days of writing PHP code with a
bunch of echo statements and concatenated strings to build your pages? It
seems to me that the author has sort of managed to move the V from MVC into
the C, which I thought we had already discovered was a bad idea.

I work in a Flask and Jinja shop, so it's not really fair for me to pass
judgement one way or another without having actually spent a month using this
style. I just can't help preferring the Jinja method of templates that are
mostly HTML with some templating code mixed in, vs. executable code that
happens to be mostly concatenated strings of HTML.

~~~
cdnsteve
Re: good old days of php.

Drupal 8 still does this. Look at the core modules help functions as an
example if you don't beleive it.

~~~
lectrick
See: why I will vehemently avoid all future Drupal projects (1 was enough)

------
csense
Beginning CS students frequently don't see the point of object-oriented
design, because intro-level class projects are by definition small, simple
programs that can be readily comprehended by a single person and written from
start to finish in a few hours. For such simple programs, the modest
organizational gains from OO programming don't seem to justify the extra
boilerplate and conceptual complexity.

The first time I started using Django, I was really confused and everything
seemed incredibly bloated and complicated. Flask seemed much more attractive
-- but as soon as I had a Flask project started to grow a moderate number of
features, Django looked better and better. For simple projects, the modest
gains from using Django's features don't seem to justify the extra boilerplate
and conceptual complexity.

I know someone who insists that assembly language is where beginners should
start.

The common thread: It's hard to start working at a high level of abstraction,
because understanding the lower level of abstraction first is what gives you
the grounding for appreciating exactly what the higher level abstraction does
and why you want it to be done.

I think the author of this article is at a point in his web dev learning where
working at a low level of abstraction is easier. When he gets to larger, more
complicated projects, he'll probably end up writing his own half-baked home-
rolled MVC, or having a project implode under the weight of its own spaghetti
architecture. Then he'll start to see the advantages of using a framework.

Nothing negative is implied by going down this path -- it provides valuable
learning experience and an intuition for what the internals of a good
framework do without even using the framework (since you've experienced first-
hand things that seem like they would be common pain points and how they're
dealt with at the lower level, you'll (often correctly) suspect that standard
higher-level tools might have ways to help people deal with those pain
points.)

~~~
jbergens
But he could have used an existing template language. Seems like he only needs
some templates with sub-templates and there are many solutions for that.
Angular 1 with ui-router is for example great for mapping data into templates.
Ember does it and so does many, many other systems.

~~~
csense
This illustrates my point. You'd be introducing a second language and a large
framework with lots of other unrelated stuff -- which is completely
unnecessary when you have a _language builtin_ which is perfectly adequate to
the task.

Yes, yes, I know, separating data from code, filters, escape sanitization,
there are a lot of good reasons to use templates. If you're a developer just
starting out in web design who is creating a very simple project, string
concatenation will let you get up and running without the extra complexity.

Of course when your project gets big enough, you'll start to try to modularize
things, and _then_ when someone spends 5 minutes explaining templates to the
idea, you can immediately see why you want them, because at that point they'll
actually reduce the complexity of your project.

------
scotty79
Funny thing is that recent React fully supports (even recommends) exactly this
style for his use case. Stateless component can now be just a function.

[https://facebook.github.io/react/blog/2015/10/07/react-v0.14...](https://facebook.github.io/react/blog/2015/10/07/react-v0.14.html#stateless-
functional-components)

He could just change few lines and have JSX, React state management, contexts,
property type and all that other stuff available if he ever needs it.

With his own solution he'd eventually need to re-implement bits of React.

~~~
tracker1
Exactly... My first thought seeing his composite is that it isn't much
different than react, mercury and others... And imo JSX is easier to reason
with.

~~~
scotty79
> Exactly... My first thought seeing his composite is that it isn't much
> different than react

Yes. And in React composition is not done through string concatenation and
values are escaped by default.

I'm not sure about mercury and others but React is first framework I've seen,
and I've seen few, that does the composition (from the point of view of react
user) exactly the way I'd do it. I had my own framework in PHP (before Rails
happened) that did something similar. My components were server side could be
composed freely and bundled not just html and js, but also php, css, images
... and could be extended in a way that allowed derived component to override
inherited css, images, html, whatever. Flow of information was accidentally
unidirectional (thanks to how HTTP works). But the important thing was idea of
freely composable components (instead of pages, resources, views, templates,
layouts or whatever)

------
ane
The MVC _pattern_ is honestly so simple it or something like it usually
emerges from most UI architectures. I would argue that even the increasingly
common backend vs. frontend separation is a form of MVC. Of course, MVC isn't
synonymous with _MVC frameworks_.

When it comes to pure old MVC, I feel that it is a bit like Greenspun's tenth
rule:

> Any sufficiently complicated C or Fortran program contains an ad hoc,
> informally-specified, bug-ridden, slow implementation of half of Common
> Lisp.

So any UI environment will eventually contain an architecture that more or
less embodies the spirit of MVC.

And I think MVC is fine _within a single environment_. That means, the
information travelling from the models to the controllers to the views does
not contain intermediary where mediums are crossed. A traditional Rails
application crosses from databases to a Ruby program to a web browser, and
each bit of logic is dependent of the others.

What makes the backend/frontend separation such a good model is that a front
running on a REST API is not inherently dependent on a protocol or a server
implementation, and the same applies to the backend. This will work in the
post-HTTP world, whenever that comes.

Traditional Rails apps assume they are talking to a web browser. This is
assumption is no longer tenable.

~~~
Retric
Plenty of websites don't need routing. Just like plenty of websites don't need
databases. IMO, a problem with frameworks is you start seeing everything in
those terms even if say static HTML might be your best option.

~~~
albemuth

      sufficiently complicated

~~~
Retric
True Scotsman.

Complexity does not grow in all areas. You could have a 3D MMO which is more
complex than 99.9% of websites without routing for example. Static HTML can
include 100MB of JavaScript that simulates something.

------
nostrademons
A lot of hate for this guy here that is, IMHO, unjustified. What he did isn't
insane. It's not exactly what I would've done, but then, the meta-lesson from
this post is that _you don 't have to do what everyone else is doing_.

The comment here about the point of MVC frameworks being for communication is
true. However, this guy isn't working on a frontend dev team. He is a
consultant doing primarily server-side development, building a landing page
for his business. The code he wrote in this entry probably took him all of
about 15 minutes. Meanwhile, many of the comments here say that he should've
used Jade, or Angular, or Knockout, or Flask, or Jinja. How long would it take
him to get up-to-speed on that? That's time he doesn't get back, which won't
be spent _working on the things that make money for him_.

I wrote a similar build script to try out different landing page concepts - in
about an hour, I'd wired up Babel, PreCSS, and Marky-Markdown so I could write
all my marketing text & tutorials in Markdown, my CSS in CSSNext, and have a
common page layout for everything. It's a lot cheaper than the MVP generators
on the net, it's easier to change and gives me more flexibility than
Bootstrap, and it's a lot less code than writing everything from scratch in
HTML. No, it bears no resemblance to any living framework, and no, it's
probably not intelligible or sane to any other frontend developer. However, it
doesn't have to be. If I get to the point where I'm hiring frontend devs,
they'll be rewriting everything anyway in the framework of _their_ choice, so
my opinion doesn't matter anyways, and in the meantime, the landing page and
product description helped me discover that I didn't need a frontend component
at all, at least for an initial version.

Optimize for the problem you have, not for the problem other people have. And
when other people come up with a solution that's different from what you
would've done, try to see how their _problem_ differs rather than saying
they're stupid.

~~~
Lazare
> A lot of hate for this guy here that is, IMHO, unjustified.

I disagree; I don't think there's a lot of "hate" just some gentle mockery.

> What he did isn't insane. It's not exactly what I would've done, but then,
> the meta-lesson from this post is that you don't have to do what everyone
> else is doing.

The thing is, he _did_ do exactly what everyone else is doing, just a bit
worse than most of the popular solutions.

> And when other people come up with a solution that's different from what you
> would've done, try to see how their problem differs rather than saying
> they're stupid.

But his problem didn't differ. He had the same problem everyone else has, and
ended up re-inventing the same solution everyone else is using.

If you're working on the web, you'll need to turn data into HTML, and his
solution was a JS function to turn data into HTML; it's the single most common
problem and the single most obvious solution pattern. The issue is that there
are already good solutions for his exact problem, and his isn't one of them.

~~~
nostrademons
Say you have two options:

1\. Spend an hour writing 50 lines of code.

2\. Spend 3 hours identifying a framework that includes those 50 lines of
code, reading the docs for it, finding exactly which call or combination of
calls duplicates the functionality that you would've written yourself, writing
code to that API, and then debugging where your mental model doesn't match the
mental model of the framework authors.

Which of those is better?

I suspect most of the commenters here would say #2. My point is that the real
answer is neither: it's "it depends". It depends upon who you're working with
and what their background is; how long you expect the code to live; whether
you expect to use additional functionality in the framework in the future; how
well-documented the framework is; what fraction of the framework will be used
in this solution; etc.

A lot of people, particularly more junior ones, look at an established
framework like React and think "because it's supported by Facebook and
thousands of people use it, _of course_ you should too". I'm saying that it's
not always that simple: sometimes it's appropriate, but sometimes, just
rolling your own is fine too.

(My perception is colored because when I was at Google, I was frequently the
one writing the software that everybody else assumed they should be using, and
I was intimately familiar with all of the downsides and weaknesses of said
software. I recall running into a post on servo-dev where someone proposed
using the Gumbo HTML parser, which I wrote, for Servo's HTML parser.
pcwalton's reply was "Just because Google released it doesn't mean that it's
suitable for our purposes" \- which is exactly correct, Gumbo was never meant
to function as a browser engine.)

~~~
jqm
How many times are you going to be spending an hour to write 50 lines of code?
Is the code going to stay at 50 lines? If the answer is "one or two or three"
and "yes" than ya... do it however.

------
dimgl
This post makes me kind of sad. There's a whole slew of developers who believe
"X is bad so I did Y" and are in turn alienating themselves from design
patterns and frameworks needlessly. I think posts like these breed arrogance
and it should be less about "why not to" and more about "why to".

------
gotchange
He lost me at the moment he showed me the all-encompassing, all-powerful, all-
knowing spaghetti wrapper function in JS.

If he really wanted to build a nice looking web template solely with front end
technologies, he could build it with Jade for the HTML part, Sass for the CSS,
and JS/TS/Babel for the behavior part and structure the template in a modular
and component-based fashion for reusability, maintainability, scalability,
customizability, and above all sanity.

If you're looking to build a web app instead, just pick any framework you feel
comfortable and your future self will thank you for that decision as the web
gets bigger and bigger, you'd still can keep it together and deliver good
results consistently.

~~~
matt4077
You're making it sound all complicated with all those frameworks. This is a
static site. It needs html, css and some js for animations. To avoid
repetition, php/fi ca. 1996 provided this awesome 'include' function.

------
archimedespi
I feel like the author is talking about how bad MVC is without fully
understanding what MVC _is_.

~~~
efaref
MVC is usually done very badly. The View and the Controller are often smooshed
together into an unholy mess.

~~~
archimedespi
But it _can_ be done well. I think the author simply isn't very good at using
the MVC pattern properly, which leads them to dislike it.

------
gherkin0
> 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 which content was dynamically
> constructed from the result of a query to a database. If I remember
> correctly it was a list of cars (Chrysler may have been a client of NeXT).

Kind of an aside, but I think this might be that presentation:

[https://www.youtube.com/watch?v=goNXogpwvAk](https://www.youtube.com/watch?v=goNXogpwvAk)

~~~
jdubray
thank you for digging, I believe that one was a few months later (MSPDC) but
still!

------
ajbetteridge
Ok, then add in some routing for your different pages, and tidy it up a bit,
make it all callable from a URL mapping, and low and behold, you've made your
own MVC framework on top of express.js. Congratulations.

------
icebraining
_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._

Yes. That's called separating the Controller from the View. And pieces of HTML
with dynamic parameters are just templates (like Mustache and such).

I think you just wrote your own (M?)VC framework, with your own templating
language.

------
efaref
I think he just reinvented Perl-CGI in Node.js. I guess the inexorable march
of reimplementing everything in JavaScript continues.

------
smadge
* Why I invented my own MVC framework

------
jbob2000
Wow! A single developer working on small websites doesn't need MVC? What a
revelation! I bet he doesn't have any pesky problems, such as; working in
large teams, long term support, developer turn over, documentation, changing
requirements, deadlines, scaling, etc. etc. Oh, but the rendered HTML looks
nice!

MVC frameworks took off because they allowed more than one person to reason
about an application. I can hire an Angular developer and expect them to have
a fair understanding of my application on day 1. If I'm new to a React shop, I
can read tons of documentation online, without pestering my new coworkers. My
Product Management team likes to change stuff on the fly, so I can use
Knockout to build small, independent components which I can piece together
like lego.

I don't know why this post irked me so much, but it did.

~~~
sergiotapia
Completely understand where you're coming from. Frameworks exist for a reason:
collaboration.

Also, what happens when you inevitably change jobs 3 years later? "I have 3
years experience with Bob's folder structure." Yeah, that's time in the trash
where yes, you learned something, but no, you can't really show value to
potential companies.

~~~
mhd
Quite often the co-worker you're collaborating with is you in 6 months.

------
mplewis
The author doesn't need MVC, he needs a templating engine.

------
jdubray
Thanks guys, I was expecting this kind of answers. The part that bothers me
is: why there is no "standard" wrapper functions (sliders, contact form,...)
that you can "theme" with various snippets of HTML/CSS. I would expect it
would be a lot more practical to deliver a template as a set of wrapper
functions, rather than the raw HTML/CSS as it is always the case.

~~~
pascalo
Am I missing something, or is what the article describes something that
doesn't look that far from from React components, really, minus many of its
benefits like shadow dom, being reactive, JSX being easier than strings?

So you render all this on the server, and then the client does what, or are is
this only targeting static pages?

~~~
marknutter
> React components, really, minus many of its benefits like shadow dom, being
> reactive, JSX being easier than strings

React does not have shadow DOM

------
mschuster91
The problem with all the "fancy" JS stuff is: people these days totally
disable their JS because people have fucked their users over and over again
with endless heaps of tracking, ads and other nasties. Or their connection has
a too high RTT (ohai EDGE!) for downloading 100+ assets in a timely matter.

I have yet to see a JS/* framework that allows me as a full-stack developer to
deliver the same content experience (sans interactiveness of course) to
clients with or without JS, without having to duplicate templating logic or
switch to NodeJS which requires a) a host supporting it, which many
"mainstream hosters" don't and b) having to code a server in javascript's
callback/promise hell.

~~~
matt4077
I don't buy your premise: I'm pretty sure the number of JS-disabling users has
dropped significantly and we're getting to a point where it's acceptable to
require JS. Server-Side rendering is implemented to satisfy search engines
(and even that's changing) or to speed up the first page load.

Your second point is a tautology. Of course it's impossible to run JS code on
the server if you don't want to run JS code and the server and don't want to
rewrite it in another language. FWIW, both ES5/6 as well as coffeescript
vastly improve 'callback hell'

------
syjer
This style is quite prone to escaping/sanitization issues. I would have at
least used a template engine instead of concatenating strings.

------
overgard
I've never understood why MVC is so popular. Any other form of application
development, you just look at what your application needs to do and design for
that. You might use a pattern, you might not, it depends. But for some reason
in web development this is THE ONE TRUE WAY, despite the fact that it's a
pretty awkward pattern for a lot of problems.

The thing that makes it more baffling is that HTTP and HTML are so simple on
their own. Almost all these abstractions being built on top of them are vastly
harder to understand then the things they attempt to abstract away in the
first place.

------
chowes
Interesting article and approach, but I don't think this is really an argument
against using something like Angular or React (which alone isn't even a true
"MVC"). It's more of "for my particular use case, this worked well"... Angular
and React most definitely have their use.

(In fact, you could probably leverage React's server side rendering and JSX to
clean up that long chain of function calls in your page function.)

------
spo81rty
This is why we use knockout instead of angular. Much simpler to do basic
temptation without forcing some mvc framework client side.

~~~
ry_ry
Ironically, I've had the opposite problem with projects built in simple
templated KO.

As projects have scaled up and teams grown the lack of formalised framework,
combined with the amount of logic-y stuff people apparently LOVE to throw into
the templates, has eventually required a rebuild to try to get some structure
in there.

------
bikamonki
Suddenly the author realizes his web app needs to handle a click event which
in turn interacts with data on a database...boom it hits him: this would be
simpler with a framework, maybe an MVC framework?

------
cwisecarver
This is a static site, at least from the examples given. Using MVC to build it
is a way to go but it seems like his way is equally pointless.

Let's take some strings and hardcode them into JS and make the user's browser
render this page dynamically every time it's loaded instead of WRITING SOME
STATIC HTML... It's all well and good to try a new way of doing things but
writing a blog post decrying MVC frameworks for a static site that you're
building dynamically with javascript is silly.

------
rileymat1
Is the css in the screen shot "good".

It seems to really unnecessarily break any sort of distinction between
presentation and content. For example what is the practical reason for using
class "white-text" on a text span instead of an inline style?

------
gitaarik
As always: use the right tool for the job.

React is not an MVC framework also, and it could actually make things much
easier for this particular job.

If you don't need MVC or frameworks then don't use them, you'll be happy they
are available when you need them ;).

------
hcarvalhoalves
TL;DR Web developer rediscovering function composition, data as code, etc.

------
escherize
The actual title was "Why I no longer use MVC Frameworks?" and that was enough
to make me stop.

I can't stand when people end declarative sentences with question marks. Never
again.

------
Walkman
> a collection of interchangeable themes with standard wrapper
> functions/interfaces.

That collection is called a framework...

------
backtoyoujim
Did anyone else use zope? Add an object db to this and it strongly reminds me
of zope.

------
seereadhack
Woof.

