hi there. i am new in digital point. can anyone suggest which one is the best javascript framework. any comparison link or post your opinion in here.
I recommend you Jquery. It's flexible, lightweight and you can do so much more with it. I used to work iwth scriptaculous and mootools before, but Jquery made me choose it as my #1 scripting Framework. Try it yourself at http://JQuery.com
Sorry, no. This is like asking, which is the best car to buy or football team to support... There is no right answer! I have worked with prototype/scriptaculous and jquery - but chose to use mootools instead. much like in driving, once you get the basics, it all boils down to geting from a to b in a fast and safe manner. fact: over time, frameworks have slowly become very similar to each other. they steal... well, share ideas and concepts - it's almost like an evolutionary process. there is only one fastest and most logical way to do task A. it makes sense to passback objects from functions so you can do chaining (element.mehtod().method2().something(); ...) so they do it now, and so forth. So, I guess the real question here is: what is the sound decision for you and your business? compatibility Consider what you have running already on your site, will it break if you add the framework? The problem is, there are two approaches to doing a framework. As javascript allows you to overwrite any variable/function, including native ones, it is tempting to extend/improve on the existing ones by changing them. For example, you may want to change the .toString() method to work differently / better - you just overwrite it like so: var toString = function() { .. } The problem with such an approach is that you can change functions and functionality various scripts rely upon. This known as a namespacing issue. The most logical name for a function that returns the X,Y coords of an element is getCoordinates(); Unfortunately, other script writers also come to the same conclusion and may overwrite your function with one that returns the data differently... Frameworks like mootools do not try to be accommodating of other scripts/frameworks. They extend native functions and always go go for the shorthand version - less typing, and at the same time, more intuitive and natural to someone that already is familiar with javascript. Frameworks like YUI or GWT take a different approach - everything is prefixed by the parent namespace, thus avoiding any possible conflicts. For example: YAHOO.util.Event.preventDefault(e); - a long way to type what in mootools would be e.stop(); or e.preventDefault(); In fact, to illustrate the above, here is the same task performed in YUI, mootools and jquery - you will see exactly how similar they can be: <a href="help.php" id="myhelp">Link's default behavior (to help.php) is suppressed.</a> HTML: via YUI: var interceptLink = function(e) { YAHOO.util.Event.preventDefault(e); alert("You clicked on the help link."); } YAHOO.util.Event.addListener("myhelp", "click", interceptLink); PHP: via Mootools: var interceptLink = function(e) { e.preventDefault(); alert("You clicked on the help link."); } $("myhelp").addEvent("click", interceptLink); // or you may want to do more than 1 event $("myhelp").set({ events: { "click": interceptLink, // you can add all sorts of events in 1 go "mouseenter": function() { }, "moseleave": function() { } } }); PHP: via jQuery: var interceptLink = function(e) { e.preventDefault(); alert("You clicked on the help link."); } $("#myhelp").click(interceptLink); PHP: I have not tested any of the above but they should all work. There is a third approach, and that is something that jQuery can do (possibly others but there are 100s of frameworks/toolkits out there): both namespaced and extracted. If you do noConflict();, changes functions to work within an alloted jQuery namespace. To call $("#myhelp"), you'd have to do jQuery("#myhelp") instead and so forth. longivity, business sense and maintenance If your site and business is to depend on a framework and needs to grow and be updated over time, then you also need to take into account things like: - how long has a framework been around, how stable it is - is it likely that it will remain 'out there' and won't leave you hanging (most are free / open source and as such, subject to the whims of people that run them) - support / community base (resources available) - support by major players, funding, chances it will change licensing etc... - your learning curve and the learning curve of any other developers - cost and availability of professional help Now, it is no accident that jQuery has the lion's share of the 'market' and it's even being put on nokia/symbian based mobile phones (used for effects / widgets as a part of the phone's built-in interface). Even microsoft use it. But... in reality, all it means jQuery have a better business model / marketing whereas most frameworks don't strive to be a commercial success. To developers like me and you and companies with smaller resources, it's not always the right path. jQuery has a great repository of plugins, most of which are user-based contributions and maintained for fun. At it's core, the framework alone only gets you that far and then you start adding plugins to save time. The problems start when the jQuery core updates and then all the plugins you are using don't. It also is relatively novice friendly with a not-too-steep a learning curve.... With mootools, you are in no danger of getting into such a situation, it has no plugins system (although plenty of user contributions). It does not try to be for beginners. It assumes you already understand the basics of OOP and javascript is second nature to you. This is partly why mootools users are often accused of being elitist and unapproachable. Nonsense... You do have great resources and all the help in the world. But it can be a slightly more difficult task to learn it initially. The rewards are worth it as you grasp how powerful and flexible the framework really is... As for the others... well. Have a read on www.ajaxian.com Also worth a mention in my opinion: ext GWT (google web toolkit) Dojo Read this post from Aeron Newton who is a javascript author extraordinaré: http://www.clientcide.com/best-prac...y-makes-one-framework-different-from-another/ I hope this helps somebody to make the right choice.
I've yet to encounter one worth a damn - 99% of the time they are fat bloated poorly written rubbish, that just bloats out and slows down your page. See jquery, mootools, et al... Frankly unless you are building something on the scale of google maps, if you need that much javascript for a website you have probably completely overthought your entire page unneccessarily turning it into a complete and miserable accessability /FAIL/ -- see the new Hotmail for an example of what I mean by /FAIL/. It is another of those sleazeball shortcuts that WILL bite you in the ass eventually. Javascript is NOT a compiled language, therin libraries are the equivalent of writing a late 70's basic program with several hundred lines of uncalled code and filled to the brim with REM statements.
I don't use any framework but if I did I would go for jQuery. jQuery by far is the most efficiently coded (imnsho) and has the least meta code (code overkill). jQuery really keeps writing javascript like javascript while other libraries try to make it as though you are writing some other language.
I vote for mootools. I know, that there is more free plugins in jQuery, but i think it's easyer to code in mootools framework.
Actually that is false. Although jQuery is the smallest of the core libraries, the results of what it outputs is not the most efficient. This does not mean I think jQuery sucks, because it doesn't. In fact, I use it regularly. If you think I'm wrong, check out this test engine: www2.webkit.org/perf/slickspeed/ Run the test in Chrome! Chrome is really fast! Also note that ext and Prototype both finish ahead of jQuery in selection speed.
the test uses jquery v.1.2.3., Current Release: v.1.2.6 - a lot of changes/improvements to selectors have been done so its not exactly a relevant result.
Having a base-lib ease your development life doesn't mean you should use selectors everywhere on large DOMs without specifying what part of the DOM it needs to search.. For instance, if you have a page with 1000 DOM nodes and a html window with about 200 DOM elements in it to describe something, then searching the entire DOM to get at elements in the window is a bit foolish. I'd selector the window only once, save that reference somewhere, and do all searches for things inside the window (=container) as (jQuery): $('div#someID.someClass', container).css ({..... The performance difference between the base-libs will be negligible (i think) if you keep your selectoring confined to the parts of the DOM tree that it _needs_ to search, and cache selector results of things you use often...
Agreed. In most situations you really don't need 95% of those selectors. Also, if selectors were critical check out sizzle. Its to be integrated into jQuery in one of the upcoming releases.
Are you talking about jQuery?? jQuery is ENTIRELY based around node-selection. In Prototype it is a key API. Almost the only thing the $, or jQuery object does is select nodes, then pass the object on so that it can be chained to various methods. The jQuery object always returns an array, which is necessary because of the scope of its ability. The reason jQuery is slower (mind you, this won't have a huge affect on normal operations), is that the power and convenience of selecting everything via $(this).method() takes a bit more cycles to accomplish. Although there are things that they are doing to speed things up some, it is always going to be a bit slower because of the way it is designed. Don't think I'm downing it, because I'm not, it is still my favorite front-end tool. Seeing how you don't actually use it...
still - being able to do all css 3 style selectors natively would be nice. and yes, some of the more obscure selectors can be worked around in 90% of the time and you'd not even think about them... one type of a selector that I find really needs to happen is this: <div class="order" data-id="50002" ></div> <div class="order" data-id="50003" ></div> <div class="order" data-id="50004" ></div> ... <script type="text-javascript"> var getOrderLayer = function(orderid) { return $("div.order[data-id="+orderid+"]"); } console.log(getOrderLayer(50003)); </script> HTML: as it seems that data-nnnn is making it's way as the established namespaced way of using elements for storage in HTML 5 but most frameworks have a problem in evaluating it correctly due to the "-". For example, if you did: <div class="order" rel="50003">, $("div.order[rel=50003]") would return fine. the issue here is that the html won't validate... adding complex structures into properties like ... alt="{id:'blah',name:'test'}" is ok for reading but at the cost of performance...
lol? Google Chrome brings nothing new into the client side markup world, as all it does is use WebKit (which is a very impressive layout engine). Its JS engine (V8) has some innovation, it is said to be extremely powerful at recursion.
Run the test I gave above in Chrome. It does every selection test natively. Of course, it is done with the new JavaScript engine. I didn't mean to imply there was a new CSS renderer.
Selectors have to do with the layout engine, it doesn't concern the JS engine. Even when used in javascript. Firefox also runs all those tests natively and safari (using fx 3.1b)
Safari too, eh? Neato. I didn't want to download fx 3.1b since I develop mostly on 1 computer, and don't want it to interfere with browser testing. The current Firefox chokes on all of them. I heard the new JavaScript engine has a lot of bugs to work out of it, however. Seeing how it's only been in development for 3 months, it's no surprise. It is supposedly going to be really fast, almost as fast as Chrome's. I'm looking forward to the day that we can kiss Flash goodbye. Actually, for this test, yes, it is testing the JavaScript. The "native" function it is testing is document.querySelectorAll, which isn't supported by FF3 (current version). It is being released in version 3.1, which is why the test worked for you. Although the test swallowed the error, it displayed it in the title attribute on the right column for me.