MVC frameworks aren't dinosaurs but sharks

&gt; Last years, using MVC framework was not an option as soon as you wanted a dynamic front-end. Having to reload a full page for every user action leads to a bad user experience and is indeed, not acceptable in 2022.<p>When it&#x27;s needed, fine.<p>But there are so many SPAs that just don&#x27;t need to be. Rendering HTML server-side is just <i>nice</i>. It&#x27;s simple and easy to work with. Weird states are unusual. The user gets a really normalized, predictable experience. And done well&#x2F;quickly, there&#x27;s little actual difference.<p>Maybe I&#x27;m just showing my age. This falls really close to my &quot;I miss the old web&quot; type sentiments. The last thing I built, and the next thing I will build, are purposely doing full page renders for any actions (no jQuery or React&#x2F;SPA stuff). I don&#x27;t think I&#x27;m going to have any javascript at all. It&#x27;s really fun and lean. I don&#x27;t know, it&#x27;s just got me going lately--reminds me of when I was starting out.<p>My last project is 300 lines of python, 270 lines of php, html&#x2F;css of course, postgresql, and cron. Some scrapers run, ingest data, and the php sorts and displays it.

The big MVC frameworks are in a great position to take advantage of the move back to hypermedia as a major network model for web development. We are seeing a swing back to this model with modern hypermedia-oriented libraries like unpoly, hotwire and my own htmx, where javascript is used to augment the hypermedia model rather than replace it with a client-server RPC-style network model as with most SPAs.<p>These older frameworks have been honed to a razors edge for producing hypermedia (HTML) server side and delivering it to clients efficiently. As people begin to realize just how much you can achieve with this approach (and the simplicity it brings back to web development) I expect interest in these frameworks to soar.<p>Bullish on 2005 tech books!

<i>&gt;But as a general rule, I think we must not discard a technology just because it&#x27;s old. Doing so because it&#x27;s too new would make more sense, if you want to build stuff for businesses.</i><p>Agree with the first statement but, not necessarily on the second.<p>People dismissed React for being &quot;too new&quot; or &quot;the latest stupid shiny new framework&quot; for a long time because they didn&#x27;t understand it. But when I read about it for the first time, I understood the problem it was solving with the VDOM. It made perfect sense for me to start using it immediately because it quickly starts saving a lot of time formerly spent on writing DOM setting&#x2F;resetting code and making sure it never breaks. It was something I was already thinking about: &quot;how could I avoid writing all this tedious DOM manipulation code&quot;. And there it was, and I knew it would become big. It took a while for the rest of the world realize it, but eventually it caught on.<p>Sometimes tools pop up that make perfect sense. So you shouldn&#x27;t dismiss any technology for its age, whether it&#x27;s old or new.

Its funny how most languages have this whole separating between microservices and monoliths. Having worked with elixir for the last 5 years, One of its biggest benefits is the ability to have a microservice deployment while having a monolithic codebase.<p>It comes with a reasonably good internal pubsub system and vm linking right out of the box. And the built in application supervisor makes it trivial to spawn thousands of threads on one machine, each with their own independently allocated heap, that can be mounted under a supervision tree.<p>Want to create a microservice? just make a file, inherit the GenServer and add it to your application tree in your application.ex. Add a library like horde and you can create singletons in your codebase that are microservices. they run as a thread somewhere in your cluster. Just send it a message by nmae and the vm will know where to deliver it.<p>The end result is the overhead of creating and maintaining a microservice in elixir is about the same as the overhead for adding a new controller.

I write UI apps, using Apple&#x27;s UIKit. I can generally write a fully functional app, in a day (or less). I do it all the time, for test harnesses. I spend more time on apps that I&#x27;ll actually be shipping (mostly doing stuff like aligning UI elements and applying accessibility and localization, which can take quite some time. <i>Lots</i> of iteration).<p>I&#x27;m putting the finishing touches on my second app in about a month and a half. It&#x27;s a &quot;total rewrite&quot; app; just like the previous one (which is already out there, and has had over a thousand downloads already).<p>I did these apps alone. After this one is out the door, I&#x27;ll return to the app I&#x27;ve been working on for a year and a half. These were just &quot;side trips,&quot; because I was getting burned out.<p>UIKit was designed as an MVC framework. If you use a different pattern, then &quot;you&#x27;re holding it wrong.&quot; You are using the framework in a manner for which it was not designed.<p>That is not always bad. I can&#x27;t actually think of any examples, right now, but I&#x27;m sure that some of the new methodologies are more effective.<p>I strongly suspect that some of the new development patterns (I won&#x27;t name them, because holy wars) were developed specifically to break up projects that are really best done by one or two skilled engineers, into ones done by a fairly large team of relatively unskilled engineers.<p>Might work out. I don&#x27;t know. That&#x27;s not how I work. YMMV.

I know it’s probably obvious to some but in an MVC framework: the API can be the view.<p>That’s the whole point of separating the code into layers: so you can have multiple implementations existing concurrently at the same layer.<p>For example you can have models talking to Postgres and models taking to Elasticsearch or Cassandra. Or as everyone knows you can have different controllers which all talk to the same models or use the same view for output.<p>And if you were to abstract beyond the framework level, MVC can apply to software written in totally different languages.<p>I consider my code to be high level MVC and it’s controllers in Elixir talking to Java model layers and outputting JSON views, HTML, or even Excel files.

&gt; 2 - Monoliths still make sense in many contexts<p>Yes and I&#x27;d argue it makes sense in most contexts for small startups.<p>Also, Monolith is sometimes synonymous with tangled spaghetti code but it doesn&#x27;t have to be. If code is kept organized, it can be split into microservices when&#x2F;if the need arises.

I feel like MVC frameworks, like most application frameworks, are caught in a constant push-pull cycle.<p>Devs write without a framework, but complain that they have to spend a lot of time working on the structure of their application. There&#x27;s a desire to use a third party framework that handles the broader structure, and the devs just have to slot in their application specific code into pre-defined places.<p>Devs then work with a third party famework for a while, but get frustrated when their application needs don&#x27;t match up with what their framework is good at. They then have to write hacky workarounds to add the functionality they need. There&#x27;s a desire to ditch the prescriptive framework, and design the code structure in a way that meets up with the application&#x27;s specific needs. And then the cycle repeats itself.<p>Application frameworks, whether MVC or something else, are a useful tool. But there&#x27;s no perfect framework, and it&#x27;s easy to feel like the grass is greener on the other side.

&gt;But as a general rule, I think we must not discard a technology just because it&#x27;s old.<p>I forget who had the quote that went something like:<p>&quot;If SQL is so great why have people been trying to replace it for decades?&quot;<p>(the failure to replace it is of course the punchline, in case anyone misses that)

An excellent article. As huge Django fan, I could not agree more (so yes, biased :-) )<p>Since 2015, I&#x27;ve always rendered <i>final</i> HTML server-side, whether that HTML was travelling over a complete http request&#x2F;response cycle (big page load or XHR or fetch), or over websockets.<p>The only JSON ever involved was stuff similar {&quot;markup&quot;:&quot;you html code here&quot;} and a few other more subtle bits to make up for a dumb&#x2F;blind client. In other words, the client does as it&#x27;s told by the server. (my client is Azatoth)<p>Opinionated? Yes.<p>Full-of-bad-suprises-after-release-oh-shit-what-did-I-do? No<p>Then again some light stuff works (flask vs django). But as (more than) hinted in the article, a hello world may satisfy this immediate need to get that shiny first HTTP 200 from your new website&#x2F;api&#x2F;whatever. But doesn&#x27;t do much insuring a certain level of quality, sanity and stability in the long(er) run.<p>my 2pence.

&quot;MVC&quot; is such an overloaded term. The article is quite clear it&#x27;s about Django, Rails and Laravel¹, yet there are already people here complaining about different meanings of that name.<p>Hell, Microsoft has a framework literally called &quot;MVC&quot; that has only a passing similarity to them, but is completely different on practice.<p>&quot;Framework&quot; is also too overloaded to my tastes, less so than &quot;MVC&quot;, but you will still get confused people if you use it without context.<p>Using those terms make ideas less clear, not more. I do really avoid using them, and I would recommend doing the same for anybody.<p>(Anyway, it&#x27;s nice to know that getting the region&#x27;s HTML and applying it to the innerHTML of an element, like I was doing with JQuery decades ago is called &quot;HTML over the wire&quot;. And it&#x27;s coming!)<p>1 - &quot;And many others&quot; that I&#x27;m sure was added to the text just to avoid angry email from wrong people, because there aren&#x27;t many others like those ones, and the few I know about wouldn&#x27;t get called MVC.

I personally wouldn&#x27;t start a new, greenfield web API project with an MVC framework. There are still too many choices present in how to handle concerns like querying, authn, authz, caching, migrations, etc, etc. I would use a system like PostgREST or Hasura and generate the API from the database directly.<p>Business logic can be handled on the control plane with replication&#x2F;subscriptions&#x2F;whatever mechanism. Small, stateful services that react to the event stream and perform whatever actions needed based on your business policies: send notifications, insert new records, call external partner APIs, etc.<p>For server-rendered UI I think there&#x27;s still a strong case for these frameworks but they could probably take some lessons and generate their data-layer models from the database DDL, push business logic down to the control plane, and focus on rendering current state from read-only models&#x2F;streams. I&#x27;ve been meaning to try something like this in Haskell (I&#x27;ve written some foundational libraries to enable this on Postgres [0]) but there are frameworks that do this like Phoenix in Elixir.<p>[0]: <a href="https:&#x2F;&#x2F;hackage.haskell.org&#x2F;package&#x2F;postgresql-replicant-0.1.0.1" rel="nofollow">https:&#x2F;&#x2F;hackage.haskell.org&#x2F;package&#x2F;postgresql-replicant-0.1...</a>

&gt; However, from what I&#x27;ve seen, there is still no Rails &#x2F; Django equivalent in JS world. Sails JS has a low satisfaction rate. Nest JS looks more like a wrapper around existing tools than a real framework. Blitz JS looks promising but has not enough traction. That may just not be the philosophy.<p>I think there is AdonisJS : <a href="https:&#x2F;&#x2F;adonisjs.com&#x2F;" rel="nofollow">https:&#x2F;&#x2F;adonisjs.com&#x2F;</a> which could be the Rails &#x2F; Django equivalent you&#x27;re looking for.

1) Meh, MVC was never all that, it&#x27;s kind of a guiding idea, but isn&#x27;t in the realm of relational databases as far as specific utility and power.<p>2) Dinosaurs are still around in the form of birds and have found amazing utility, so even the analogy lacks nuance ;)

What about maintenance of the framework? It can be a nightmare, not all frameworks are considered equal (I’m looking at you, SailsJS). And even mature frameworks come with plenty of woes WRT patching vulnerabilities. But, that can be attributed to the programming language package manager ecosystem. I will admit that I miss Spring Boot, it ruined all MVC frameworks after that for me other than native stuff like Swift.<p>I just build mostly from scratch now, (update) [using MVC monolith] feels icky because I’m not trying to start a company or working at a startup. Frameworks are bad suggestions in mid&#x2F;late stage company.<p>It’s nice to drop some value bombs, but if you intend to stick around for many years and you got more than 10 engineers in your organization, don’t choose a monolithic framework because it just makes the politics of getting your framework broken out into logical parts (ie micro services) a PITA. That’s my two cents.

You can&#x27;t reason about solutions when the problem is not defined.<p>Of course a monolith is a great choice for a team of 4 devs for example. It could be great even for a team of 20 devs. But when you have 30 teams of N devs, then the monolith maybe is not the best idea.<p>Businesses scale in different ways, and different stacks exist for this reason.

Meh.<p>From .NET Core 2.1 + Angular 5&#x2F;6 to .NET Core 6.0 Web API + Angular 12&#x2F;13 on the front-end = Total Win.<p>No need for changing what works. Svelte? React? Web Components? Naaaah, I am good.

Same post from yesterday (on second page of HN right now): <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=31310073" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=31310073</a>.

But you are not forced to build only monoliths with MVC frameworks. At least with .NET you can do the logic in a few API microservices and render the HTML&#x2F;HTMX in one or more MVC microservices.

And how do I build offline-first web applications with HTML over the wire?!? This whole HTML over the wire trick is actually pretty old and you can do some nice stuff with it, but it doesn&#x27;t solve all the use-cases you can solve with with JS frameworks&#x2F;libraries.<p>The big advantage I see for MVC applications, if that it is a well understood pattern. JS frameworks, on the other hand, come all ~3 years with some new innovative way to structure your code, while even the last approach isn&#x27;t fully understood by many people.

MVC is a great pattern, that solves some problems very well. Quite often it is just overkill, and makes the solution much more complicated.<p>But I don’t really see why you need a MVC framework for doing MVC.

Is the argument that because it&#x27;s a shark, we should accept that and avoid feeding any contenders?<p>Was the shark perfect at its inception or did it adapt as all things do?<p>Doesn&#x27;t its shark-ness come by virtue of surviving against the best efforts of challengers through time?<p>Isn&#x27;t that continual evolution at least in part dependent on a continuum of challengers?<p>Don&#x27;t we implicitly give up on searching for something that could potentially overtake the shark by dogmatically accepting the shark&#x27;s shark-ness?

I might replace the references to “MVC” with “monolith” to make it more clear. MVC is a dated and painful paradigm and orthogonal to monolith vs services.<p>I also would advise against using Hotwire for Rails, some of our worst bugs have come from the desyncing of HTML and JS from Hotwire, as well as unexpected network status code handling. And most people only run Hotwire in production, so bugs are easy to miss.

I played through this short guide a week or so ago: <a href="https:&#x2F;&#x2F;codelabs.developers.google.com&#x2F;create-an-instant-and-seamless-web-app" rel="nofollow">https:&#x2F;&#x2F;codelabs.developers.google.com&#x2F;create-an-instant-and...</a><p>Add SPA performance to a multi page app thanks to guided pre-rendering. I came away from it thinking that&#x27;s one less benefit an SPA holds over MPA now.

Of all the topics our design pattern study group gnawed on, MVC et al took the longest, sparked the most debate.<p>IMHO, &quot;MVC&quot; is the catch all term for anything defying neat summary and categorization.<p>Consequently, I assume any and all usage of &quot;MVC&quot; is an admission of ignorance, intentional or otherwise.

I like that people seem to be re-discovering Martin Fowler and the decades of thought that have already been put into the application development space.<p>Originally coming from a Java rich client world and moving into JS in ~2013, it always surprised me how much historical context the JS world was missing.

Here I am remembering when Rails was the shiny new thing and competing against various staid approaches in Java and Python, not to mention Cold Fusion and some of the other former hot things.

I wonder how WASM will change the landscape for these frameworks. If Python had something like Yew [0], I&#x27;m not sure I&#x27;d be writing React for my Django backend.<p>[0]: <a href="https:&#x2F;&#x2F;yew.rs&#x2F;" rel="nofollow">https:&#x2F;&#x2F;yew.rs&#x2F;</a>

ha, I thought this was going to be about C++ MVC frameworks.

Sharks are some of the oldest creatures on earth...

Btw if here on HN, people engaged less in which framework is better and how to render a table with the flavor of the day JS framework.<p>Then <i>maybe</i> just maybe, you will all have more time to work and become millionaires, just saying.

I hate MVC, or to be more specific Microsoft’s implementation of it. I know enough asp.net to build any site quickly, but when I move to mvc I have the feeling that I write a shit ton of unnecessary code just to get things in a state that might benefit me in the future. Well fuck that. I’d rather rewrite the whole thing in the future if it doesn’t suit my needs any longer, than spend 50% more time to write it in the first place.

This reads like someone who spent a lot of time using one particular framework (maybe two) and now wants to justify their inability to survive without said framework(s). Not sure at all why it&#x27;s also about monoliths and microservices; I&#x27;ve written microservices in Django, for example.<p>Sometimes a monolith makes sense. Other times, a microservice architecture makes sense. Sometimes a &quot;just right&quot; sized repo makes the most sense, neither a monolith nor a microservice.<p>Why does it have to be so tribal? Why is there a #monoteam and a #microteam?

&gt; You see, relational databases aren’t dinosaurs. They aren’t lumbering prehistoric relics doomed to extinction by a changing world. They are sharks. Apex predators honed by millions of years of evolution into a perfectly adapted creature that is just as effective today as it was eons ago.<p>RDBM is optimized for file size; it is very much an artifact of its time, when hard drive space was limited. I don&#x27;t buy it for a second.<p>People think in dictionaries, so just use one. If you are making a simple app and don&#x27;t need transactions, aggregations, or multiple connections, then just use JSON in an S3 bucket or something. If you are going a step farther, JSON-based databases are quite feature complete these days. For monolithic business logic applications, relational databases are the right tool IMO, but they are used for <i>every</i> use case when they are absolutely not needed.<p>Controversial claim: Joins are a foot gun. It is so easy to make too many tables and mis-use unnecessarily complex table structures because it feels safe and &quot;engineery&quot; to do it. I don&#x27;t know how many young startups I&#x27;ve seen that absolutely struggle with RDBM performance, and almost always they have gotten themselves into some horrible situation joining five tables deep with a spaghetti ERD and no clear pathway forward. It is hard to make the same mistakes with a JSON foundation.