Hacker News new | ask | show | jobs
by qaexl 5374 days ago
Agreed. I can't find any insight or advantage in making this kind of a distinction.

The article attempts to address it by saying that people attempt to implement Model2 on a Javascript front-end. That is awkward. However, it isn't awkward because you should be using real MVC. It is awkward because Javascript is asynchronous and you want to make sure the user interaction stays responsive without devolving into spaghetti. The key insight is "asynchronous" rather than "let's do REAL MVC!"

I've seen this obsessive focus on taxonomy of solutions divorced from specific problems in domains outside computing. I suspect it's a cultural thing. Some cultures obsess over gadgets more than others. That works out until people start arguing about who has the shinier toy, instead of actually using said toys as tools.

2 comments

> It is awkward because Javascript is asynchronous and you want to make sure the user interaction stays responsive without devolving into spaghetti.

This is exactly the feeling I've been getting recently as I foray into writing my first Chrome extension. The asynchronous nature of XHR is ending up making my code a little more spaghetti-like that I would prefer. Would you happen to have any recommended resources for possible approaches to addressing this issue?

So could one call Rails a sort of "synchronous MVC" and javascript MVC "asynchronous MVC"?
Hmm. Maybe? Seems impoverished to me.

Someone on the comments for the original article said, the big idea in Rails wasn't so much MVC as much as separation of concerns. I'm on-board with that. Thinking in that way has brought a lot of advantages for me over the years I've been working with Rails.

By extension, if the big idea is "separation of concerns", then I should be applying it in my non-Rails code too, whether that's "MVC" or not "MVC". In fact, my small taste of functional programming allowed me to play with "separation of concerns" in a different coding style, one that I've imported back into the Ruby code I write. Write functions without side-effects. Treat data as immutable. Interesting times.