4 ms·

FUD. Backbone is nothing but a bootstrap. It really just means that you evetually rely on literally twenty or thirty other "micro" JS libraries to get the same

by Rygu 12y ago

FUD. Backbone is nothing but a bootstrap. It really just means that you evetually rely on literally twenty or thirty other "micro" JS libraries to get the same shit done that one framework could singlehandedly provide. Those micro libraries have a higher abandonment rate than anything. Personally I'd go for company-backed projects.

angersock 12y ago
At the same time, a lot less is being abandoned--and your team is more likely going to be able to fight bitrot on a small microframework than on a huge thing like Angular.
- Rygu 12y ago
  Not having tons of libraries means that my team doesn't have to fight bitrot regularly though. Also bug reports / PRs are actually handled adequately by the bigger frameworks and their bigger pool of contributors, so code quality, which I find an important aspect of the software I deliver, is very much guaranteed.
  - encoderer 12y ago
    I don't see much point fretting about bit rot. That's a murky future problem and there is little to guarantee the code we're writing today will outlive the libraries we're using. Instead what I care about is productivity and my experience as an engineer and engineering manager is that the simple, small, annotated source of libraries like Backbone and Underscore will beat the monolithic uber frameworks 9 times out of 10. The trouble is that people often use examples of what you can accomplish with a framework if you follow the common path. But we've all been there -- a 20 hour feature where you build 90% of it with heavy framework support in the first 10 hours, then spend the next 10 fighting the framework for whatever it is that you need done differently than the framework prescribes. This blunts that seemingly-huge time save that a framework appears to provide when you watch a 5 minute build-a-blog screencast. So in the end, it comes, as it usually does, to mastery. The guy who has developed mastery over his tools will outperform, and I think it's a lot easier to master these small libraries with accessible source code.
Igglyboo 12y ago
Yea but those microframeworks can also easily be replaced or re-written if they are abandoned.
- Rygu 12y ago
  That's true, but most companies need to spend at least some of their time on writing their own code and features too. So we pick third party code that serves us and saves us time. Analogy if the goal is to go for a smooth car drive, why would you want to stop and be replacing/reinventing wheels every few minutes?
  - Igglyboo 12y ago
    Obviously it's not black and white and you'll probably have to do a little of both.
mythz 12y ago
> Those micro libraries have a higher abandonment rate than anything.. > Personally I'd go for company-backed projects. You mean company-backed projects like YUI?
- Rygu 12y ago
  Yes, when it was still relevant and heavily developed. So for a long time now I would've said chosen something else, more relevant to and convenient for modern-day web development. Of course if you chose YUI a few years ago and you're still using and relying on it, that means it is still serving you well. Was a great past decision ay?
shangxiao 12y ago
Just a note about company backed projects. I backed Google Web Toolkit a few years back. Big mistake.
- peterb 12y ago
  Why? This is not a troll, I'm very interested in your reasons.
  - shangxiao 12y ago
    Well it's no longer "Google" Web Toolkit, it's now just "GWT"; they've handed it over to a steering committee. At the time I loved using it as it had many nice features. But sadly it's very hard to migrate from. Most importantly is the vendor lock-in with the 2 framework specific RPC mechanisms used to communicate to the server.
  - gknoy 12y ago
    As someone who has been working with GWT, and since moved to JS, I can elaborate on why I agree. GWT was an excellent tool when I started using it, but has been eclipsed (no pun intended) by substantially nicer frameworks (IMO). I am extremely thankful to be using it as little as possible, and am migrating as many of our GWT apps over into Javascript apps as soon as workload allows. (I'd LOVE to hear from someone who is currently using GWT, and has compelling reasons that it's a great tool that are not driven by the inertia of a large codebase.) The main reason I'm glad not to use GWT is that I enjoy developing in Javascript a lot more than I do in GWT (Java). I have found that I can implement, modify, or troubleshoot a UI roughly an order of magnitude faster than I used to be able to do it with GWT. This is due to a combination of being able to reload by refreshing my browser (no slow re-compilation steps), as well as being able to inspect elements/styles directly in the Chrome dev tools. There are about an order of magnitude (or more!) people who write about Javascript, or $FrameworkOfChoice (Angular, Backbone, etc) than there are that write about GWT. This includes both blogs and Stack Overflow, not to mention examples on JSFiddle or the like. GWT doesn't easily let me integrate other Javascript libraries or components, so you have to implement your crappy version of Chosen (or similar) yourself. There's no JQuery or Underscore or similar, because it's all Java (basically). The Chrome Dev Tools or Firebug are >>> the GWT debugger. The GWT Dev Mode plugins required for debugging, is also no longer supported in Chrome, and soon in Firefox. (I discovered this last week, the first time I've touched GWT in half a year. There's a newer Dev Tools alternative, but I've been unable to actually get it working.) Javascript testing tools (Jasmine, phantomJS, etc) and build tools are now a MUCH more mature ecosystem than they were when GWT was first invented. We used to use a combo of JUnit + Watir/Selenium to test our UI, and now we can do similar with Javascript frameworks in a less fragile way. In summary, GWT was awesome, but I see no reason to use it today. It helped me find my current job, so I'm grateful for that. However, if you were looking for a web framework, you would be much better served (IMO) if you chose React, Angular, or Ember rather than GWT.
apalmer 12y ago
'Company-backed' is a very nebulous term. If Microsoft was backing Angular I would have every confidence that it would be supported at least for security fixes for the next 10 years even if microsoft had to add a whole compatibility layer on there next 3 OSs to do so. Google backing an open source project on the other hand has a whole different level of support expectations in a 3 year timeframe.
- darkmarmot 12y ago
  just like Silverlight! :)
  - apalmer 12y ago
    yeah exactly MS gave up in silverlight however they will continue to provide security fixes for it probably for the next decade
rubiquity 12y ago
I've been using Backbone for years without any micro libraries. I only recently started using React with Backbone, which is an awesome pair.

by Rygu 12y ago

angersock 12y ago

At the same time, a lot less is being abandoned--and your team is more likely going to be able to fight bitrot on a small microframework than on a huge thing like Angular.

Rygu 12y ago
Not having tons of libraries means that my team doesn't have to fight bitrot regularly though. Also bug reports / PRs are actually handled adequately by the bigger frameworks and their bigger pool of contributors, so code quality, which I find an important aspect of the software I deliver, is very much guaranteed.
- encoderer 12y ago
  I don't see much point fretting about bit rot. That's a murky future problem and there is little to guarantee the code we're writing today will outlive the libraries we're using. Instead what I care about is productivity and my experience as an engineer and engineering manager is that the simple, small, annotated source of libraries like Backbone and Underscore will beat the monolithic uber frameworks 9 times out of 10. The trouble is that people often use examples of what you can accomplish with a framework if you follow the common path. But we've all been there -- a 20 hour feature where you build 90% of it with heavy framework support in the first 10 hours, then spend the next 10 fighting the framework for whatever it is that you need done differently than the framework prescribes. This blunts that seemingly-huge time save that a framework appears to provide when you watch a 5 minute build-a-blog screencast. So in the end, it comes, as it usually does, to mastery. The guy who has developed mastery over his tools will outperform, and I think it's a lot easier to master these small libraries with accessible source code.

Igglyboo 12y ago

Yea but those microframeworks can also easily be replaced or re-written if they are abandoned.

Rygu 12y ago
That's true, but most companies need to spend at least some of their time on writing their own code and features too. So we pick third party code that serves us and saves us time. Analogy if the goal is to go for a smooth car drive, why would you want to stop and be replacing/reinventing wheels every few minutes?
- Igglyboo 12y ago
  Obviously it's not black and white and you'll probably have to do a little of both.

mythz 12y ago

> Those micro libraries have a higher abandonment rate than anything.. > Personally I'd go for company-backed projects. You mean company-backed projects like YUI?

Rygu 12y ago
Yes, when it was still relevant and heavily developed. So for a long time now I would've said chosen something else, more relevant to and convenient for modern-day web development. Of course if you chose YUI a few years ago and you're still using and relying on it, that means it is still serving you well. Was a great past decision ay?

shangxiao 12y ago

Just a note about company backed projects. I backed Google Web Toolkit a few years back. Big mistake.

peterb 12y ago
Why? This is not a troll, I'm very interested in your reasons.
- shangxiao 12y ago
  Well it's no longer "Google" Web Toolkit, it's now just "GWT"; they've handed it over to a steering committee. At the time I loved using it as it had many nice features. But sadly it's very hard to migrate from. Most importantly is the vendor lock-in with the 2 framework specific RPC mechanisms used to communicate to the server.
- gknoy 12y ago
  As someone who has been working with GWT, and since moved to JS, I can elaborate on why I agree. GWT was an excellent tool when I started using it, but has been eclipsed (no pun intended) by substantially nicer frameworks (IMO). I am extremely thankful to be using it as little as possible, and am migrating as many of our GWT apps over into Javascript apps as soon as workload allows. (I'd LOVE to hear from someone who is currently using GWT, and has compelling reasons that it's a great tool that are not driven by the inertia of a large codebase.) The main reason I'm glad not to use GWT is that I enjoy developing in Javascript a lot more than I do in GWT (Java). I have found that I can implement, modify, or troubleshoot a UI roughly an order of magnitude faster than I used to be able to do it with GWT. This is due to a combination of being able to reload by refreshing my browser (no slow re-compilation steps), as well as being able to inspect elements/styles directly in the Chrome dev tools. There are about an order of magnitude (or more!) people who write about Javascript, or $FrameworkOfChoice (Angular, Backbone, etc) than there are that write about GWT. This includes both blogs and Stack Overflow, not to mention examples on JSFiddle or the like. GWT doesn't easily let me integrate other Javascript libraries or components, so you have to implement your crappy version of Chosen (or similar) yourself. There's no JQuery or Underscore or similar, because it's all Java (basically). The Chrome Dev Tools or Firebug are >>> the GWT debugger. The GWT Dev Mode plugins required for debugging, is also no longer supported in Chrome, and soon in Firefox. (I discovered this last week, the first time I've touched GWT in half a year. There's a newer Dev Tools alternative, but I've been unable to actually get it working.) Javascript testing tools (Jasmine, phantomJS, etc) and build tools are now a MUCH more mature ecosystem than they were when GWT was first invented. We used to use a combo of JUnit + Watir/Selenium to test our UI, and now we can do similar with Javascript frameworks in a less fragile way. In summary, GWT was awesome, but I see no reason to use it today. It helped me find my current job, so I'm grateful for that. However, if you were looking for a web framework, you would be much better served (IMO) if you chose React, Angular, or Ember rather than GWT.

apalmer 12y ago

'Company-backed' is a very nebulous term. If Microsoft was backing Angular I would have every confidence that it would be supported at least for security fixes for the next 10 years even if microsoft had to add a whole compatibility layer on there next 3 OSs to do so. Google backing an open source project on the other hand has a whole different level of support expectations in a 3 year timeframe.

darkmarmot 12y ago
just like Silverlight! :)
- apalmer 12y ago
  yeah exactly MS gave up in silverlight however they will continue to provide security fixes for it probably for the next decade

rubiquity 12y ago

I've been using Backbone for years without any micro libraries. I only recently started using React with Backbone, which is an awesome pair.