15 ms·

Why I no longer use MVC frameworks

116 points by jdubray 11y ago

Lazare 11y ago
"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 11y ago
  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.
icebraining 11y ago
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.
ajbetteridge 11y ago
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.
chowes 11y ago
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.)
deleted 11y ago
[deleted]
Pro777 11y ago
And the data magically appears from a sinatra app without any MVC.
quasse 11y ago
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.
- swehner 11y ago
  Same here, reminded me of PHP
- cdnsteve 11y ago
  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 11y ago
    See: why I will vehemently avoid all future Drupal projects (1 was enough)
- jspiral 11y ago
  Java servlets
- roninb 11y ago
  Could I possibly ask where you work? I've been trying to find more places that work with Flask or Jinja to improve my own knowledge about the specific niche I eventually want to fill in a year or two and haven't really been able to find much out there.
- steveklabnik 11y ago
  > This article has kind of occam's razored me, because I can't > actually tell if the author is serious. Let me introduce you to my good friend: https://en.wikipedia.org/wiki/Poe%27s_law https://en.wikipedia.org/wiki/Poe%27s_law (I actually didn't read the article yet, but that's what it sounds like you mean here)
smadge 11y ago
* Why I invented my own MVC framework
deleted 11y ago
[deleted]
ane 11y ago
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.
- bpicolo 11y ago
  Yep. If you don't have it you're just going to reinvent routing and a database abstraction layer over and over again
- Retric 11y ago
  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 11y ago
    sufficiently complicated
    - Retric 11y ago
      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.
jbob2000 11y ago
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 11y ago
  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.
  - bpicolo 11y ago
    : organization
  - mhd 11y ago
    Quite often the co-worker you're collaborating with is you in 6 months.
  - gnrme 11y ago
    Yeah. The skills aspect is important. That bespoke CMS/MVC product that you spent years working with... it's kind of worthless. Employers and recruiters have a list of requirements to tick before narrowing down the candidates. Once you get to the interview and they want to look at the code from a project, then sure, it will help a lot - assuming you created it.
- nulltype 11y ago
gherkin0 11y ago
> 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 11y ago
  thank you for digging, I believe that one was a few months later (MSPDC) but still!
jdubray 11y ago
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.
- whatever_dude 11y ago
  That is normally called a Controller or a ViewController or something of the sort depending on the developer's preference. There is no interchangeable "standard" for that for the same reason there is no "standard" for almost anything in technology: different requirements, platforms, styles, projects, etc
- mjpuser 11y ago
  Re: why there is no "standard" functions that you can [use] to theme various snippets of HTML/CSS. -> There shouldn't really be a "theme" in HTML. Yes, you have classes and stuff, but the html should be _markup_ in that describes data, not worrying about presentation. Different themes should be achieved via CSS, which is the standard theming abilities you're looking for. Honestly, I can understand the confusion, since it's difficult to parse through all the technologies and understand what is going on at the heart of the matter.
  - tahssa 11y ago
    > html should be _markup_ in that describes data, not worrying about presentation. And I wish that was truly the case. Sadly half of all HTML written is to support presentation.
- deleted 11y ago
  [deleted]
- mplewis 11y ago
  You're literally describing React + Bootstrap.
- 11y ago
dimgl 11y ago
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".
scotty79 11y ago
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.html#stateless-functional-components https://facebook.github.io/react/blog/2015/10/07/react-v0.14... 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.
- jdubray 11y ago
  thank you, this is really helpful
- tracker1 11y ago
  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 11y ago
    > 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)
archimedespi 11y ago
I feel like the author is talking about how bad MVC is without fully understanding what MVC is.
- efaref 11y ago
  MVC is usually done very badly. The View and the Controller are often smooshed together into an unholy mess.
  - archimedespi 11y ago
    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.
- Scarblac 11y ago
  Nobody does anymore. The original pattern had an individual model, view and controller for each UI element in the window, now all frameworks I've seen that mention MVC are completely different.
efaref 11y ago
I think he just reinvented Perl-CGI in Node.js. I guess the inexorable march of reimplementing everything in JavaScript continues.
mplewis 11y ago
The author doesn't need MVC, he needs a templating engine.
backtoyoujim 11y ago
Did anyone else use zope? Add an object db to this and it strongly reminds me of zope.
gotchange 11y ago
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 11y ago
  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.
seereadhack 11y ago
Woof.
nostrademons 11y ago
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.
- jdubray 11y ago
  spot on! that's exactly who I am and what I do.
- Lazare 11y ago
  > 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.
syjer 11y ago
This style is quite prone to escaping/sanitization issues. I would have at least used a template engine instead of concatenating strings.
Walkman 11y ago
> a collection of interchangeable themes with standard wrapper functions/interfaces. That collection is called a framework...
spo81rty 11y ago
This is why we use knockout instead of angular. Much simpler to do basic temptation without forcing some mvc framework client side.
- ry_ry 11y ago
  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.
mschuster91 11y ago
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 11y ago
  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'
- warfangle 11y ago
  Which mainstream hosters don't? The same ones that only support and will only ever support PHP? > b) having to code a server in javascript's callback/promise hell. Don't really see promises as hell, but with latest versions of Node and this neat little library called co, you can write your async code like this: function doAsyncOne() {} // returns promise function doAsyncTwo() {} // returns promise co(function*() { try { let [resultOne, resultTwo] = yield [doAsyncOne(), doAsyncTwo()]; } catch(e) { // one of the promises rejected, handle it } }); Generators as coroutines are the poor man's async/await.
hcarvalhoalves 11y ago
TL;DR Web developer rediscovering function composition, data as code, etc.
csense 11y ago
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.)
- akkartik 11y ago
  My assembly language for beginners: https://github.com/akkartik/mu https://github.com/akkartik/mu. Rationale: http://akkartik.name/post/mu http://akkartik.name/post/mu
- jbergens 11y ago
  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.
gitaarik 11y ago
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 ;).
cwisecarver 11y ago
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.
overgard 11y ago
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.
bikamonki 11y ago
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?
rileymat1 11y ago
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?
escherize 11y ago
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.

116 points by jdubray 11y ago

"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 11y ago
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.

icebraining 11y ago

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.

ajbetteridge 11y ago

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.

chowes 11y ago

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.)

deleted 11y ago

[deleted]

Pro777 11y ago

And the data magically appears from a sinatra app without any MVC.

quasse 11y ago

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.

swehner 11y ago
Same here, reminded me of PHP
cdnsteve 11y ago
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 11y ago
  See: why I will vehemently avoid all future Drupal projects (1 was enough)
jspiral 11y ago
Java servlets
roninb 11y ago
Could I possibly ask where you work? I've been trying to find more places that work with Flask or Jinja to improve my own knowledge about the specific niche I eventually want to fill in a year or two and haven't really been able to find much out there.
steveklabnik 11y ago
> This article has kind of occam's razored me, because I can't > actually tell if the author is serious. Let me introduce you to my good friend: https://en.wikipedia.org/wiki/Poe%27s_law https://en.wikipedia.org/wiki/Poe%27s_law (I actually didn't read the article yet, but that's what it sounds like you mean here)

smadge 11y ago

* Why I invented my own MVC framework

deleted 11y ago

[deleted]

ane 11y ago

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.

bpicolo 11y ago
Yep. If you don't have it you're just going to reinvent routing and a database abstraction layer over and over again
Retric 11y ago
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 11y ago
  sufficiently complicated
  - Retric 11y ago
    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.

jbob2000 11y ago

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 11y ago
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.
- bpicolo 11y ago
  : organization
- mhd 11y ago
  Quite often the co-worker you're collaborating with is you in 6 months.
- gnrme 11y ago
  Yeah. The skills aspect is important. That bespoke CMS/MVC product that you spent years working with... it's kind of worthless. Employers and recruiters have a list of requirements to tick before narrowing down the candidates. Once you get to the interview and they want to look at the code from a project, then sure, it will help a lot - assuming you created it.
nulltype 11y ago

gherkin0 11y ago

> 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 11y ago
thank you for digging, I believe that one was a few months later (MSPDC) but still!

jdubray 11y ago

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.

whatever_dude 11y ago
That is normally called a Controller or a ViewController or something of the sort depending on the developer's preference. There is no interchangeable "standard" for that for the same reason there is no "standard" for almost anything in technology: different requirements, platforms, styles, projects, etc
mjpuser 11y ago
Re: why there is no "standard" functions that you can [use] to theme various snippets of HTML/CSS. -> There shouldn't really be a "theme" in HTML. Yes, you have classes and stuff, but the html should be _markup_ in that describes data, not worrying about presentation. Different themes should be achieved via CSS, which is the standard theming abilities you're looking for. Honestly, I can understand the confusion, since it's difficult to parse through all the technologies and understand what is going on at the heart of the matter.
- tahssa 11y ago
  > html should be _markup_ in that describes data, not worrying about presentation. And I wish that was truly the case. Sadly half of all HTML written is to support presentation.
deleted 11y ago
[deleted]
mplewis 11y ago
You're literally describing React + Bootstrap.
11y ago

dimgl 11y ago

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".

scotty79 11y ago

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.html#stateless-functional-components https://facebook.github.io/react/blog/2015/10/07/react-v0.14... 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.

jdubray 11y ago
thank you, this is really helpful
tracker1 11y ago
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 11y ago
  > 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)

archimedespi 11y ago

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

efaref 11y ago
MVC is usually done very badly. The View and the Controller are often smooshed together into an unholy mess.
- archimedespi 11y ago
  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.
Scarblac 11y ago
Nobody does anymore. The original pattern had an individual model, view and controller for each UI element in the window, now all frameworks I've seen that mention MVC are completely different.

efaref 11y ago

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

mplewis 11y ago

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

backtoyoujim 11y ago

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

gotchange 11y ago

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 11y ago
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.

seereadhack 11y ago

Woof.

nostrademons 11y ago

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.

jdubray 11y ago
spot on! that's exactly who I am and what I do.
Lazare 11y ago
> 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.

syjer 11y ago

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

Walkman 11y ago

> a collection of interchangeable themes with standard wrapper functions/interfaces. That collection is called a framework...

spo81rty 11y ago

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

ry_ry 11y ago
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.

mschuster91 11y ago

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 11y ago
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'
warfangle 11y ago
Which mainstream hosters don't? The same ones that only support and will only ever support PHP? > b) having to code a server in javascript's callback/promise hell. Don't really see promises as hell, but with latest versions of Node and this neat little library called co, you can write your async code like this: function doAsyncOne() {} // returns promise function doAsyncTwo() {} // returns promise co(function*() { try { let [resultOne, resultTwo] = yield [doAsyncOne(), doAsyncTwo()]; } catch(e) { // one of the promises rejected, handle it } }); Generators as coroutines are the poor man's async/await.

hcarvalhoalves 11y ago

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

csense 11y ago

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.)

akkartik 11y ago
My assembly language for beginners: https://github.com/akkartik/mu https://github.com/akkartik/mu. Rationale: http://akkartik.name/post/mu http://akkartik.name/post/mu
jbergens 11y ago
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.

gitaarik 11y ago

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 ;).

cwisecarver 11y ago

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.

overgard 11y ago

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.

bikamonki 11y ago

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?

rileymat1 11y ago

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?

escherize 11y ago

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.