Develop Reference

Is backbone.js production ready?

I was recently hired at a startup as the front end developer. As our product is a user admin that will be used by financial organizations, we want the app to run as much like an application as possible. I have been tasked with finding the clientside framework.
After researching, I have chosen backbone.js. When I presented this choice today, I was asked some questions that I do not have the full answers for but thought you guys might.
Is backbone.js production ready?
Is it rock solid and is there any proof?
I will only be using models, views, and collections for this app. My question is, how confident can I be that backbone will not just randomly fail when dealing with models. Are there any official tests I might be able to look at? What are your experiences with backbone?
Is there any sort of support network in place for dealing with backbone related issues?
Answers to either of these questions as well as any insights you have that I could present to my boss would be most appreciated! I Really want to use backbone as I think its a perfect fit, but because its so new, I need to sell it.
Thanks in advance!

Is Backbone.js production ready?
Take a look at Backbone's example section. Some of its better known users include:
DocumentCloud themselves.
37signals for BaseCamp Mobile.
SoundCloud for their mobile site.
BitTorrent in a manner that is not immediately obvious from the description, but seemingly related to a beta product.
Is there a support network in place?
There is, of course, no guarantee that it will be supported by its authors indefinitely, but it has gained a lot of traction very quickly so I don't see it going anywhere soon. The authors recommend reporting issues on GitHub.
There is always Stack Overflow itself for support!

I too was looking for a front-end app framework a few months ago. Here's the list of requirements that we had and how Backbone.js responded to each of those:
1. Browser support (IE8+)
There is one caveat here: The backbone.history module makes use of hashchange event, which doesn't work in IE7 and below. There are ways to hack around this problem, so it's not a show stopper, but kind of an annoyance.
2. The ability to apply our own look and feel to UI elements
As backbone only enforces the MVC structure of your app (unlike frameworks like cappucino or sproutcore) this was a perfect fit for us.
3. Being able to hook up any other external JavaScript libraries
We were using jQuery already, and backbone supports it, so that was fine. However, it seems like backbone is trying to take a library agnostic approach (for instance you can use zepto.js instead of jQuery if you like).
4. Community Support
There is a lot of introductory material on backbone (like people posting tutorials on blogs). Unfortunately, when your APP get's complicated it turned out there were quite a few "architectural" parts we had to figure out by ourselves, there was no obvious way to do it. The DOCS are good, but not great.
I guess on of the pitfalls of opinionated frameworks (like rails), is that sometimes you get caught up in a "am I doing this right" feeling.
5. Real world examples
It's always convincing to see that someone else has actually done something "REAL" with backbone:
http://documentcloud.github.com/backbone/#examples
We ended up using Backbone, and it was overall a nice experience, and I will definetively be looking into it again for our next project.

Who is to say that something is production ready better than the product users?
I'm working with backbone.js on a relatively large project (livechat operator application, 13k+ lines, currently at early beta). I have more than three months of experience with backbone and in my opinion it's excellent. I haven't had any unpleasant surprises because of backbone. I can't imagine developing an app of this size without clean and well-structured code. With backbone you can achieve that easily.
There's also an excellent bonus when using backbone - underscore.js. You will use that a lot.
StackOverflow backbone.js tag is there for you!
Your company, being a startup, cannot be afraid of new things. You should adapt them and spread your experiences. Remember, that your product is also going to be new.

A little late to the game with this answer but I felt compelled to respond to the question "how confident can I be that backbone will not just randomly fail when dealing with models".
No code just randomly fails; code fails for a specific reason which can always be traced back to somewhere. Often code appears to randomly fail because it's so complex and obtuse you can't follow it. In the case of backbone.js, the source is small (1,500 lines FULLY documented) and REALLY well documented.
If you need to trace down what is breaking, it's a simple matter of diving into the source and seeing what is going on.
Anyhow, I hope you got to try it out at your job!

At Planbox We've been using Backbone JS in in production for over 6 months without any problems. I wrote a few posts about our experience here and here.
We even use Backbone JS for our mobile version along with jQuery.

What are some example javascript frameworks that people use?

I am really big fan of jQuery, but I don't see it as a framework for a site, more like a library. I am looking for some sort of framework that will give me the tools to build really structured applications in javaScript. I have found backbone.js, but find it somewhat confusing. Is that a good one, and are there others similar to it? an MVC pattern would be really cool, but I havent found anything.

I use currently RightJS with RequireJS. It has worked out well for my purposes. I used jQuery + jQuery UI previously. The current combo fits my style better (more barebone functionality instead of just DOM wrapper + UI plugins).
I know RightJS isn't that popular. The docs are adequate and the author is responsive. This makes up for that. :)
Some other alternatives:
qooxdoo
MooTools
Prototype
I'm sure there are plenty of more alternatives. It really comes down to your preferences and exact needs.
Personally I have been looking at Sencha's offerings (ExtJS, Sencha Touch) lately. The latter is particularly interesting as it provides simple means to write cross-platform apps for mobile devices. Works great in iPad at least!

The Google Closure Library & Tools is pretty good, and is the framework they use to build Gmail, Google Maps, and so on.

jQuery and YUI 3: A Tale of Two JavaScript Libraries is a story about a jQuery developer that found that YUI3 was more "framework-like" and apt for his project.
I've been using YUI2 for years and it never disappointed me.

If you like dynamic OOP languages like Ruby/Python, you should really check RightJS. It is very compact, fast and simple. RightJS is built fully on OOP paradigm and allows you to implement serious stuff in a serious but not boring way.
As for the dom part, it doesn't exactly uses MVC as is, but RightJS has OOP dom-wrappers, with inheritance and so one. That provides basically the same result, but with much less headache.
And if you're particularly interested in patterns, check this out https://github.com/rightjs/rightjs-patterns :)

YUI and/or jQuery for a new project?

If I am starting a new project how should I pick between using YUI 2, YUI 3 and jQuery?
I know there are a bunch of questions/answers already about can you use them together, but I am trying to figure out what criteria I should be thinking about to make my decision.
Are they overlapping?
Is one better at GUI and the other better at internals?
Do they play well together? My understanding from other questions is that they can live in different namespaces, so they can live together, but that doesn't necessarily mean that it is good to use both.
Thanks!

If you are familiar with neither, I personally have found jQuery's documentation and API easier to understand than YUI's, at least for simpler things. It also appears there is more jQuery related information than YUI on stackoverflow.
YUI does have its users and supporters though, so check it out in case you end up finding it suitable for you. It's got a huge library of additional modules you can use for complex web applications.
My usual advice would be to go with whatever you're familiar with, and I say this because I don't think it's worth dropping one to start learning the other from scratch. But if you are familiar with neither, then you should check out how easy the documentation for both is to understand.
PS I would not recommend YUI2 if you're starting anew as it has been superceded by YUI3, which is much better designed.

We need more information about the type and size of the project before a proper library can be suggested.
For example, if you're building a semi-complex/large-ish web app, I would suggest Dojo or ExtJs. Otherwise, for smaller projects, jQuery might be more appropriate. I cannot comment on YUI as I have not used it.

Impossible to say without knowing more details about the project. Use jQuery or Prototype for things like DOM manipulation and making autocomplete, etc. If you need a more powerful Javascript implementation take a look at ExtJS, which is basically a full stack framework for Javascript.

Both are JS frameworks and there to help you. YUI is known to be more natural in them and more closer to the original Javascript while jQuery is known as more easy and you find more jQuery users and support around then YUI. However, as said earlier, it depends on the project, if it is likely that you will be making your own custom widgets, I will suggest you to go with YUI but if it's like a simple e-commerce website in which you just need some fancy galleries and shopping cart, go with jQuery, you will learn and implement that quickly. I am not saying that you can not go more in depth with jQuery but my impression is that jQuery is more of a CakePHP for PHP like of framework which gets you off the grounds quickly.
In my opinion there is no need for you to use them side by side in a single project, that will just produce the over-head as both do whatever you want to do in them i.e creating dialog panels, autocomplete quick searches, event related utilities etc.
I am writing down a series of beginner and mid-level tutorials for YUI users, let me know if you find them useful or if there is anything else where I can help.
http://ciitronian.com/blog/tag/yui/

What are the arguments against using a JavaScript Framework for a Web site development company? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
Our company builds websites and web applications. We are a small firm and our team of developers are always building the javascript functions from scratch or copying from other websites built by us. Every time I bring to the table the word standardization and using a JS framework like JQuery, Prototype or any other, I am told Frameworks have the three points below as arguments against them:
Mainly for people that don't know enough JS
Frameworks limit Javascript developers
Frameworks bloat the actual development code with a lot of things that are not used.
We don't use enough Javascript in our applications for us to need JS framework
In my mind it seems that Frameworks, give our team a good starting point, documentation, a community and always the option to grow on top of the framework. Could some Framework users elaborate further?
EDIT 1:
Thanks to all of you for your great responses. I really did not think that this was going to be such a hot topic. I am glad I asked the question. I posted another similar question in the following link in case you might think you want to add something. The topic of the new question is CSS related. Thanks.

By your coworkers point of view, .NET and JAVA are for people who don't know enough assembly.
Frameworks exist for a reason. They allow you go focus on the problem instead of dealing with repetitive code. They allow you to be confident (assuming you use well tested frameworks) that certain pieces of your code are reliable and well tested.
If your coworkers are against frameworks, I would seriously consider moving on.

Since no one has mentioned it - a Javascript framework rapidly becomes one more project dependancy, and in general terms, dependencies are bad as they represent points of failure.
As for this:
Mainly for people that don't know
enough JS
Without elaborating, I will say that if one of our team said something like that in my presence, I would try to shrug it off as a joke. If I thought they were being serious, I would probably have to kill them.
And as for this:
Frameworks limit Javascript
developers
That could translate to "Frameworks make it marginally harder to write spaghetti code, and that's what I do best"
Those are not arguments, they are excuses.

Arguments against:
Frameworks prevent you from re-inventing the wheel
Frameworks generally contain well tested code
Frameworks are well supported by the community
Frameworks force you to focus on the business problem you're trying to solve
</sarcasm>
Frameworks may have a license you don't agree/can't work with

A few positives for javascript frameworks (like JQuery).
They provide standardization in ui
elements.
Reduce time to develop complex
interfaces and effects.
Normalize efforts by providing
functions that are already
cross-browser compatible.
Due to efforts in cross
compatibility documentation is more
useful in a framework as you can use
the framework's api as canon
instead of searching for obscure
support for various/proprietary
javascript functions.
Reduced learning curve for new
developers making them productive on
your software quicker.
I completely disagree that a framework limits javascript developers. Quite the opposite actually. Most frameworks provide extensive plug-in mechanisms where the framework can be extended using raw javascript utilizing hooks in the framework itself.

I'll use jQuery as an example, but what I'm saying here could apply to most JavaScript frameworks.
Many frameworks (notably jQuery) are far too monolithic and not modular enough.
While depending on well-tested 3rd party software is often more than justified, "frameworks" tend to give you a lot more functionality than you need at the moment.
In many projects, I very much like the convenience that jQuery gives me for selecting sets of elements (using $(".classname"), for example). But, if I'm not using any significant amount of AJAX, I don't need the AJAX utilities provided by jQuery.
Software should do one thing and do it well, and software written in JavaScript is no exception. Most of the frameworks you refer to try to do everything, resulting in unnecessary complexity.
One place this can bite you is when you're considering upgrading to the next version of the framework. That involves crawling through jQuery's changelogs for backwards-incompatible changes and searching your project for areas where that code is used. This can be quite a nightmare, especially if you don't necessarily have a comprehensive list of which jQuery features you use and which ones you don't.
Also, jQuery (and other frameworks) tends to cause developers to start depending on new features of jQuery without even thinking about it, making it harder to determine which features of jQuery your project uses and which it doesn't.
If you use a utility which does one thing, then you know exactly which features of that utility you're using. There's only one. (If you aren't using that utility at all, it's easy to determine. Such a determination would mean you could safely remove it from your project.)
I'm all for using well-tested 3rd party code. But if it tries to do too much, (that is, if it's a framework rather than a utility), you should probably look for an alternative. If it tries to do too much (like jQuery tries to do too much), then it's got some serious, foundational design flaws that will probably come back to bite you.

I'm surprised no one has already mentioned it:
A lot of web developers default to using JQuery without considering the alternatives
And end up including it on a web page to do a few trivial tasks which could easily be done in pure JavaScript
The result is that users have to wait for the whole library to download and it slows down web browsing
Also:
Some web developers get carried away with the design of web pages, and end up developing unnecessarily complex web pages because of the power of JQuery
Just because JQuery enables you to create scripts with good cross-browser compatibility it doesn't mean that the end result is usable on different devices / interfaces
I'd also argue the cross-browser compatibilty because I've seen instances of webkit not playing well with JQuery
JQuery encourages "fast" scripting - but if you rush it you are likely to have missed something out
Writing in JavaScript from scratch is slower - but I believe that you end up with a more complete solution which more closely matches the users needs
Using JQuery can shift the focus of the web developer to creating web sites which are highly graphical and visually appealing, whereas the focus should be on functionality and usability
JQuery is not a silver bullet for web development
I am biased here because I don't use JQuery, but it is because I haven't found a need for it yet - maybe it's because I focus more on usability and functionality rather than making the user interface look pretty (sorry I know JQuery can do more than that).

An argument against libraries is BROWSER SUPPORT most libraries support only a subset of browsers out there .
Here is an example of BBC rolling out their own instead of using something like jquery .

I liked the answer of pb +
Mainly for people that don't know
enough JS
I believe it is too complicated for them, so they use this excuse. FW allows you to build much more complex applications.
Frameworks limit Javascript developers
bullshit
Frameworks bloat the actual
development code with a lot of things
that are not used.
what is it today extra 100k-200k? especially if you use the CDN versions (at google for instance). And this is assuming you use nothing in the FW.

There are plenty of good reasons to be suspicious of frameworks in general, balanced of course by lots of reasons why they are worthwhile.
I use jquery now, and frankly within an hour of learning it realised that it fits the job so well that if it didn't exist I'd only end up reimplementing something very similar myself, only it wouldn't be as good or as cross platform.
There isn't much bloat there, it's very small and well designed and does nothing at all that stops you writing any javascript you want for specific cases that don't fit your needs.

Do javascript developers need to know jquery?

If you were to hire a javascript developer would you expect them to know jquery?
I just started using stack overflow this week and knew that jquery led the pack, but didn't realize the extent of it until I noticed that MooTools (my favorite) has 59 questions while jquery has over 4000. (of course, a good statistician could attribute jquery having more questions to it's usability, rather than it's popularity--but we know that's false)
And then I started noticing that many people post questions with the tag "javascript" but not "jquery" when every line of their code is jquery--like it's the de facto javascript 2.0, or that they don't even realize they aren't writing "javascript" but rather jquery.
Anyway, I ask this because I've always been freelance and could use whatever framework I want on a project. But lately I've been recommended to be the front-end developer for a couple companies. I want a feel for the community's expectations to know if I should put some other personal projects on hold to pick up jquery before exploring the positions that might be offered.

No. I'd expect them to know how JS works. A good JS developer will pick up jQuery in less than a week, probably a few hours.
A developer who knows jQuery but doesn't know JS has a great deal to learn and would only be considered for the most junior roles.
jQuery is definitely not JS2.0 - it's a great standardisation framework if you still need to target IE8 and the like, but it's not great at mobile, it can't be loaded with async or defer, it doesn't support newer features like passive events, and its primary optimisations are about finding elements in an already built DOM (which means it doesn't add much value for client side DOM builders).
I would expect them to have heard of it, and be able to talk about its strengths and weaknesses against other frameworks.

They should at least know what JQuery is, and be able to tell why they chose it or another framework. Next to that, a basic understanding of the most popular javascript framework can never hurt.

I started off when I came across mootools and have not looked back since. But recently, I have spent a fair amount of time polishing my 'vanilla' javascript and have also started looking at jquery (out of sheer curiosity ). Turns out, you need to understand a lot about the frameworks, the differences between them and how javascript works if you want to be able to translate your skills and be able to refactor code between them freely.
for example, consider this as the logical code refactoring between the 2 frameworks
mootools
$("elementId").addEvent("click", function() {
this.setStyles({
border: "1px solid #000"
});
});
jquery
$("elementId").click(function() {
this.css({
border: "1px solid #000"
}); // fails.
});
I was surprised to discover jquery did not work - and then considered that mootools extends the elements' prototypes by adding .setStyles whereas jquery is function based. the fix is obviously to use $(this).css instead - only it's not that obvious at first. It made me realise it would take more than reading the interface docs to be able to swap between the two.
as somebody said, it would take a week to pickup on all of the nuances of jquery even if you have a strong-ish javascript/mootools (or other framework) background, but it won't be such a challenge. moving from jquery over to mootools, however - won't be such an easy task if you are not well versed in vanilla javascript and OOP.
the short answer is, I wouldn't expect a javascript programmer to just know jquery but I'd expect a jquery user to learn about javascript.

JQuery is a very important part of javascript development these days, so yes I would expect a JS developer to know how to use it even if its just the basics.
One of the reasons that it has suddenly gained momentum in the business app development arena is that Microsoft have given it their backing and have agreed to have it distributed with their latest web frameworks (See ASP.NET MVC).

It all depends on what they were developing.
If the web application extensively used ajax, which you could argue it should if possible) then JQuery is a excellent way of doing this. JQuery reduces development times over solely javascript.
Bottom line, if it was me doing the recommending Yes, know both

I would expect JavaScript developer to know jQuery because it's famous for a reason.

I wouldn't expect them to know jQuery, if they could use it, then it'd be better, since I prefer jQuery to all of the rest. It is possible that he/she has their own preference over jQuery, as many people do.

Jquery is pretty popular these days. It make development much more efficient and easy. And there are tons of plugins and scripts available to choose.