[nullwasamistake]

Eh, no. The whole MVC pattern is obsolete and every web project I've worked on less than 5 years old is a SPA. It's gone the way of PHP. It will always be around in legacy stuff but hardly anyone is building new project with it.

[bdcravens]

What are you using for the backend? A SPA has no value without one. Unless you're using something like Firebase, pretty good chance your backend is an MVC app. (I think you're confusing server-rendered apps with the MVC pattern)

[zawerf]

If you're using graphql for the backend, is it still MVC?

Even if you can stretch the definition to fit, is it still useful to organize your code along those terms instead of what's natural in the new ecosystem? (data source resolvers, type schemas, queries/mutations)

[nullwasamistake]

Eh I guess I meant "traditional" web MVC where HTML template for the whole page is pre-rendered on the server.

We use gRPC web, so backend is a bunch of RPC endpoints. Front end is regular SPA.

This has worked great for us because it reduces backend to "shipping objects" instead of all the bs you normally have to deal with in HTTP.

With gRPC there's no use for rails, or any HTTP server framework. As far as I can tell, this is the future of web endpoints, so rails will die out.

[_bxg1]

MVC is way bigger than "server-rendered websites". It applies to anything with an interface - native apps, SPAs. Arguably even services that don't have GUIs. It's a method of separating concerns that has remained remarkably popular through many different technology cycles. You're saying a lot of words but I don't think you know what they mean.

[bobjordan]

Right on. My concept of MVC just helps guide me on how I’m going to go about building some particular web functionality, irregardless of whether or not the end result is more or less SPA in nature or not. Some parts of my app are nearly completely Ajax driven and server side rendered, other parts are just static web pages. The model means, what classes or methods do I need to build to store the data/state. The view means how am I going to present the to the client side, with a mix of html/template engine working with a backend view class/methods. The controller is how am I going to network the model with the view, and that is generally with forms and other supporting logic. The level of people on this thread that are talking very confidently about things with which they are clearly novices, is pretty shocking. I haven’t seen such a thread on HN in a long time. I’m a python guy using Flask, but congrats to the Rails users and thanks to the developers for continuing to drive it! You’ve made the web a better place.

[drspacemonkey]

Assuming your API follows REST, I find the MVC pattern to be immensely helpful. Even if the "V" part is just an object serializer, it's still a great pattern.

[freehunter]

And this is why every website now has a loading screen in front of it.

[sergiotapia]

That's stupid implementation. You can _easily_ build static websites that load near instantly and are tiny. Also if you choose to shut off javascript that's your choice, but don't complain the web does not work.

[mtbcoder]

MVC has been around since the 70s and is one of the most formative design patterns. Hardly obsolete.

[paublyrne]

You can very easily eschew the V and run your spa against a Rails API.

[bdcravens]

Strictly speaking, the V is still there. The View doesn't have to render HTML; it's still there, rendering JSON, in a Rails API.

You can even build an SPA using the MVC pattern. I think nullwasamistake's comment was misusing buzzwords, and they were rather comparing server-rendered apps vs client-side SPAs.