4 ms·
Nice article! I think it hits a lot of the philosophy behind rich JS Apps. Taking some key points from it: * Do not store state in the DOM. You'll live to regr
by jashkenas 16y ago
Nice article! I think it hits a lot of the philosophy behind rich JS Apps. Taking some key points from it:
* Do not store state in the DOM. You'll live to regret it when you need to represent the same model in more than one place at once, or refactor your UI.
* Events are the way to go, when connecting changes in the model to updates in the view. Ideally, models know nothing about what UI happens to be on the screen at any given moment.
* If you're going to be doing interesting business logic in the client, it helps to have collections (in this case, Backbone.Collection) with a richer API than JS arrays: filter, any, map, reduce, reject, include, invoke...
* Lots of little testable JS files for development, one minified gzipped file for production.
The one point I'm in disagreement with is: "Keep your models as simple as possible". In my opinion, client-side models really shine when they contain a large part of your important JS business logic, and you can use the same models in different situations to provide access-control, URL generation, data munging, etc.
For example, here's a list of some of the methods we have on a Backbone.Model called "Document": viewerUrl, publishedUrl, canonicalId, openViewer, openText, openPdf, allowedToEdit(account), checkAllowedToEdit(account, message), checkBusy, notes, uniqueEntities, isPending, isPublic, isPublished.
- CrabDude 16y agoThe fat Model vs fat Controller argument has raged since the days when dinosaurs ruled the seas and monkeys hadn't yet learned to fly. I myself am a fat-controller proponent, however, I find myself in development really needing something more like a MVCRouter solution where the router acts like what fat-Modelists would consider a controller and the controller subsumes the inter-object business logic often found in fat controllers.
- catshirt 16y agowhat is the best way to handle not storing state on DOM, when you need to maintain javascriptless functionality, and your data is loaded from the server pre-render? currently using data attributes to solve this. which means our state is in DOM anyway.
- jashkenas 16y agoI'd think it'd be a little nicer to bootstrap in the data as JSON objects -- so that you don't have to scrape your own data out of the HTML... But really, if you have to maintain JavaScript-less functionality for a web site (not a web app), that's a fine way to do it. Pull all of your data out of the data attributes once at load time, and you're off to the races.
- catshirt 16y agothanks! good to know it's not atypical... it naturally doesn't "feel right". this functionality is one of the only things that has kept my code from evolving into nearly backbone. felt like maybe I was missing a piece of the puzzle. considering that... backbone is not exactly what I need, but it is definitely inspiring for refining my own solutions (which again, are drawn from similar conclusions).
- HenrikJoreteg 16y agoThanks for your input. As you probably realized, my post was more about a strategy for apps that feel more like desktop apps, where once you're logged in, you're not really moving around from page to page at all. In my case it was a chat app where the whole app was useless without JS. It's an interesting thought, though. However, I don't know if I'd see the need for something like backbone on any site where I was trying to support non-js browsers.
- simonw 16y agoI can understand why storing state on the DOM would quickly start to suck if you're building a single-page application, but I've found it works really well for applications that work without JavaScript using progressive enhancement.
- HenrikJoreteg 16y agoTrue, what I'm talking about in my post is definitely a different paradigm than a more traditional web site where one of the goals is to make it widely accessible for any and all users/devices. ps. thanks for reading my post simon, u da man!
- jashkenas 16y agoWe're in agreement there -- the DOM is a nice place (technically the only place) to store state for light JS enhancement of web sites, but I think we're going to see a larger gap grow between those and web apps.
- HenrikJoreteg 16y agoJeremy, first of all. Thanks for Backbone! You guys rock. I'm glad you liked my post. Regarding "keeping models simple". Perhaps I wasn't so clear. My point here was mainly just that when I first started trying to build a model layer separate from the DOM (pre-backbone). I was very explicitly defining what attributes each model has and then also doing the corresponding DOM manipulations in my setters and getters. That got messy pretty quickly. So, my point was not that you shouldn't add methods to your Backbone.Model's, but rather that you should keep view and controller logic out of your model layer.
- jashkenas 16y agoAh, great -- we agree then after all. Models contain sophisticated domain logic, but know nothing about HTML or DOM manipulation. Perhaps that point could be expanded with a bit more nuance at the end of article.