6 ms·

JavaScript MVC

59 points by naish 17y ago

olegp 17y ago
Also worth taking a look at json-template: http://code.google.com/p/json-template/ http://code.google.com/p/json-template/
- mnemonik 17y ago
  Allow me to take this opportunity to shamelessly plug my jQuery templating plugin: http://plugins.jquery.com/project/tempest http://plugins.jquery.com/project/tempest It is designed to do a lot less than other JS templating engines. The goal is to force the separation of programming logic and HTML markup.
- judofyr 17y ago
  Here's the discussion when it was released: http://news.ycombinator.com/item?id=538389 http://news.ycombinator.com/item?id=538389
jerf 17y ago
Pure MVC isn't possible for most Javascript apps, because the Model lives on the server. Now we're talking something like MMVC (Model-server, model-client, view, controller). Oh, and the controller isn't just controlling the view, it eventually has to feedback to the actual server model, so it's more like MMVCC. Oh, and if you want the page to load concrete HTML for the initial view of the data (for speed, since dynamically constructing it client side may be slow), then we've got MMVVCC. Now, I know some sites don't have that last one, but MMVCC is pretty common. Now that following MMVVCC has mucked up your code beyond belief, maybe you should reconsider whether it actually bought you anything. Upshot: The MVC abstraction just doesn't make sense in this context. It cuts the wrong way for a client-server application, and if you're just forcing your code into MVC's structure because there's this dogma floating around that it's a good idea... don't do that! There are far better ways to structure your JS. In fact, almost anything is a better way to structure your JS.
- sfphotoarts 17y ago
  no, MVC is perfectly possible. Think of the server model as the persistence layer then it will become clear to you.
  - known 17y ago
    bingo
- 9oliYQjP 17y ago
  I can see your point and certainly I've seen code as you have described. However, just because the model lives on a server doesn't mean that you can't have a model class on the client. If that were true, then we would not be able to have model classes tied to databases. But that's fairly common, even if it does add a level of abstraction. The big mistake that folks make is not that they use MVC on the client but that they use MVC on the server side in this scenario. You'd get better bang for your buck if you used MVC on the client and accessed RESTful resources via a model class, and treated the server like a filesystem for loading controller and view classes that were handled exclusively by the client.
- mjw 17y ago
  Genuinely interested here in what you'd propose as an alternative. Separating model logic from presentational logic helps me a lot in client side code. Then the 'two models' problem seems inescapable if you want to divide the load of model-level computation between client and server. Sure, if you do all the non-trivial computation server-side, then the client-side model becomes less important. But sometimes you need to do more complex computation in the client, whether for UI latency or scalability reasons. If you didn't, you'd just be writing a traditional server-side web app (which of course is fine, but not what we're talking about). On the other hand, if you do most of the computation client-side, the server-side can be a relatively trivial persistence layer, and sometimes that works out really well. But even if all you're doing is calling on a persistence layer, it can still require a fair bit of bookkeeping logic in your client-side model code. versioning, caching and cache expiry, object identity, managing consistency of local copies of denormalised data etc. As for 'two controllers', I'm not sure I get what you mean there. In most verisons of MVC I've seen, the controller talks to both model and view, not just the view. But it is a poorly-defined term. Personally I prefer an approach something like "M + Tree(V + C)". That is, a model layer, and then a tree of 'widgets' or user-interface components, each of which has its own controller and view logic. Widgets may create and manage child widgets. etc. Finding this works quite well, especially when you throw data-binding into the mix too. Agree that the 'VV' approach you describe sounds quite a crazy optimisation, depending on how far you take it. Although might make more sense if you have more of a unified development environment between client and server eg GWT or a javascript-based server framework.
mgreenbe 17y ago
MVC never made a great deal of sense to me, in that I've never really seen a system that entirely embodies what's described. Nevertheless, programming Javascript is tough because it's easy to confuse the DOM---the view---with the client-side model. When updates can come from the server or the view, maintaining the client side model is quite difficult. Plug: Flapjax <http://flapjax-lang.org/&#62 http://flapjax-lang.org/> helps with this a bit. My own thesis work used Flapjax to prototype an even more robust system.
smithjchris 17y ago
We built something akin to .Net web forms for jQuery. Works a treat. Basically there is a chunk of HTML up front and a chunk of javascript behind each control. The server composits all of these chunks onto the output stream and out comes an application.
hendler 17y ago
Many design patterns work perfectly well in Javascript. In web architectures, there is a practical problem with where logic lives, where the data lives, and what generates the "view". It's a non trivial architectural problem, but it's not impossible by any means. The computer science and software is completely capable. I guess this is tangential to the debate about if Javascript is _good_ for MVC. If code is executed on both the server and the browser there probably needs to be a clean separation of responsibility or code generation. Otherwise - Google gears and chrome OS can certainly make the entire app live completely client side (and in MVC/ JS).

59 points by naish 17y ago

olegp 17y ago

Also worth taking a look at json-template: http://code.google.com/p/json-template/ http://code.google.com/p/json-template/

mnemonik 17y ago
Allow me to take this opportunity to shamelessly plug my jQuery templating plugin: http://plugins.jquery.com/project/tempest http://plugins.jquery.com/project/tempest It is designed to do a lot less than other JS templating engines. The goal is to force the separation of programming logic and HTML markup.
judofyr 17y ago
Here's the discussion when it was released: http://news.ycombinator.com/item?id=538389 http://news.ycombinator.com/item?id=538389

jerf 17y ago

Pure MVC isn't possible for most Javascript apps, because the Model lives on the server. Now we're talking something like MMVC (Model-server, model-client, view, controller). Oh, and the controller isn't just controlling the view, it eventually has to feedback to the actual server model, so it's more like MMVCC. Oh, and if you want the page to load concrete HTML for the initial view of the data (for speed, since dynamically constructing it client side may be slow), then we've got MMVVCC. Now, I know some sites don't have that last one, but MMVCC is pretty common. Now that following MMVVCC has mucked up your code beyond belief, maybe you should reconsider whether it actually bought you anything. Upshot: The MVC abstraction just doesn't make sense in this context. It cuts the wrong way for a client-server application, and if you're just forcing your code into MVC's structure because there's this dogma floating around that it's a good idea... don't do that! There are far better ways to structure your JS. In fact, almost anything is a better way to structure your JS.

sfphotoarts 17y ago
no, MVC is perfectly possible. Think of the server model as the persistence layer then it will become clear to you.
- known 17y ago
  bingo
9oliYQjP 17y ago
I can see your point and certainly I've seen code as you have described. However, just because the model lives on a server doesn't mean that you can't have a model class on the client. If that were true, then we would not be able to have model classes tied to databases. But that's fairly common, even if it does add a level of abstraction. The big mistake that folks make is not that they use MVC on the client but that they use MVC on the server side in this scenario. You'd get better bang for your buck if you used MVC on the client and accessed RESTful resources via a model class, and treated the server like a filesystem for loading controller and view classes that were handled exclusively by the client.
mjw 17y ago
Genuinely interested here in what you'd propose as an alternative. Separating model logic from presentational logic helps me a lot in client side code. Then the 'two models' problem seems inescapable if you want to divide the load of model-level computation between client and server. Sure, if you do all the non-trivial computation server-side, then the client-side model becomes less important. But sometimes you need to do more complex computation in the client, whether for UI latency or scalability reasons. If you didn't, you'd just be writing a traditional server-side web app (which of course is fine, but not what we're talking about). On the other hand, if you do most of the computation client-side, the server-side can be a relatively trivial persistence layer, and sometimes that works out really well. But even if all you're doing is calling on a persistence layer, it can still require a fair bit of bookkeeping logic in your client-side model code. versioning, caching and cache expiry, object identity, managing consistency of local copies of denormalised data etc. As for 'two controllers', I'm not sure I get what you mean there. In most verisons of MVC I've seen, the controller talks to both model and view, not just the view. But it is a poorly-defined term. Personally I prefer an approach something like "M + Tree(V + C)". That is, a model layer, and then a tree of 'widgets' or user-interface components, each of which has its own controller and view logic. Widgets may create and manage child widgets. etc. Finding this works quite well, especially when you throw data-binding into the mix too. Agree that the 'VV' approach you describe sounds quite a crazy optimisation, depending on how far you take it. Although might make more sense if you have more of a unified development environment between client and server eg GWT or a javascript-based server framework.

mgreenbe 17y ago

MVC never made a great deal of sense to me, in that I've never really seen a system that entirely embodies what's described. Nevertheless, programming Javascript is tough because it's easy to confuse the DOM---the view---with the client-side model. When updates can come from the server or the view, maintaining the client side model is quite difficult. Plug: Flapjax <http://flapjax-lang.org/&#62 http://flapjax-lang.org/> helps with this a bit. My own thesis work used Flapjax to prototype an even more robust system.

smithjchris 17y ago

We built something akin to .Net web forms for jQuery. Works a treat. Basically there is a chunk of HTML up front and a chunk of javascript behind each control. The server composits all of these chunks onto the output stream and out comes an application.

hendler 17y ago

Many design patterns work perfectly well in Javascript. In web architectures, there is a practical problem with where logic lives, where the data lives, and what generates the "view". It's a non trivial architectural problem, but it's not impossible by any means. The computer science and software is completely capable. I guess this is tangential to the debate about if Javascript is _good_ for MVC. If code is executed on both the server and the browser there probably needs to be a clean separation of responsibility or code generation. Otherwise - Google gears and chrome OS can certainly make the entire app live completely client side (and in MVC/ JS).