20 ms·

MVC frameworks aren't dinosaurs but sharks

318 points by j4mie 4y ago

SantiagoElf 4y ago
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. Then maybe just maybe, you will all have more time to work and become millionaires, just saying.
gilbetron 4y ago
1) Meh, MVC was never all that, it's kind of a guiding idea, but isn't in the realm of relational databases as far as specific utility and power. 2) Dinosaurs are still around in the form of birds and have found amazing utility, so even the analogy lacks nuance ;)
- collyw 4y ago
  The MVC frameworks he was talking about all rely on relational databases as far as I am aware. Django certainly does.
  - DeathArrow 4y ago
    ASP.NET MVC doesn't rely on any database. People tend to use it with relational databases but it will work happily with MongoDB, Cassandra, Redis and just about any database.
eatonphil 4y ago
Same post from yesterday (on second page of HN right now): https://news.ycombinator.com/item?id=31310073 https://news.ycombinator.com/item?id=31310073.
cosmiccatnap 4y ago
Sharks are some of the oldest creatures on earth...
- camdv 4y ago
  That's the point of the article. Oldest and well-adapted.
dismantlethesun 4y ago
I know it’s probably obvious to some but in an MVC framework: the API can be the view. That’s the whole point of separating the code into layers: so you can have multiple implementations existing concurrently at the same layer. 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. And if you were to abstract beyond the framework level, MVC can apply to software written in totally different languages. 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.
- ethbr0 4y ago
  IMHO, the primary value of any framework (from an organization / product lifetime perspective) is two-fold. #1 - Organize and implement in a manner that adheres to some standards, so someone can always be found to maintain and fix it. #2 - Create some interfaces that break components apart. What standards and what interfaces (and how many) are an order of magnitude less important than that they exist at all.
  - shafyy 4y ago
    Don't forget: #0 - Speed/Developer productivity Not only when writing actual code, but there's less bike shedding and "fundamental" discussions.
    - collyw 4y ago
      This is what I was thinking. Got Tornado plus a load of home grown code at my work. Compared to Django it's just so slow to develop on. There are so many well tested, documented features in Django, while we have some half arsed buggy implementation doing a poorer job.
hu3 4y ago
> 2 - Monoliths still make sense in many contexts Yes and I'd argue it makes sense in most contexts for small startups. Also, Monolith is sometimes synonymous with tangled spaghetti code but it doesn't have to be. If code is kept organized, it can be split into microservices when/if the need arises.
- mathgorges 4y ago
  Hard agree. If you aren't familiar, I find The App Continuum [1] to be fantastic for structuring these kind of conversations with my teams :D [1]: https://www.appcontinuum.io/ https://www.appcontinuum.io/
- nicoburns 4y ago
  > If code is kept organized, it can be split into microservices when/if the need arises. You can even just run multiple copies of the monolith with feature flags to enable/disable different parts of the code.
  - cheradenine_uk 4y ago
    I know, right? It's also perfectly possible to split those things up, and to have them share the same database. This causes microservice extremists' heads to pop off..
    - withinboredom 4y ago
      We do this at work with multiple entry points. New engineers sometimes don’t even know it exists until the 6th month when they eventually run into shenanigans.
      - cheradenine_uk 4y ago
        Hehe "shenanigans" ;-) The truth is, most things can be made to work - though there are various trade-offs ("shenanigans") involved. e.g: In my current project, there's a bit that loads large-ish files, parses/converts the data, and loads them (order of tens of thousands of rwos) into SQL tables. For reasons that best escape me - since after the files are parsed the entire dataset is _literally_ in memory, instead of doing a bulk sql update there- and then, thousands of messages are enqueued to be consumed by a practically unlimited number of lambda functions that then... bomb out as the SQL database hits it's connection limit and keels over. I guess those shenanigans have better buzzword compliance!
lexx 4y ago
You can't reason about solutions when the problem is not defined. 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. Businesses scale in different ways, and different stacks exist for this reason.
- pier25 4y ago
  Exactly. The problem is that so many small teams (even solo devs) believe they should be acting like big corps with 30 teams of N devs.
  - lexx 4y ago
    True, that is also very funny in my opinion. It's our need to play with new toys that makes us over-engineer stuff. As I get more experienced, I try to find the easiest, most profound solution to a problem. At the same time I "design" escape scenarios. If that business will scale in that x way then I will be able to do y. Most times the need for scale never comes.
  - gedy 4y ago
    Yes but bear in mind successful companies do grow and you are then frequently stuck with the startup type choices made early on because "now it's too late" - even if it just due to original small team now being the tech leadership and know no other way. Been at a 30 team company working on an old Rails monolith and it totally sucked.
    - lexx 4y ago
      Yeah, I get that and it happened to me too. That can happen in any design though. Even with a microservices approach. As I said in the previous comment, you have to design your way out of the thing you are building. Not easy at all, and sometimes, not possible to predict. I mean successful companies do grow, but a lot of times they pivot, etc.
    - deleted 4y ago
      [deleted]
TameAntelope 4y ago
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's also about monoliths and microservices; I've written microservices in Django, for example. Sometimes a monolith makes sense. Other times, a microservice architecture makes sense. Sometimes a "just right" sized repo makes the most sense, neither a monolith nor a microservice. Why does it have to be so tribal? Why is there a #monoteam and a #microteam?
- hermitdev 4y ago
  > Why does it have to be so tribal? I think it's just a symptom of "When the only tool you have is a hammer, everything looks like a nail."
ChrisMarshallNY 4y ago
I write UI apps, using Apple'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'll actually be shipping (mostly doing stuff like aligning UI elements and applying accessibility and localization, which can take quite some time. Lots of iteration). I'm putting the finishing touches on my second app in about a month and a half. It's a "total rewrite" app; just like the previous one (which is already out there, and has had over a thousand downloads already). I did these apps alone. After this one is out the door, I'll return to the app I've been working on for a year and a half. These were just "side trips," because I was getting burned out. UIKit was designed as an MVC framework. If you use a different pattern, then "you're holding it wrong." You are using the framework in a manner for which it was not designed. That is not always bad. I can't actually think of any examples, right now, but I'm sure that some of the new methodologies are more effective. I strongly suspect that some of the new development patterns (I won'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. Might work out. I don't know. That's not how I work. YMMV.
- tragictrash 4y ago
  Thank you! My team recently implemented a section of the app with SwiftUI in 'MVVM' and it is a unmaintainable tangled mess. We should have used something more like MVC.
- pvg 4y ago
  really best done by one or two skilled engineers, into ones done by a fairly large team of relatively unskilled engineers. I think this is mostly a way to flatter ourselves about things we don't like. It's perfectly fine to not like things but as an argument, it is pretty poor. It's at also at the core of PG's 'blub language' thing, a mistake at the time that's aged even less well.
  - ChrisMarshallNY 4y ago
    I'm sorry. It must be my age, but I don't really understand the comment. Was I supposed to be insulted? It may have fallen wide of the mark, if so. I wasn't railing against anything that "I don't like." I was simply stating that I use MVC, on a regular, daily basis, and it gives me the results that I require. And, I know, for a fact, that some of these patterns are used for exactly the reason that I stated. I know this, because I have talked to the managers that decided to use them, and that was the motivation. I don't even have an opinion on whether or not that is bad. Many of these teams do great work. Maybe things are better, done in ways beyond my limited, saurian, comprehension. All I can say, is that I'm able to churn out a lot of stuff, of extremely high Quality, in a remarkably short time, using these prehistoric patterns. I know that Apple developed the patterns they use, in order to allow very small teams to create high-Quality, high-performance apps, in very short time (again, because I've talked to some of the folks involved in writing UIKit). People like me, working the way I do, were what they had in mind, as they developed their frameworks. SwiftUI looks pretty cool. I haven't used it much [yet], because I have yet to be convinced that it is suitable for ambitious, shippable projects. I'm waiting for it to develop a bit of momentum. At first glance, it doesn’t seem to be designed for MVC (but it may work great. I don’t know enough about it, yet, to be sure). I’m happy to learn up on whatever methodology works best for it. I learn quickly, and adapt extremely well. Been doing exactly that, for quite some time.
nassimsoftware 4y ago
> However, from what I've seen, there is still no Rails / 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. I think there is AdonisJS : https://adonisjs.com/ https://adonisjs.com/ which could be the Rails / Django equivalent you're looking for.
- davepeck 4y ago
  AFAIK RedwoodJS seeks to be the Rails/Django of the JS world: https://redwoodjs.com https://redwoodjs.com
  - multiplegeorges 4y ago
    Redwood looks promising, but it only went 1.0 ~a month ago. Rails went 1.0 in 2005. The JS ecosystem has had a long time to come up with something equivalent.
- swlkr 4y ago
  There's also https://remix.run https://remix.run
- popcorncowboy 4y ago
  I think the point stands. Nest, Sails, Adonis, Redwood, Blitz and many others you could plausibly lump into this list, all of which are playing catchup/reinvent to the alt-language sharks, none of which have crossed the threshold where the Lindy Effect [0] would apply. There is as yet no MVC/Rails shark for the Node/JS ecosystem. [0] - https://en.wikipedia.org/wiki/Lindy_effect https://en.wikipedia.org/wiki/Lindy_effect
stevebmark 4y ago
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. 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.
- likortera 4y ago
  > And most people only run Hotwire in production eh? Aren't you confusing the full "Hotwire" suite with just Turbo? I don't think you cannot run "Hotwire" in development.
antris 4y ago
>But as a general rule, I think we must not discard a technology just because it's old. Doing so because it's too new would make more sense, if you want to build stuff for businesses. Agree with the first statement but, not necessarily on the second. People dismissed React for being "too new" or "the latest stupid shiny new framework" for a long time because they didn'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/resetting code and making sure it never breaks. It was something I was already thinking about: "how could I avoid writing all this tedious DOM manipulation code". 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. Sometimes tools pop up that make perfect sense. So you shouldn't dismiss any technology for its age, whether it's old or new.
- pjerem 4y ago
  Yup. And that’s why author wrote "But as a general rule" instead of as an immuable rule.
- m12k 4y ago
  The problem with new tech isn't just that it might not make sense. It's also that if it doesn't gain enough traction to reach critical mass, it might not be a good technical foundation for your business. As a business owner the question isn't just "can I solve the problems I face today using this?" it's also "will I be able to hire developers that know this 10 years from now?" and "will there continue to be an ecosystem of useful middleware for this?" For React, the answer is yes to all of those, and has been for a couple years now, but 5 years ago, the latter questions weren't really decided yet.
  - antris 4y ago
    If you only use React as a library for the VDOM, there's barely anything to learn, though. Even if nobody had heard of it previously, people would get up to speed in no time. That's how I started using it, keep my application as it is but just use React as the DOM diffing engine and delete tons of DOM manipulation code from the repo. The "React as a framework" thing came later, which I personally think is a misstep. I'm not into frameworks in general.
projektfu 4y ago
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.
- sparker72678 4y ago
  Cold Fusion was my first introduction to web apps and templated html! I wouldn’t want to go back, but those were some fun days.
duxup 4y ago
>But as a general rule, I think we must not discard a technology just because it's old. I forget who had the quote that went something like: "If SQL is so great why have people been trying to replace it for decades?" (the failure to replace it is of course the punchline, in case anyone misses that)
recursivedoubts 4y ago
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. 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. Bullish on 2005 tech books!
- nathias 4y ago
  htmx loks really cool, a performance comparison vs the fastest SSR SPAs would be helpful
- robertlagrant 4y ago
  Did you make htmx? I love that thing.
  - recursivedoubts 4y ago
    yep, glad you are finding it useful :)
    - 0des 4y ago
      I see you just about everywhere on the internet. It's nuts. Prove that you aren't a pile of ants wearing a trenchcoat.
      - robertlagrant 4y ago
        Beats half a million ants and half collapsing star.
- no_wizard 4y ago
andix 4y ago
MVC is a great pattern, that solves some problems very well. Quite often it is just overkill, and makes the solution much more complicated. But I don’t really see why you need a MVC framework for doing MVC.
- collyw 4y ago
  If you are doing MVC why wouldn't you use a framework? Lots of well tested code written for you already. Why reinvent the parts of the wheel the are there already?
ape4 4y ago
ha, I thought this was going to be about C++ MVC frameworks.
ARandumGuy 4y ago
I feel like MVC frameworks, like most application frameworks, are caught in a constant push-pull cycle. Devs write without a framework, but complain that they have to spend a lot of time working on the structure of their application. There'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. Devs then work with a third party famework for a while, but get frustrated when their application needs don't match up with what their framework is good at. They then have to write hacky workarounds to add the functionality they need. There's a desire to ditch the prescriptive framework, and design the code structure in a way that meets up with the application's specific needs. And then the cycle repeats itself. Application frameworks, whether MVC or something else, are a useful tool. But there's no perfect framework, and it's easy to feel like the grass is greener on the other side.
- DeathArrow 4y ago
  That doesn't in the .NET world as the framework does not stand in your way. Everybody uses the framework. It comes with batteries included but it's very modular and you can use only the parts you need and use custom functionality if the framework provided functionality does not match your needs.
SantiagoElf 4y ago
Meh. From .NET Core 2.1 + Angular 5/6 to .NET Core 6.0 Web API + Angular 12/13 on the front-end = Total Win. No need for changing what works. Svelte? React? Web Components? Naaaah, I am good.
- mmis1000 4y ago
  Some people just forgot why the MVC and these tools are invented at first place. They complains the framework you use isn't shiny enough. While in practice, things they write using these shiny frameworks performs outright painfully. It's really a weird trend that everyone just run for the newest thing and forgot why these are invented for at first place.
  - SantiagoElf 4y ago
    They jump on the new thing - thinking it will solve their issues. But the reality, the issue is them not 'understanding/knowing/being able to build semi-good software. Think about it - you have the Fed literally printing money, then many VCs giving MILLIONS to half-assed, barely functioning prototypes. The idea is not there, the craftsmanship is not there - it's just a bunch of kids on Adderall slapping some nice-looking UI and getting paid. Guess what the thing they like to talk about is - the technology behind it because sure as hell it doesn't solve any business need. It is hilarious.
    - DeathArrow 4y ago
      Talking about the Emperor's clothes...
- DeathArrow 4y ago
  I am very happy with ASP.NET. But I either use MVC + HTMX or Blazor for the rare cases I also have to do the frontend (which is mostly work done for myself). If other people are doing the Frontend, I don't care what they use. I just show them the data contracts and wish them good luck.
agentultra 4y ago
I personally wouldn'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. Business logic can be handled on the control plane with replication/subscriptions/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. For server-rendered UI I think there'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/streams. I've been meaning to try something like this in Haskell (I've written some foundational libraries to enable this on Postgres [0]) but there are frameworks that do this like Phoenix in Elixir. [0]: https://hackage.haskell.org/package/postgresql-replicant-0.1.0.1 https://hackage.haskell.org/package/postgresql-replicant-0.1...
- sparker72678 4y ago
  Or you could just use Rails and actually ship a product within the first year of work.
  - agentultra 4y ago
    Whatever floats your boat. I can stand up a REST API server with PostgREST and a database in a couple of hours. I can deploy new models with a SQL migration. Like I said, if you want to do server-side rendering it's still a place where Rails/Django/etc shine but I think they could learn a thing or two there to make them better. They could improve so that folks can write/maintain even less code.
- DeathArrow 4y ago
  >I personally wouldn'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. It depends on the framework. In .NET the only difference between MVC and API is the base class of the controller. You either return JSON or you return a view. Database connections, migrations, routing, serialization, error handling, exception handling, authentication, authorization, Swagger specification, Docker file generation, can be handled by the framework if you so desire. Also, you can mix MVC controllers and API controllers in the same project if you so desire. >For server-rendered UI I think there'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 I find it better to just generate the database from the domain entities using code first approach. It's faster and the ORM will generate proper indexes and also provide optimized SQL queries.
marcosdumay 4y ago
"MVC" is such an overloaded term. The article is quite clear it's about Django, Rails and Laravel¹, yet there are already people here complaining about different meanings of that name. Hell, Microsoft has a framework literally called "MVC" that has only a passing similarity to them, but is completely different on practice. "Framework" is also too overloaded to my tastes, less so than "MVC", but you will still get confused people if you use it without context. Using those terms make ideas less clear, not more. I do really avoid using them, and I would recommend doing the same for anybody. (Anyway, it's nice to know that getting the region's HTML and applying it to the innerHTML of an element, like I was doing with JQuery decades ago is called "HTML over the wire". And it's coming!) 1 - "And many others" that I'm sure was added to the text just to avoid angry email from wrong people, because there aren't many others like those ones, and the few I know about wouldn't get called MVC.
louissan 4y ago
An excellent article. As huge Django fan, I could not agree more (so yes, biased :-) ) Since 2015, I've always rendered final HTML server-side, whether that HTML was travelling over a complete http request/response cycle (big page load or XHR or fetch), or over websockets. The only JSON ever involved was stuff similar {"markup":"you html code here"} and a few other more subtle bits to make up for a dumb/blind client. In other words, the client does as it's told by the server. (my client is Azatoth) Opinionated? Yes. Full-of-bad-suprises-after-release-oh-shit-what-did-I-do? No 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/api/whatever. But doesn't do much insuring a certain level of quality, sanity and stability in the long(er) run. my 2pence.
RunawayGalaxy 4y ago
Is the argument that because it's a shark, we should accept that and avoid feeding any contenders? Was the shark perfect at its inception or did it adapt as all things do? Doesn't its shark-ness come by virtue of surviving against the best efforts of challengers through time? Isn't that continual evolution at least in part dependent on a continuum of challengers? Don't we implicitly give up on searching for something that could potentially overtake the shark by dogmatically accepting the shark's shark-ness?
- sparker72678 4y ago
  Go for it, but also admit you’re trying to out-compete a shark. The bar for success in that case is pretty high, and the challenge significant.
tantaman 4y ago
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. 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.
- viggity 4y ago
  Node/Angular are exactly what you get when you disregard Chesterson's Fence.
  - popcorncowboy 4y ago
    https://thoughtbot.com/blog/chestertons-fence https://thoughtbot.com/blog/chestertons-fence > There exists in such a case a certain institution or law; let us say, for the sake of simplicity, a fence or gate erected across a road. The more modern type of reformer goes gaily up to it and says, “I don’t see the use of this; let us clear it away.” To which the more intelligent type of reformer will do well to answer: “If you don’t see the use of it, I certainly won’t let you clear it away. Go away and think. Then, when you can come back and tell me that you do see the use of it, I may allow you to destroy it.”
Pandabob 4y ago
I wonder how WASM will change the landscape for these frameworks. If Python had something like Yew [0], I'm not sure I'd be writing React for my Django backend. [0]: https://yew.rs/ https://yew.rs/
elorant 4y ago
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.
- metaltyphoon 4y ago
  Good thing that you have Razor pages which is insanely easier, and for most projects, good enough.
  - elorant 4y ago
    Yeap. Blazor too is promising.
- DeathArrow 4y ago
  Can you provide an example of unnecessary code you have to write? I assume you are referring to Core based MVC, not the old one.
  - elorant 4y ago
    MVC requires me to write at least 50% more code than asp.net. That's what I mean by unnecessary. And I'm referring to the "old" mvc model, I haven't bothered with asp.net core mvc.
    - DeathArrow 4y ago
      >, I haven't bothered with asp.net core mvc. You should try, because now there is almost no difference between MVC and WebAPI. You just have controllers with different base classes.
DeathArrow 4y ago
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/HTMX in one or more MVC microservices.
arendtio 4y ago
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't solve all the use-cases you can solve with with JS frameworks/libraries. 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't fully understood by many people.
- oneplane 4y ago
  I think you can run MVC applications locally just fine. Instead of shipping electron you'd ship a server runtime, and you'd access the application on localhost instead of in the web view of the electron app. Unless you're talking about PWA, but in theory you'd get MVC PWA apps that do that same (but you're right in that it's an endless cycle of distinctions without a difference in the JS ecosystem).
- gcpwnd 4y ago
  > And how do I build offline-first web applications with HTML over the wire?!? I can't give you an perfect answer, because I am not aware of a practical example. But I think its quite doable. In a very naive way you can just store the results locally and use them when requested while offline. That potentially increases the storage size of individual items due to the HTML overhead of course. A fairly small app with little offline content could be quite simple. An advanced approach could be to push template parsing to the frontend. HTML fragments could use i.e. micro formats to retrieve data from the HTML and store it for later use. The question in this case how much logic you have to duplicate. I.e. template parsing should be very simple, unless you can share the template engine.
  - arendtio 4y ago
    > An advanced approach could be to push template parsing to the frontend. Sounds more like a JS view/vue ;-) Sure, it is possible, but then you are probably better off using a proper JS framework with SSR (server side rendering) support.
mod 4y ago
> 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. When it's needed, fine. But there are so many SPAs that just don't need to be. Rendering HTML server-side is just nice. It's simple and easy to work with. Weird states are unusual. The user gets a really normalized, predictable experience. And done well/quickly, there's little actual difference. Maybe I'm just showing my age. This falls really close to my "I miss the old web" 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/SPA stuff). I don't think I'm going to have any javascript at all. It's really fun and lean. I don't know, it's just got me going lately--reminds me of when I was starting out. My last project is 300 lines of python, 270 lines of php, html/css of course, postgresql, and cron. Some scrapers run, ingest data, and the php sorts and displays it.
- moonchrome 4y ago
  In my experience server side rendering becomes really messy once you hit complex state management. Shuffling shit between pages, persistent vs transient state, handling reload/resubmit logic, validation. It works for simple stuff but even then I think once SPA tech matures more (ironically even after all this time I think transpilers/bundlers/package managers in JS still have a long way to go to get out of the way and frameworks are still far from optimal) anything that's not a web page should handle UI logic on the front-end.
  - zippercreatemy 4y ago
    WHAT??? Okay I am going to bite, state is managed by the browser and then SPAs came along and tried to hack the state management ever since. I remember creating SPAs in 2004 when it was called AJAX and there was the debate of HTML or JSON over the wire. The biggest issue was back and forward buttons, even today that issue is not solved very well by SPAs. The issue I have is we had a great idea to refresh parts of a page with AJAX and then we went overboard and tried to move the entire application to complex frameworks which add more problems then they solve. We became so scared of screen rendering we avoided at all costs. This is bad UX as users actually get good confirmation that something has happened when there is a screen refresh.
specialist 4y ago
Of all the topics our design pattern study group gnawed on, MVC et al took the longest, sparked the most debate. IMHO, "MVC" is the catch all term for anything defying neat summary and categorization. Consequently, I assume any and all usage of "MVC" is an admission of ignorance, intentional or otherwise.
cultofmetatron 4y ago
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. 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. 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. 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.
- vereis 4y ago
  Guaranteeing a singleton process is a very difficult problem which horde definitely does not solve perfectly mind you. All is well and good until it isn't. We opted for leveraging different mix release permutations deployed on k8s as needed instead. Definitely takes more effort than what you describe, and has its own issues... But imo definitely better understood than fighting weird state with horde
- spion 4y ago
  Elixir (and Phoenix) are truly amazing. I only wish there was a typesystem / spec system better (stricter) than Dialyzer. Or perhaps I am doing something wrong but I couldn't get it to be as strict - if there is a way i'd love for `credo` to force me to adhere to it.
  - cultofmetatron 4y ago
    its unfortunate that elixir's type system isn't too strict. That said, if you want somethign stricter, there is gleam (https://gleam.run/ https://gleam.run/) which has interop with elixir. I haven't tried it myself yet but you could probably embed a service in gleam for specific cases where you need the stricter type checking.
deleted 4y ago
[deleted]
CraigJPerry 4y ago
I played through this short guide a week or so ago: https://codelabs.developers.google.com/create-an-instant-and-seamless-web-app https://codelabs.developers.google.com/create-an-instant-and... Add SPA performance to a multi page app thanks to guided pre-rendering. I came away from it thinking that's one less benefit an SPA holds over MPA now.
engineeringwoke 4y ago
> 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. RDBM is optimized for file size; it is very much an artifact of its time, when hard drive space was limited. I don't buy it for a second. People think in dictionaries, so just use one. If you are making a simple app and don'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 every use case when they are absolutely not needed. 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 "engineery" to do it. I don't know how many young startups I'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.
- DeathArrow 4y ago
  If the data is highly relational, no JSON structure and data duplication will save you from joins. You will either do them at database level or in memory. I see a need for relational databases, NoSQL, data lakes and all other storage strategies. You chose based on the type of data, the way you acquire it, the way you process and deliver it, based on security and reliability needs. In many non trivial application there is more than one data storage solution implied. Since I work with large microservice based apps, it's a long time since I have to use more than one data storage strategy in the same app.
  - engineeringwoke 4y ago
    Agreed on all points. I still think RDBM is over-used; it's the default in many shops for any minor micro-service. It's like using a 20-piece multi-tool for something that only needs a regular kitchen knife.
awill88 4y ago
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. 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/late stage company. 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.

318 points by j4mie 4y ago

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. Then maybe just maybe, you will all have more time to work and become millionaires, just saying.

gilbetron 4y ago

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

collyw 4y ago
The MVC frameworks he was talking about all rely on relational databases as far as I am aware. Django certainly does.
- DeathArrow 4y ago
  ASP.NET MVC doesn't rely on any database. People tend to use it with relational databases but it will work happily with MongoDB, Cassandra, Redis and just about any database.

eatonphil 4y ago

Same post from yesterday (on second page of HN right now): https://news.ycombinator.com/item?id=31310073 https://news.ycombinator.com/item?id=31310073.

cosmiccatnap 4y ago

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

camdv 4y ago
That's the point of the article. Oldest and well-adapted.

dismantlethesun 4y ago

I know it’s probably obvious to some but in an MVC framework: the API can be the view. That’s the whole point of separating the code into layers: so you can have multiple implementations existing concurrently at the same layer. 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. And if you were to abstract beyond the framework level, MVC can apply to software written in totally different languages. 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.

ethbr0 4y ago
IMHO, the primary value of any framework (from an organization / product lifetime perspective) is two-fold. #1 - Organize and implement in a manner that adheres to some standards, so someone can always be found to maintain and fix it. #2 - Create some interfaces that break components apart. What standards and what interfaces (and how many) are an order of magnitude less important than that they exist at all.
- shafyy 4y ago
  Don't forget: #0 - Speed/Developer productivity Not only when writing actual code, but there's less bike shedding and "fundamental" discussions.
  - collyw 4y ago
    This is what I was thinking. Got Tornado plus a load of home grown code at my work. Compared to Django it's just so slow to develop on. There are so many well tested, documented features in Django, while we have some half arsed buggy implementation doing a poorer job.

hu3 4y ago

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

mathgorges 4y ago
Hard agree. If you aren't familiar, I find The App Continuum [1] to be fantastic for structuring these kind of conversations with my teams :D [1]: https://www.appcontinuum.io/ https://www.appcontinuum.io/
nicoburns 4y ago
> If code is kept organized, it can be split into microservices when/if the need arises. You can even just run multiple copies of the monolith with feature flags to enable/disable different parts of the code.
- cheradenine_uk 4y ago
  I know, right? It's also perfectly possible to split those things up, and to have them share the same database. This causes microservice extremists' heads to pop off..
  - withinboredom 4y ago
    We do this at work with multiple entry points. New engineers sometimes don’t even know it exists until the 6th month when they eventually run into shenanigans.
    - cheradenine_uk 4y ago
      Hehe "shenanigans" ;-) The truth is, most things can be made to work - though there are various trade-offs ("shenanigans") involved. e.g: In my current project, there's a bit that loads large-ish files, parses/converts the data, and loads them (order of tens of thousands of rwos) into SQL tables. For reasons that best escape me - since after the files are parsed the entire dataset is _literally_ in memory, instead of doing a bulk sql update there- and then, thousands of messages are enqueued to be consumed by a practically unlimited number of lambda functions that then... bomb out as the SQL database hits it's connection limit and keels over. I guess those shenanigans have better buzzword compliance!

lexx 4y ago

You can't reason about solutions when the problem is not defined. 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. Businesses scale in different ways, and different stacks exist for this reason.

pier25 4y ago
Exactly. The problem is that so many small teams (even solo devs) believe they should be acting like big corps with 30 teams of N devs.
- lexx 4y ago
  True, that is also very funny in my opinion. It's our need to play with new toys that makes us over-engineer stuff. As I get more experienced, I try to find the easiest, most profound solution to a problem. At the same time I "design" escape scenarios. If that business will scale in that x way then I will be able to do y. Most times the need for scale never comes.
- gedy 4y ago
  Yes but bear in mind successful companies do grow and you are then frequently stuck with the startup type choices made early on because "now it's too late" - even if it just due to original small team now being the tech leadership and know no other way. Been at a 30 team company working on an old Rails monolith and it totally sucked.
  - lexx 4y ago
    Yeah, I get that and it happened to me too. That can happen in any design though. Even with a microservices approach. As I said in the previous comment, you have to design your way out of the thing you are building. Not easy at all, and sometimes, not possible to predict. I mean successful companies do grow, but a lot of times they pivot, etc.
  - deleted 4y ago
    [deleted]

TameAntelope 4y ago

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's also about monoliths and microservices; I've written microservices in Django, for example. Sometimes a monolith makes sense. Other times, a microservice architecture makes sense. Sometimes a "just right" sized repo makes the most sense, neither a monolith nor a microservice. Why does it have to be so tribal? Why is there a #monoteam and a #microteam?

hermitdev 4y ago
> Why does it have to be so tribal? I think it's just a symptom of "When the only tool you have is a hammer, everything looks like a nail."

ChrisMarshallNY 4y ago

I write UI apps, using Apple'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'll actually be shipping (mostly doing stuff like aligning UI elements and applying accessibility and localization, which can take quite some time. Lots of iteration). I'm putting the finishing touches on my second app in about a month and a half. It's a "total rewrite" app; just like the previous one (which is already out there, and has had over a thousand downloads already). I did these apps alone. After this one is out the door, I'll return to the app I've been working on for a year and a half. These were just "side trips," because I was getting burned out. UIKit was designed as an MVC framework. If you use a different pattern, then "you're holding it wrong." You are using the framework in a manner for which it was not designed. That is not always bad. I can't actually think of any examples, right now, but I'm sure that some of the new methodologies are more effective. I strongly suspect that some of the new development patterns (I won'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. Might work out. I don't know. That's not how I work. YMMV.

tragictrash 4y ago
Thank you! My team recently implemented a section of the app with SwiftUI in 'MVVM' and it is a unmaintainable tangled mess. We should have used something more like MVC.
pvg 4y ago
really best done by one or two skilled engineers, into ones done by a fairly large team of relatively unskilled engineers. I think this is mostly a way to flatter ourselves about things we don't like. It's perfectly fine to not like things but as an argument, it is pretty poor. It's at also at the core of PG's 'blub language' thing, a mistake at the time that's aged even less well.
- ChrisMarshallNY 4y ago
  I'm sorry. It must be my age, but I don't really understand the comment. Was I supposed to be insulted? It may have fallen wide of the mark, if so. I wasn't railing against anything that "I don't like." I was simply stating that I use MVC, on a regular, daily basis, and it gives me the results that I require. And, I know, for a fact, that some of these patterns are used for exactly the reason that I stated. I know this, because I have talked to the managers that decided to use them, and that was the motivation. I don't even have an opinion on whether or not that is bad. Many of these teams do great work. Maybe things are better, done in ways beyond my limited, saurian, comprehension. All I can say, is that I'm able to churn out a lot of stuff, of extremely high Quality, in a remarkably short time, using these prehistoric patterns. I know that Apple developed the patterns they use, in order to allow very small teams to create high-Quality, high-performance apps, in very short time (again, because I've talked to some of the folks involved in writing UIKit). People like me, working the way I do, were what they had in mind, as they developed their frameworks. SwiftUI looks pretty cool. I haven't used it much [yet], because I have yet to be convinced that it is suitable for ambitious, shippable projects. I'm waiting for it to develop a bit of momentum. At first glance, it doesn’t seem to be designed for MVC (but it may work great. I don’t know enough about it, yet, to be sure). I’m happy to learn up on whatever methodology works best for it. I learn quickly, and adapt extremely well. Been doing exactly that, for quite some time.

nassimsoftware 4y ago

> However, from what I've seen, there is still no Rails / 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. I think there is AdonisJS : https://adonisjs.com/ https://adonisjs.com/ which could be the Rails / Django equivalent you're looking for.

davepeck 4y ago
AFAIK RedwoodJS seeks to be the Rails/Django of the JS world: https://redwoodjs.com https://redwoodjs.com
- multiplegeorges 4y ago
  Redwood looks promising, but it only went 1.0 ~a month ago. Rails went 1.0 in 2005. The JS ecosystem has had a long time to come up with something equivalent.
swlkr 4y ago
There's also https://remix.run https://remix.run
popcorncowboy 4y ago
I think the point stands. Nest, Sails, Adonis, Redwood, Blitz and many others you could plausibly lump into this list, all of which are playing catchup/reinvent to the alt-language sharks, none of which have crossed the threshold where the Lindy Effect [0] would apply. There is as yet no MVC/Rails shark for the Node/JS ecosystem. [0] - https://en.wikipedia.org/wiki/Lindy_effect https://en.wikipedia.org/wiki/Lindy_effect

stevebmark 4y ago

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

likortera 4y ago
> And most people only run Hotwire in production eh? Aren't you confusing the full "Hotwire" suite with just Turbo? I don't think you cannot run "Hotwire" in development.

antris 4y ago

>But as a general rule, I think we must not discard a technology just because it's old. Doing so because it's too new would make more sense, if you want to build stuff for businesses. Agree with the first statement but, not necessarily on the second. People dismissed React for being "too new" or "the latest stupid shiny new framework" for a long time because they didn'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/resetting code and making sure it never breaks. It was something I was already thinking about: "how could I avoid writing all this tedious DOM manipulation code". 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. Sometimes tools pop up that make perfect sense. So you shouldn't dismiss any technology for its age, whether it's old or new.

pjerem 4y ago
Yup. And that’s why author wrote "But as a general rule" instead of as an immuable rule.
m12k 4y ago
The problem with new tech isn't just that it might not make sense. It's also that if it doesn't gain enough traction to reach critical mass, it might not be a good technical foundation for your business. As a business owner the question isn't just "can I solve the problems I face today using this?" it's also "will I be able to hire developers that know this 10 years from now?" and "will there continue to be an ecosystem of useful middleware for this?" For React, the answer is yes to all of those, and has been for a couple years now, but 5 years ago, the latter questions weren't really decided yet.
- antris 4y ago
  If you only use React as a library for the VDOM, there's barely anything to learn, though. Even if nobody had heard of it previously, people would get up to speed in no time. That's how I started using it, keep my application as it is but just use React as the DOM diffing engine and delete tons of DOM manipulation code from the repo. The "React as a framework" thing came later, which I personally think is a misstep. I'm not into frameworks in general.

projektfu 4y ago

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.

sparker72678 4y ago
Cold Fusion was my first introduction to web apps and templated html! I wouldn’t want to go back, but those were some fun days.

duxup 4y ago

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

recursivedoubts 4y ago

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. 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. Bullish on 2005 tech books!

nathias 4y ago
htmx loks really cool, a performance comparison vs the fastest SSR SPAs would be helpful
robertlagrant 4y ago
Did you make htmx? I love that thing.
- recursivedoubts 4y ago
  yep, glad you are finding it useful :)
  - 0des 4y ago
    I see you just about everywhere on the internet. It's nuts. Prove that you aren't a pile of ants wearing a trenchcoat.
    - robertlagrant 4y ago
      Beats half a million ants and half collapsing star.
no_wizard 4y ago

andix 4y ago

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

collyw 4y ago
If you are doing MVC why wouldn't you use a framework? Lots of well tested code written for you already. Why reinvent the parts of the wheel the are there already?

ape4 4y ago

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

ARandumGuy 4y ago

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

DeathArrow 4y ago
That doesn't in the .NET world as the framework does not stand in your way. Everybody uses the framework. It comes with batteries included but it's very modular and you can use only the parts you need and use custom functionality if the framework provided functionality does not match your needs.

SantiagoElf 4y ago

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

mmis1000 4y ago
Some people just forgot why the MVC and these tools are invented at first place. They complains the framework you use isn't shiny enough. While in practice, things they write using these shiny frameworks performs outright painfully. It's really a weird trend that everyone just run for the newest thing and forgot why these are invented for at first place.
- SantiagoElf 4y ago
  They jump on the new thing - thinking it will solve their issues. But the reality, the issue is them not 'understanding/knowing/being able to build semi-good software. Think about it - you have the Fed literally printing money, then many VCs giving MILLIONS to half-assed, barely functioning prototypes. The idea is not there, the craftsmanship is not there - it's just a bunch of kids on Adderall slapping some nice-looking UI and getting paid. Guess what the thing they like to talk about is - the technology behind it because sure as hell it doesn't solve any business need. It is hilarious.
  - DeathArrow 4y ago
    Talking about the Emperor's clothes...
DeathArrow 4y ago
I am very happy with ASP.NET. But I either use MVC + HTMX or Blazor for the rare cases I also have to do the frontend (which is mostly work done for myself). If other people are doing the Frontend, I don't care what they use. I just show them the data contracts and wish them good luck.

agentultra 4y ago

I personally wouldn'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. Business logic can be handled on the control plane with replication/subscriptions/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. For server-rendered UI I think there'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/streams. I've been meaning to try something like this in Haskell (I've written some foundational libraries to enable this on Postgres [0]) but there are frameworks that do this like Phoenix in Elixir. [0]: https://hackage.haskell.org/package/postgresql-replicant-0.1.0.1 https://hackage.haskell.org/package/postgresql-replicant-0.1...

sparker72678 4y ago
Or you could just use Rails and actually ship a product within the first year of work.
- agentultra 4y ago
  Whatever floats your boat. I can stand up a REST API server with PostgREST and a database in a couple of hours. I can deploy new models with a SQL migration. Like I said, if you want to do server-side rendering it's still a place where Rails/Django/etc shine but I think they could learn a thing or two there to make them better. They could improve so that folks can write/maintain even less code.
DeathArrow 4y ago
>I personally wouldn'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. It depends on the framework. In .NET the only difference between MVC and API is the base class of the controller. You either return JSON or you return a view. Database connections, migrations, routing, serialization, error handling, exception handling, authentication, authorization, Swagger specification, Docker file generation, can be handled by the framework if you so desire. Also, you can mix MVC controllers and API controllers in the same project if you so desire. >For server-rendered UI I think there'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 I find it better to just generate the database from the domain entities using code first approach. It's faster and the ORM will generate proper indexes and also provide optimized SQL queries.

marcosdumay 4y ago

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

louissan 4y ago

An excellent article. As huge Django fan, I could not agree more (so yes, biased :-) ) Since 2015, I've always rendered final HTML server-side, whether that HTML was travelling over a complete http request/response cycle (big page load or XHR or fetch), or over websockets. The only JSON ever involved was stuff similar {"markup":"you html code here"} and a few other more subtle bits to make up for a dumb/blind client. In other words, the client does as it's told by the server. (my client is Azatoth) Opinionated? Yes. Full-of-bad-suprises-after-release-oh-shit-what-did-I-do? No 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/api/whatever. But doesn't do much insuring a certain level of quality, sanity and stability in the long(er) run. my 2pence.

RunawayGalaxy 4y ago

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

sparker72678 4y ago
Go for it, but also admit you’re trying to out-compete a shark. The bar for success in that case is pretty high, and the challenge significant.

tantaman 4y ago

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

viggity 4y ago
Node/Angular are exactly what you get when you disregard Chesterson's Fence.
- popcorncowboy 4y ago
  https://thoughtbot.com/blog/chestertons-fence https://thoughtbot.com/blog/chestertons-fence > There exists in such a case a certain institution or law; let us say, for the sake of simplicity, a fence or gate erected across a road. The more modern type of reformer goes gaily up to it and says, “I don’t see the use of this; let us clear it away.” To which the more intelligent type of reformer will do well to answer: “If you don’t see the use of it, I certainly won’t let you clear it away. Go away and think. Then, when you can come back and tell me that you do see the use of it, I may allow you to destroy it.”

Pandabob 4y ago

I wonder how WASM will change the landscape for these frameworks. If Python had something like Yew [0], I'm not sure I'd be writing React for my Django backend. [0]: https://yew.rs/ https://yew.rs/

elorant 4y ago

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.

metaltyphoon 4y ago
Good thing that you have Razor pages which is insanely easier, and for most projects, good enough.
- elorant 4y ago
  Yeap. Blazor too is promising.
DeathArrow 4y ago
Can you provide an example of unnecessary code you have to write? I assume you are referring to Core based MVC, not the old one.
- elorant 4y ago
  MVC requires me to write at least 50% more code than asp.net. That's what I mean by unnecessary. And I'm referring to the "old" mvc model, I haven't bothered with asp.net core mvc.
  - DeathArrow 4y ago
    >, I haven't bothered with asp.net core mvc. You should try, because now there is almost no difference between MVC and WebAPI. You just have controllers with different base classes.

DeathArrow 4y ago

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/HTMX in one or more MVC microservices.

arendtio 4y ago

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't solve all the use-cases you can solve with with JS frameworks/libraries. 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't fully understood by many people.

oneplane 4y ago
I think you can run MVC applications locally just fine. Instead of shipping electron you'd ship a server runtime, and you'd access the application on localhost instead of in the web view of the electron app. Unless you're talking about PWA, but in theory you'd get MVC PWA apps that do that same (but you're right in that it's an endless cycle of distinctions without a difference in the JS ecosystem).
gcpwnd 4y ago
> And how do I build offline-first web applications with HTML over the wire?!? I can't give you an perfect answer, because I am not aware of a practical example. But I think its quite doable. In a very naive way you can just store the results locally and use them when requested while offline. That potentially increases the storage size of individual items due to the HTML overhead of course. A fairly small app with little offline content could be quite simple. An advanced approach could be to push template parsing to the frontend. HTML fragments could use i.e. micro formats to retrieve data from the HTML and store it for later use. The question in this case how much logic you have to duplicate. I.e. template parsing should be very simple, unless you can share the template engine.
- arendtio 4y ago
  > An advanced approach could be to push template parsing to the frontend. Sounds more like a JS view/vue ;-) Sure, it is possible, but then you are probably better off using a proper JS framework with SSR (server side rendering) support.

mod 4y ago

> 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. When it's needed, fine. But there are so many SPAs that just don't need to be. Rendering HTML server-side is just nice. It's simple and easy to work with. Weird states are unusual. The user gets a really normalized, predictable experience. And done well/quickly, there's little actual difference. Maybe I'm just showing my age. This falls really close to my "I miss the old web" 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/SPA stuff). I don't think I'm going to have any javascript at all. It's really fun and lean. I don't know, it's just got me going lately--reminds me of when I was starting out. My last project is 300 lines of python, 270 lines of php, html/css of course, postgresql, and cron. Some scrapers run, ingest data, and the php sorts and displays it.

moonchrome 4y ago
In my experience server side rendering becomes really messy once you hit complex state management. Shuffling shit between pages, persistent vs transient state, handling reload/resubmit logic, validation. It works for simple stuff but even then I think once SPA tech matures more (ironically even after all this time I think transpilers/bundlers/package managers in JS still have a long way to go to get out of the way and frameworks are still far from optimal) anything that's not a web page should handle UI logic on the front-end.
- zippercreatemy 4y ago
  WHAT??? Okay I am going to bite, state is managed by the browser and then SPAs came along and tried to hack the state management ever since. I remember creating SPAs in 2004 when it was called AJAX and there was the debate of HTML or JSON over the wire. The biggest issue was back and forward buttons, even today that issue is not solved very well by SPAs. The issue I have is we had a great idea to refresh parts of a page with AJAX and then we went overboard and tried to move the entire application to complex frameworks which add more problems then they solve. We became so scared of screen rendering we avoided at all costs. This is bad UX as users actually get good confirmation that something has happened when there is a screen refresh.

specialist 4y ago

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

cultofmetatron 4y ago

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

vereis 4y ago
Guaranteeing a singleton process is a very difficult problem which horde definitely does not solve perfectly mind you. All is well and good until it isn't. We opted for leveraging different mix release permutations deployed on k8s as needed instead. Definitely takes more effort than what you describe, and has its own issues... But imo definitely better understood than fighting weird state with horde
spion 4y ago
Elixir (and Phoenix) are truly amazing. I only wish there was a typesystem / spec system better (stricter) than Dialyzer. Or perhaps I am doing something wrong but I couldn't get it to be as strict - if there is a way i'd love for `credo` to force me to adhere to it.
- cultofmetatron 4y ago
  its unfortunate that elixir's type system isn't too strict. That said, if you want somethign stricter, there is gleam (https://gleam.run/ https://gleam.run/) which has interop with elixir. I haven't tried it myself yet but you could probably embed a service in gleam for specific cases where you need the stricter type checking.

deleted 4y ago

[deleted]

CraigJPerry 4y ago

I played through this short guide a week or so ago: https://codelabs.developers.google.com/create-an-instant-and-seamless-web-app https://codelabs.developers.google.com/create-an-instant-and... Add SPA performance to a multi page app thanks to guided pre-rendering. I came away from it thinking that's one less benefit an SPA holds over MPA now.

engineeringwoke 4y ago

> 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. RDBM is optimized for file size; it is very much an artifact of its time, when hard drive space was limited. I don't buy it for a second. People think in dictionaries, so just use one. If you are making a simple app and don'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 every use case when they are absolutely not needed. 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 "engineery" to do it. I don't know how many young startups I'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.

DeathArrow 4y ago
If the data is highly relational, no JSON structure and data duplication will save you from joins. You will either do them at database level or in memory. I see a need for relational databases, NoSQL, data lakes and all other storage strategies. You chose based on the type of data, the way you acquire it, the way you process and deliver it, based on security and reliability needs. In many non trivial application there is more than one data storage solution implied. Since I work with large microservice based apps, it's a long time since I have to use more than one data storage strategy in the same app.
- engineeringwoke 4y ago
  Agreed on all points. I still think RDBM is over-used; it's the default in many shops for any minor micro-service. It's like using a 20-piece multi-tool for something that only needs a regular kitchen knife.

awill88 4y ago

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. 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/late stage company. 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.