by j4mie on 5/9/22, 1:43 PM with 248 comments
by mod on 5/9/22, 7:03 PM
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.
by recursivedoubts on 5/9/22, 4:14 PM
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!
by antris on 5/9/22, 3:59 PM
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.
by cultofmetatron on 5/9/22, 7:07 PM
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.
by ChrisMarshallNY on 5/9/22, 3:42 PM
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.
by dismantlethesun on 5/9/22, 2:42 PM
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.
by hu3 on 5/9/22, 2:57 PM
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.
by ARandumGuy on 5/9/22, 4:32 PM
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.
by duxup on 5/9/22, 4:12 PM
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)
by louissan on 5/9/22, 5:01 PM
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.
by marcosdumay on 5/9/22, 4:42 PM
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.
by agentultra on 5/9/22, 4:39 PM
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...
by nassimsoftware on 5/9/22, 3:49 PM
I think there is AdonisJS : https://adonisjs.com/ which could be the Rails / Django equivalent you're looking for.
by gilbetron on 5/9/22, 2:54 PM
2) Dinosaurs are still around in the form of birds and have found amazing utility, so even the analogy lacks nuance ;)
by awill88 on 5/10/22, 7:31 AM
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.
by lexx on 5/9/22, 3:17 PM
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.
by SantiagoElf on 5/9/22, 4:39 PM
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.
by eatonphil on 5/9/22, 2:50 PM
by DeathArrow on 5/9/22, 6:43 PM
by arendtio on 5/9/22, 6:54 PM
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.
by andix on 5/9/22, 4:20 PM
But I don’t really see why you need a MVC framework for doing MVC.
by RunawayGalaxy on 5/9/22, 5:36 PM
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?
by stevebmark on 5/9/22, 3:56 PM
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.
by CraigJPerry on 5/9/22, 7:39 PM
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.
by specialist on 5/9/22, 7:04 PM
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.
by tantaman on 5/9/22, 5:49 PM
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.
by projektfu on 5/9/22, 4:01 PM
by Pandabob on 5/9/22, 6:25 PM
[0]: https://yew.rs/
by ape4 on 5/9/22, 4:30 PM
by cosmiccatnap on 5/9/22, 2:40 PM
by SantiagoElf on 5/9/22, 6:04 PM
Then maybe just maybe, you will all have more time to work and become millionaires, just saying.
by elorant on 5/9/22, 6:41 PM
by TameAntelope on 5/9/22, 3:31 PM
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?
by engineeringwoke on 5/9/22, 7:50 PM
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.