Hacker News new | past | comments | ask | show | jobs | submit login
Why I no longer use MVC frameworks (ebpml.org)
116 points by jdubray on Dec 15, 2015 | hide | past | web | favorite | 92 comments



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


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.


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.


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.


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


  > 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

(I actually didn't read the article yet, but that's what it sounds like you mean here)


That's exactly what I was thinking, too, when reading:

  > 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. 
The comment section was pretty quick to point out the article that the author couldn't find. I mean, some readers are pushing back because they legitimately disagree, but I was more so confused because React already does this. And it's somewhat well documented. Though the author coming to a similar conclusion by himself is praise worthy.


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.


Same here, reminded me of PHP


Java servlets


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


My assembly language for beginners: https://github.com/akkartik/mu. Rationale: http://akkartik.name/post/mu


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.


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.


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

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.


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.


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


thank you, this is really helpful


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.


Yep. If you don't have it you're just going to reinvent routing and a database abstraction layer over and over again


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.


  sufficiently complicated


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.


I've the argument a few times that the HTML/CSS/Javascript should never be thought of as more than the V portion of the MVC. I don't tend to gain any converts but I think its a pretty valid perspective.


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.


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


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


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.


Words of wisdom, especially your first and last paragraph. Besides upvoting your comment, I wanted to tell you that.

It's easy to get involved in the ratrace of using the whole shebang for your projects, how big or small these projects may be. I've used some frameworks in the past, but I eventually found out they added more distraction, took forever to learn and they crippled my flexibility. Good old HTML, CSS, PHP (I'm very afraid of saying this here out loud), Javascript and XML worked for me. And programming without a framework was more fun, like a completely blank canvas that makes it very clear that you are the one who has to do it.


spot on! that's exactly who I am and what I do.


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


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.


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.


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


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


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.


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.


> 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


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


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.


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.


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


* Why I invented my own MVC framework


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.


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.


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


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.


: organization


Frameworks exist for that reason. I don't think that means every framework has to be MVC.


Yep. Sometimes it doesn't always make sense. If your models involve pulling data from multiple different, potentially expensive sources or processes, but your user's request only requires knowing a subset of those results or a subset of the model's properties, you may not want to populate every property of the model.

One reason I like Flask over Django: You can do MVC if you want to, but aren't forced to.


Although there are arguments against MVC I don't see how your example is against MVC.


I guess if you're going to argue against MVC, you have to figure out what MVC means first. The original MVC isn't the same as many of the popular MVCs we have today:

https://github.com/ciscoheat/mithril-hx/wiki/Rediscovering-M... https://heim.ifi.uio.no/~trygver/2007/MVC_Originals.pdf


Let's say I have a model called restaurant. Getting restaurant.name, restaurant.type, restaurant.phone are free. Getting restaurant.menu involves spending $X to get it from an paid API. Getting restaurant.photos involves counting against some social network API's rate limits.

Fully populating a restaurant model and sending it along to a view is costly. A user's requested parameters may not have needed the menu, for example.

That's just scratching the surface of the problem. Okay, let's say I create a model called restaurant that's actually a Python class, where menu and photos are fetched only when called. That's fine and dandy, but now, what if the user's request actually needs to render 10 menus, and it so happens that the API cost of getting N menus doesn't linearly scale? For example, what if I could fetch all those menus in 1 API call and spend only $X? Now all of a sudden our abstracted Python class is terrible at minimizing costs, because it will make a separate call for each restaurant object.

Now add in silly time-based rate limits. Photos API allows upto an average of 10 requests/second in a continuously-moving time window of 5 minutes, while menus API allows 50K requests per day, resetting midnight in Pacific time for American restaurants, and another menus API allows 20K requests per day, resetting midnight in Chinese time for restaurants in China. However, you have nearly unlimited requests for the American menus API if the user has used some login method that gives you a user-specific access token instead your application access token. Oh, and the API that provides Chinese menus doesn't support asking for multiple menus in one call. Also, since you have access limits, you choose to not provide menus for less important anonymous user requests, based on some importance criteria, in order to best serve the users that are most likely to stick. You now have a real mess of a framework.

In general, MVC breaks very easily for practical purposes when you're not in charge of the database, and the people owning the data have business motives and arbitrary access restrictions.

If you own all the data and it's in a nice little MySQL database on your own servers, then sure, slap an ORM on it and go MVC as far as you can, I totally agree.


You're complaining about ORMs, not MVC. If you have a use-case for a limited restaurant model just create another class for that use-case, probably with some code sharing. Specialize and all that. Break the abstraction when needed by a real-world requirement, it's not a problem.


How is it the MVC framework's fault that aggregating data from third parties is expensive?

Lazy evaluation will help to some degree, as will caching data locally once you've retrieved it.

Extending your ORM to invoke third party pay-per-view APIs is obviously the wrong way to solve this problem. That does not mean that MVC or ORM are obviously the wrong way to solve this problem.

MVC will help you with the stuff that it is suited to, as will ORM. Neither are suited to optimising usage of expensive pay-per-view APIs. You need to build the API interaction part separately, and arrange for the MVC side of things to work with thst API-using-API.

Off the cuff, why not have a batching task that takes requests from the last fraction of a second and sends them off to each provider? How long can you stretch that fraction of a second without upsetting you customers? Are they willing to wait three seconds? If you get a dozen requests per minute, three seconds might halve your API bills.

As you said, MVC breaks when you do not control the data. So your job is to get the data into a form and place that you control.


That's a lovely explanation of why mediocre ORMs can cause more problems than they solve. And it's well known that Django's ORM is very mediocre, and sadly it's so tightly coupled to the framerwork that you can't just drop in a better one.

...but what does this have to do with MVC? You're entire argument comes down to "sometimes you need to have some smart models to deal with external APIs". Well...yeah?


Are we including Django in MVC now? The term has become completely vague then.

Django's web framework is URL routing plus views, which may use the template engine if they want to. There is also an ORM which is separate from the Web framework and other tools.


Well, from wikipedia:

> Django (/ˈdʒæŋɡoʊ/ jang-goh)[4] is a free and open source web application framework, written in Python, which follows the model–view–controller (MVC) architectural pattern.[5][6]

And realistically it has models, views, and controllers; it's at least as "MVC" as most frameworks we label that, and more than many. If Django isn't MVC, what is?


Smalltalk was. Django's FAQ says that if you want it to fit an acronym, maybe use "MTV" (model, template, view).


I found this to be more insightful: https://news.ycombinator.com/item?id=10730047

Being that, the original conception of MVC was for the user's mental model, not the programmer's mental model.


MVC frameworks took off because of cargo culting. Almost nobody who says "MVC" actually knows where MVC came from or why it was conceived.

There are many reasonable ways to split up responsibilities. I know this because many different usable frameworks split up responsibilities differently (although many of them all call themselves "MVC" regardless of the differences).


I actually love that he started the post talking about WebObjects. Probably the only relatively mainstream MVC framework that was designed by people who actually understood what MVC is supposed to do/be, and why.


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


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.


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?


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

React does not have shadow DOM


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.


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


You're literally describing React + Bootstrap.


Funny you started out mentioning WebObjects. It's free and does everything you dreamed of. It came a long way from the ugly table based layout SJ showed off in 1995. It is the ultimate full stack MVC framework. There is still nothing comparable today.

The Model can be generated from db schema or vice versa. You don't need to know SQL. The Model informs the ORM (Object Relational Mapper) how to create/read/update/delete (CRUD) your objects to/from the database. The model also validates your data for you. The field is 255 wide? Then 256 chars throws validation exceptions automatically, and so on.

The view is generated by reusable components on the server. Small reusable components ultimately assemble into a full page. Hundreds of components that do everything imaginable exist already.

With no code at all, they Controller wires them together using the Direct to Web (D2W) rule system. In fact, if all you want is an admin interface to do CRUD type operations on your database, you won't need anything beyond the hello world D2W application. These rules allow you to make sweeping changes throughout your entire application. Want to change every component that handles text input in a form page? Create one rule:

100: task = 'edit' and attribute.className = 'java.lang.String' => componentName = "MyNewEditStringComponent" [Assignment]

Or override with other components as appropriate

105: task = 'edit' and attribute.className = 'java.lang.String' and session.user.isAdmin => componentName = 'AdminEditString' [Assignment]

WebObjects allows you to maintain a level of state that no other web based MVC can match. You can nest your tables of data as deep as you like, paginating and sorting any of them at every level. No other web framework can do this. Period.

You only need to learn WebObjects to be full stack.


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


> why there is no "standard" wrapper functions (sliders, contact form,...) that you can "theme" with various snippets of HTML/CSS

For one thing, HTML was originally designed for read-only publishing. User interaction was gradually added over time.

For another, if you expand the scope of HTML to entire widgets, it'll become an incredibly bloated language. At a certain point, it needs to be building blocks rather than a pre-built solution.

Why don't Legos come with cars and boats already built in the box? Because some people don't want a car or a boat, they want a plane.

You might get some pieces that lend themselves to a particular purpose (select box, blockquote, etc.), but the language is not highly opinionated about what you do with them.


Rendering HTML on the server is very old school. Before we had much JavaScript, we rendered HTML on the server and used links and HTML forms for interaction. There are a zillion frameworks in a zillion server-side languages to do this, but mostly not in JavaScript.


> Rendering HTML on the server is very old school

That's not true as generally as you've phrased it. Rendering HTML on the server is very useful for certain kinds of sites, like blogs. It allows you to generate pages that can be cached and behave like static pages (with appropriate, static-like headers).


I agree. Old school doesn't mean it's not useful.


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.


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'


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.


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


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.


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


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


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.


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?


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.


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?


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


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


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.


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

That collection is called a framework...


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


Woof.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: