4 ms·

I feel this way about backbone as well. Before using backbone, I wrote complex user interfaces in Javascript/JQuery. They were a mess. Backbone allowed me to w

I feel this way about backbone as well. Before using backbone, I wrote complex user interfaces in Javascript/JQuery. They were a mess. Backbone allowed me to write cleaner code without forcing me to do anything. I still use backbone today. The code tends to be very verbose, but the trade-off is that it is not heavy handed. I never have to "hack" around backbone, it just gets out of my way when I want it to. This fits my personal preferences, I prefer simple, verbose code. I also tend to prefer lower-level to high level. For example, I don't like ORMs. For me, it is easier to explicitly express how I want the data to be indexed and move in and out of a database as opposed to have an ORM manage it for me... because if it doesn't do it right, its very difficult for me to learn how to get the ORM to do what I want it to do. I also prefer more keystrokes and fewer "things to have to know about" to fewer keystrokes with many things going on behind the scenes that I cannot see. I think I may be in the minority in this respect? I understand that there may be better frameworks now, but I feel I need to commit to something and stick with it, I think the cost of re-writing things all the time is too high. I think its faster in the long run to use an old framework that's 50% slower than switch to a better framework every two years. For reference, this is the main project I use backbone on: https://demo.enterprisejazz.com/ https://demo.enterprisejazz.com/

bikamonki 10y ago
>I think the cost of re-writing things all the time is too high. Exactly. So, unless it stops running on modern browsers, the code should continue to execute and provide a complete solution. Although, I do try to keep Backbone versions up to date. I also plan to continue using Backbone but I do want to learn a 'view' tool to improve performance of UI-rich apps. React seems too big and complicated, I am more inclined towards vue.js or mithril.js. I checked your demo, in case you have not done so already here are 3 tweaks I've done to make Backbone run faster: - Select el already on DOM for a view's el instead of render/append. This is a huge performance improvement. - For big collections use plain JS array instead of Backbone native collection. You'll trade some methods for performance, but such methods can be re-implemented with Underscore. - Ditch the router if you need dynamic routes. Here's an experiment of a classic listings app. After selecting a city, 5000 random listings are loaded at once into a JS array, after that I use Underscore for search/sort. Records in this example come from a static demo file. A red warning pops up with total download time and total processing time (lapse from download ready to array populated and ready for use). When I used Backbone collection processing time would be between 5-9 seconds (depends on processor speed). http://edwardspooner.com/items/index.html http://edwardspooner.com/items/index.html
- ChrisDutrow 10y ago
  I actually do use an el already in the DOM. To be honest, I do it that way because the code looks cleaner and is easier for me to understand that way, I didn't know it was faster. The only caveat I've found with that way is that if you remove a view and add an identical one, the events from the old view still get fired. For views where that happens, I actually use a custom extension of the original views that has a special destroy method that gets called which unbinds events and stuff. When first learning backbone, I played around with the router, but I don't use it at all now. It was pretty hard for me to use and didn't seem to have much of a point. I suspect for many use cases, if you really need the url path to change, reloading the page from the server would be fine. But of course my perspective comes from only the use cases that I've worked with. I actually mostly don't use backbone to organize the data, mostly only to display the data. The demo you looked at actually has little mini database implemented in the background using arrays and objects (used as maps). I mostly use collections for things that go right on the screen. I also (mostly) don't use backbone's ability to sync data with the server. I have a module that uses Jquery's Ajax for this instead. The reason I don't use backbone for this is that I found their way of doing it breaks down with more complex relationships within the data. I mainly use backbone as a utility for message passing (update a model and one place, and messages are passed so everywhere else it is displayed updates also). And for organization: the views, pieces of the DOM within a view, and events. Also, I use Marionette.js, not pure Backbone.js ...I'm not trying to say my way of doing things is the right way, just relating what I do and why for discussions sake. Oh, and I looked at your demo. That is really cool. That's really fast for so many records.

bikamonki 10y ago

>I think the cost of re-writing things all the time is too high. Exactly. So, unless it stops running on modern browsers, the code should continue to execute and provide a complete solution. Although, I do try to keep Backbone versions up to date. I also plan to continue using Backbone but I do want to learn a 'view' tool to improve performance of UI-rich apps. React seems too big and complicated, I am more inclined towards vue.js or mithril.js. I checked your demo, in case you have not done so already here are 3 tweaks I've done to make Backbone run faster: - Select el already on DOM for a view's el instead of render/append. This is a huge performance improvement. - For big collections use plain JS array instead of Backbone native collection. You'll trade some methods for performance, but such methods can be re-implemented with Underscore. - Ditch the router if you need dynamic routes. Here's an experiment of a classic listings app. After selecting a city, 5000 random listings are loaded at once into a JS array, after that I use Underscore for search/sort. Records in this example come from a static demo file. A red warning pops up with total download time and total processing time (lapse from download ready to array populated and ready for use). When I used Backbone collection processing time would be between 5-9 seconds (depends on processor speed). http://edwardspooner.com/items/index.html http://edwardspooner.com/items/index.html

ChrisDutrow 10y ago
I actually do use an el already in the DOM. To be honest, I do it that way because the code looks cleaner and is easier for me to understand that way, I didn't know it was faster. The only caveat I've found with that way is that if you remove a view and add an identical one, the events from the old view still get fired. For views where that happens, I actually use a custom extension of the original views that has a special destroy method that gets called which unbinds events and stuff. When first learning backbone, I played around with the router, but I don't use it at all now. It was pretty hard for me to use and didn't seem to have much of a point. I suspect for many use cases, if you really need the url path to change, reloading the page from the server would be fine. But of course my perspective comes from only the use cases that I've worked with. I actually mostly don't use backbone to organize the data, mostly only to display the data. The demo you looked at actually has little mini database implemented in the background using arrays and objects (used as maps). I mostly use collections for things that go right on the screen. I also (mostly) don't use backbone's ability to sync data with the server. I have a module that uses Jquery's Ajax for this instead. The reason I don't use backbone for this is that I found their way of doing it breaks down with more complex relationships within the data. I mainly use backbone as a utility for message passing (update a model and one place, and messages are passed so everywhere else it is displayed updates also). And for organization: the views, pieces of the DOM within a view, and events. Also, I use Marionette.js, not pure Backbone.js ...I'm not trying to say my way of doing things is the right way, just relating what I do and why for discussions sake. Oh, and I looked at your demo. That is really cool. That's really fast for so many records.