Hacker News Reader

Comment by peter_l_downs | Hacker News Reader

Are there any MOVE frameworks yet? I very much like the idea, but one of my favorite tests for "correctness" in a program is to use it to build something. Although it could be (and probably is) a reflection on my lack of knowledge, I find myself "fighting" with MVC frameworks like backbone whenever I try to use them. I would love to see if MOVE would be any better.

View on HN

MVC may not be a solid pattern for a client side framework. It makes sense to contain some semblance of state with in the presentation layer on the client side, rather than working with a stateless MVC pattern.

http://www.martinfowler.com/eaaDev/uiArchs.html MVP via M. Fowler seems a little closer to what client side should feel like (imho).

http://en.wikipedia.org/wiki/Model_View_ViewModel MVVM also makes sense for a client side app, which is just an extension of MVP.

IMO MVC on the client side is just a carry over from people who were experienced in writing web apps who wanted something that felt familiar on the client side. It's a leaky abstraction at best.

I agree with this. I'm not particularly interested in client-side MVC frameworks because it wrongly trivializes the server component, and technically speaking any javascript running on the client is part of the view.

I'm not sure what the right answer is, but I certainly feel like the race for rich client-side apps had too many frameworks settle on MVC without thinking about the bigger picture.

"Are there any MOVE frameworks yet? "

I don't think so, but I feel that Grails may be the closest thing currently. It has a concept of a Service construct that feels like an Operation. Then again I could be completely wrong.

I feel like you could still accomplish this with existing frameworks, though it'll be a bit of a hack. Perhaps split the controller in half, for instance LoginOperations and LoginEvents

I think Express may be freeform enough to implement an app in this manner.

I think the problem with most MVC frameworks is not the framework themselves, but that that the MVC design pattern should only be considered while refactoring existing working code. Starting right off the bat with a giant MVC boilerplate isn't necessary and may even be counter-productive.

I write my code initially as one monolithic controller, and then refactor my code into an MVC pattern. It doesn't take that long to move functions from one object an other, and now you're working with an already-functioning piece of code rather than guessing how things might work later on.

So this could be the part where I'm not that great a programmer, but the I've had trouble creating apps from scratch with MVC, not just refactoring existing code.

MVC didn't really click for me until I wrote a non-trivial web application in PHP without it.

Reply on news.ycombinator.com