4 ms·

Good question. I haven't used backbone at all, and only know what I've read about it. Flux is a complete replacement for backbone as far as I can tell. As you

Good question. I haven't used backbone at all, and only know what I've read about it. Flux is a complete replacement for backbone as far as I can tell. As you say, the models live in stores, so building on my other comment, you would have an ArticleStore that is responsible for providing access to and caching all of the Article objects. As a rule, if you want to mutate data, you do so by calling an action (ArticleActions.update, for example). See my other comment for how the update flow works: https://news.ycombinator.com/item?id=7721381 https://news.ycombinator.com/item?id=7721381 If you want to fetch data, you go to the store (ArticleStore.getByID, or ArticleStore.query). The ArticleStore will then call into the ArticleDAO (data access abstraction) to fetch data asynchronously, and when it returns the ArticleStore incorporates the data into its cache and "informs", which is basically a pub-sub push (the views/components subscribe to the stores they want to get data from).

riquito 12y ago
> I haven't used backbone at all, and only know what I've read about it I find it mind-blowing: do you only use tools made inside Facebook? Do you develop these frameworks or just use them? If you don't know Backbone which frameworks did you learn of this kind? I'm curious.
- e1g 12y ago
  I am another a developer that has never used Backbone (until couple months ago at least). Someone could assume that is because I develop trivial apps, but in reality the opposite is true. Tools such as jQuery and Backbone seem ubiquitous on the web because they are a perfect fit for addressing common problems in the webpage/ajax/dynamic content area. However, there is a sizeable group of developers who work with rich applications, intranet portals, line-of-business apps that required significantly more structure and skeleton than Backbone/Marionette provide. This importance of using an overarching "framework" rather than a "library" increases in proportion to the team size and the code surface area. In my case, we started with YUI and then migrated to ExtJS. This was before Backbone existed, although it would not have made a difference. In recent years we have evaluated Angular and Ember but did not find compelling reasons to migrate (for a greenfield project the choice may be different, but migrating significant apps carries a significant cost). Both YIU and ExtJS provided everything we needed under one roof, and there was no use for jQuery or Backbone&co. The downsize of a mega-framework like ExtJS is the overhead - it is ill suited for a simple app. Couple months ago I started using Backbone & co for small isolated mini-apps, but I cannot wait to find a suitable replacement because it feels clumsy and backwards. To be clear, I am not saying it is impossible to build complex apps primarily driven by Backbone - I know people who have done that (often to their own peril). I am saying that it is entirely possible to be a Facebook-level engineer working on complex applications and have zero experience with Backbone as it is great and solving problems you do not have.
  - noir_lord 12y ago
    I'm developing a SaaS application that is essentially a LoB in wolf's clothing and I went with Knockout for much the same reason, I'm not a strong javascript programmer but I rapidly realised if I stuck with just jQuery I was going to be in maintenance hell. I've really enjoyed working with knockout (so much so I've even written "components" with it (ajax file handler a la gmails but with previews etc) and I've found it to have just enough structure for the stuff I need on the front side. It surprises me that it's not more popular than it is but maybe there are reasons for that I simply don't know or understand.
- girvo 12y ago
  I've used Angular extensively, React and Spine.js, but I never used Backbone either. It's got nothing to do with where someone works, as far as I'm aware; I certainly don't work at Facebook, anyway.
- wingspan 12y ago
  I didn't develop React, I just use it at Facebook. I started Javascript development at Microsoft where we were using mostly our own homegrown stack on www.so.cl. When I moved to Facebook, the entire project I'm working on is in React. Since I haven't built many single page apps in my spare time, I have had very little exposure to Backbone. Rest assured the React devs certainly are familiar with most of the Javascript frameworks out there ;)
jmreidy 12y ago
Is there a reason why data fetches (e.g. ArticleStore.getByID) don't just return a promise for the return data? I'm guessing the current implementation doesn't return anything, it just emits an event for informing data loaded. The one plus of the event approach I can think of is that if one component causes new data to load on the client (an article is updated), none of the components that rely on that article will show stale data - that is to say, it's extraordinarily difficult for components looking at the same data to ever be out of sync.

riquito 12y ago

> I haven't used backbone at all, and only know what I've read about it I find it mind-blowing: do you only use tools made inside Facebook? Do you develop these frameworks or just use them? If you don't know Backbone which frameworks did you learn of this kind? I'm curious.

e1g 12y ago
I am another a developer that has never used Backbone (until couple months ago at least). Someone could assume that is because I develop trivial apps, but in reality the opposite is true. Tools such as jQuery and Backbone seem ubiquitous on the web because they are a perfect fit for addressing common problems in the webpage/ajax/dynamic content area. However, there is a sizeable group of developers who work with rich applications, intranet portals, line-of-business apps that required significantly more structure and skeleton than Backbone/Marionette provide. This importance of using an overarching "framework" rather than a "library" increases in proportion to the team size and the code surface area. In my case, we started with YUI and then migrated to ExtJS. This was before Backbone existed, although it would not have made a difference. In recent years we have evaluated Angular and Ember but did not find compelling reasons to migrate (for a greenfield project the choice may be different, but migrating significant apps carries a significant cost). Both YIU and ExtJS provided everything we needed under one roof, and there was no use for jQuery or Backbone&co. The downsize of a mega-framework like ExtJS is the overhead - it is ill suited for a simple app. Couple months ago I started using Backbone & co for small isolated mini-apps, but I cannot wait to find a suitable replacement because it feels clumsy and backwards. To be clear, I am not saying it is impossible to build complex apps primarily driven by Backbone - I know people who have done that (often to their own peril). I am saying that it is entirely possible to be a Facebook-level engineer working on complex applications and have zero experience with Backbone as it is great and solving problems you do not have.
- noir_lord 12y ago
  I'm developing a SaaS application that is essentially a LoB in wolf's clothing and I went with Knockout for much the same reason, I'm not a strong javascript programmer but I rapidly realised if I stuck with just jQuery I was going to be in maintenance hell. I've really enjoyed working with knockout (so much so I've even written "components" with it (ajax file handler a la gmails but with previews etc) and I've found it to have just enough structure for the stuff I need on the front side. It surprises me that it's not more popular than it is but maybe there are reasons for that I simply don't know or understand.
girvo 12y ago
I've used Angular extensively, React and Spine.js, but I never used Backbone either. It's got nothing to do with where someone works, as far as I'm aware; I certainly don't work at Facebook, anyway.
wingspan 12y ago
I didn't develop React, I just use it at Facebook. I started Javascript development at Microsoft where we were using mostly our own homegrown stack on www.so.cl. When I moved to Facebook, the entire project I'm working on is in React. Since I haven't built many single page apps in my spare time, I have had very little exposure to Backbone. Rest assured the React devs certainly are familiar with most of the Javascript frameworks out there ;)

jmreidy 12y ago

Is there a reason why data fetches (e.g. ArticleStore.getByID) don't just return a promise for the return data? I'm guessing the current implementation doesn't return anything, it just emits an event for informing data loaded. The one plus of the event approach I can think of is that if one component causes new data to load on the client (an article is updated), none of the components that rely on that article will show stale data - that is to say, it's extraordinarily difficult for components looking at the same data to ever be out of sync.