Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

If you look closely in the original smalltalk definitions you'll also see that separation of view and controller was intended first and foremost as a way to swap multiple views for the same controller, assuming those views shared controls and interaction patterns. This may have made sense in the context it was designed in : rendering was closer to raw painting on a canvas, mixing event handling with painting code would probably have been ugly. In my opinion it makes much less sense in a browser where the rendering layer is almost entirely in the runtime and building UIs is pretty trivial. We all feel something is wrong because, well, something very is wrong with MVC in the client. Where to we "render" ? To the DOM. Where do user interactions come from ? From the DOM, through events. We already have the controller-view part, and it's the DOM. Everything we are doing, stated or not, is adding layers on top of it to make things simpler to manage. Glorified helpers.

Same goes for the model. If you don't like to duplicate information for the sake of it, it's pretty straightforward to note that models on the client should be ... well, are a glorified caching mechanism. All these MV* models are in my opinion strongly hindering creativity and progress.

In this respect, I think React is onto something big.



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: