Hacker News Reader

Comment by sspross | Hacker News Reader

no offense, but I am the only one who thinks this MVC style isn't an option anymore after things like react?

Er, adding an option doesn't delete all the other options.

MVC is a decades old, tried and tested pattern for building user interfaces. Whatever its merits, I suspect it will survive react.

This is not a critique of MVC, but rather the particular implementation that Backbone provides. With React you still have your models (and controllers).

And adding a new option may make an existing one obsolete. Remember ES3? I do, but I wouldn't want to write new code in it. Once new options were added (ES5, and then ES6), they made the old one obsolete. It desn't mean you can't use the old options, but why would you if the new ones are superior?

I missed the word 'this' in the GP, so this is fair enough.

Even if we're just talking about Backbone, however, it's a little off: I mean, people use react with the non-view parts of Backbone. Often you're going to need some way to talk to APIs (say), and Backbone gives you a cheap and well-known solution for that. I'm no Backbone fanboy, but significant things have been achieved with it, and they are not now suddenly impossible because there's a new view layer on the scene.

Is the ES3 vs. ES5/ES6 comparison valid? The latter were subsequent versions of the former, kind of like Angular 2 vs Angular 1. Whereas Backbone, Ember, React, etc. are all different, each with its own "way" of doing things.

I used ES5/6 because those are (I hope) in the eyes of the HN community clear improvements over ES3. I personally wouldn't use ES5/6 nowadays, and instead use TypeScript or PureScript. Both of which are IMO even bigger improvements. Backwards compatibility does not matter in this comparison, what matters is the relative ordering: Backbone.View < React, ES3 < ES5 < ES6, and IMO: ESx < TypeScript/PureScript.

Well, "things like react" are not more than the V in your MVC ;)

Sure, but it suggests a component hierarchy which blurs the already ambiguous line between view and controller. Which is why there's flux and all of its variants, and things like falcor in the works - the missing model in data-component architecture.

On the ambiguous line between view and controller: a piece of code belongs to the controller when it touch the model, and to the view when it touch the DOM, the corollary being "don't write code that touch both the controller and the model". Put that way it doesn't seems that ambiguous.

The fact that react suggests you organize the views in a component's hierarchy has nothing to do, imho, with people calling the models from those components. It's just bad practices, whatever is the view library being used.

But I get your point nonetheless: flux & all do try to make it clearer that react should only get called from events and update the DOM as a consequence.

For the record, there's also good things being done in that field by the clojurescript community (Om/Reagent for example).

this book is old. It was written before React. I even do not understand why it is so high voted here. But many thanks for Addy writing it and making it open!!!

You're not alone. Use Vieux architecture instead: Vieux.io :)

Reply on news.ycombinator.com