Develop Reference

Javascript dead code elimination

I'm looking for a way to reduce a javascript library/framework with the objective of only sending to the client (browser) only the necessary code. I've searched and I found that, for example, closure compiler can't remove jquery dead code.
How can I write a web application, using javascript or any other languages/frameworks/tools to archive this goal? I've nothing against frameworks but in mobile devices performance counts a lot. I've tested HTML5 mobile apps on cheap android devices and it's terrible to use due to performance issues. I want to extract maximum performance.

My 2 cents:
In term of performance, use good practises with a linter such as jslint, jshint, or eslint.
To check wich concept is better than another one, you can check at jsperf or make your own ones with benchmark.js.
For loading time, jQuery is a bit big for mobile. Zepto is a good alternative. Imo, it's better to concat all js files on mobile than async load the js.
MicroJs is a site which list all libraries that usually fit a specific need.

Testing and comparing performance of jQuery plugins

There are a tonne of jQuery plugins out there and so I want to ensure that when I find two or more plugins that do the same thing, I choose the best.
I generally go for filesize as a first indicator of peformance, but I was wondering else I can do to test and compare performance of these plugins.
Could I use jsperf.com? Throw those plugins I want to compare in there. Would the results be a good indicator as to the performance?
Any other suggestions?
Thanks.

For measuring performance and so on there's a great free tool in circulation: DynaTrace Ajax 3 Edition ( http://ajax.dynatrace.com/ajax/en/ )
In your case you have to look at the JavaScript part http://ajax.dynatrace.com/ajax/en/content/c-javascript-dom-tracing.aspx
Which gives you the ability of measuring performance of specific methods and so on. I've used it in the past to optimize a huge mega drop down menu running in IE7. It helped a lot!

Filesize is not a good indicator of runtime performance. If you know javascript very well, you could look at the code and form an opinion of how well written it is, but I wouldn't expect filesize to be a good measure of runtime performance.
If performance really matters to you, then the only way to make a meaningful decision is to measure the exact operations that you care about. jsPerf is one very useful tool for setting up a performance comparison between two different ways of accomplishing a task. But, you have to be very careful when designing performance tests so that what you are measuring is really the right thing and jsPerf can only measure some types of things.
More specific advice would depend upon the specific plug-in and what types of operations it does that you care the most about.
For reference, jQuery may sometimes be the fastest and most convenient way to write code, but often isn't the fastest executing code for sections of code where speed really matters. For example, document.getElementById("test").value = "foo" is 5-7x faster than $("#test").val("foo") as illustrated here: http://jsperf.com/jquery-vs-plain-javascript.

Generally the best indicator of performance, aside from looking through the code and testing it yourself, is the number of people using it along with the comments and reviews you read about it. File size is of little consequence unless it's extreme.
Just read what others have said, what the documentation says about known issues and make an educated guess.

Sign up for Sauce Labs, which lets you test the most prominent browser/OS combinations, and see how the plugins perform in every browser you care about.
(A free account gives you 45 minutes of testing per month.)

Is there a jQuery alternative for building faster web sites

We are about to commence a redesign of our site and are exploring all options in improving performance. The site is fairly heavy in javascript loaded adverts, therefore we need to be really lean with the javascript we use.
Do any of you have any experience of lighter frameworks or more efficient frameworks that I could explore? Or any resources that you could point me toward? YUI looks like an interesting concept … has the loader being tested in anger? ANy good?
Any thoughts would be appreciated.
Cheers.
edit: Sorry, I wasn't clear. The sites performance currently is pretty good, we are not redesigning due to performance issues, it is due to a rebrand. We just wanted to take the opportunity to review best practices.

jQuery 1.4.2 is lean and mean. You'll be hard pressed finding something faster or more lightweight.
As an example, here is a framework test called slickspeed from mootools. It tests a framework's ability at finding elements in the DOM. The version of jQuery being tested is 1.2.6. Depending on your browser, jQuery performs exceptionally well. In my Chrome browser, jQuery beat all the others with a total time of 20 milliseconds.
And since version 1.2, jQuery has had astounding improvements in optimization and speed, especially with 1.4.
That said, a framework isn't going to make you code better. You can write some seriously slow scripts using any framework, including jQuery.
If, however, you write optimized code, jQuery can be so fast you don't even notice.
Pointy's comment above is spot on. All these guys do all day is worry about how to perform better. So it's pretty optimized.
addendum
This is from jQuery's blog:
While comprehensive benchmarks like Taskspeed can be interesting if deconstructed into individual sub-tests for further study, as a project we tend to stay away from using them as an accurate measure of true, overall, library performance. Considering how many aspects make up a library, not to mention the different techniques that they offer, cumulative results rarely reflect how an actual user may use a library.
So take that as you will.

I prefer YUI3 for larger apps and just about anywhere that 'load on demand' can offer benefits :)
I agree that slowdowns mostly stem from how you implement your app, which is one of the benefits, imho, of YUI, it lends itself naturally towards more modular implementations.
Using the yui loader to bring in page elements widget style allows for good code reuse (and caching) as well letting the user see 'something' quicker.
It won't really solve your JS ad issues though, for that, the best thing you can do is load it as near the bottom of the page as possible, and perhaps look at what loading options the adservers have.
Re: Stephen's comment
Well, raw speed for tight loops are sometimes meaningful, sometimes not. There is also the issue of the implementations used for the comparison, the YUI3 code posted in Ejohns version looks positively gimped compared to the jQuery code, look fx at the first one. Where jQuery adds almost the complete DOM element from a string while YUI3 is going thru all kinds of hoops, relatively speaking.
For a version that is written by someone who knows YUI3 have a look at http://yuilibrary.com/~msweeney/yui-tests/taskspeed/ the newest jquery isn't represented, but it does have YUI3 as ~4 times faster overall than jquery 1.3.2 in my Chrome.
Update
http://www.yuiblog.com/blog/2010/10/27/jquery-and-yui-3-a-tale-of-two-javascript-libraries/ a jquery users experience of yui3.

Probably the best place to start off is not to ask what frameworks can help but why your current site has bad performance. I would start off with tools like Yahoo's YSlow and also Dynatrace ajax edition. Dynatrace is nice because it will point out javascript/dom manip stuff that make your pages slow. You will want to use more than just two performance tools though since they all pretty much have their own idea's on what makes a page fast. Once you have that down then I would come into a forum and state that your having performance issues with X and what can I do to fix.

vapor.js is the world's smallest and fastest javascript library
http://vaporjs.com/

I think you should have a look at zepto.js
http://zeptojs.com/
this article gives you some advices for porting your jquery code
http://blog.pamelafox.org/2012/03/porting-jquery-plugins-to-zepto-tips.html

jQuery is plenty lightweight if coded properly. It sounds like which framework you are using is not the problem, but either a) why the javascript your writing is performing slowly, or b) why you are using so many slow loading ads to begin with.
But if you really want to look into other frameworks, here's a handy comparison chart: Comparison of JavaScript Frameworks

I just wrote an internal app for our company using jquery and jquery UI (http://jqueryui.com/), mixed in with c#. I found it to be extremely lean and fast - no problems whatsoever.
the jquery ui makes it easy to theme the website...
and by adding other components like blockui, jgrowl, etc you should be able to do anything you want!

Sprint is a tiny, fast alternative.
Check out the repo for benchmarks on a few functions, compared with recent versions of jQuery and Zepto.

JS Framework that doesn't use CSS selectors?

A thing that I noticed about most JavaScript frameworks is that the most common way to find/access the DOM elements is to use CSS selectors.
However this usually requires the framework to include a CSS selector parser, because they need to support selectors, that the browser natively doesn't, foremost the frameworks own proprietary extensions.
I would think that these parsers are large and slow. Wouldn't it be more efficient to have something that doesn't require a parser, such a chained method calls?
Some like:
id("example").children().class("test").hasAttribute("href")
instead of
$("#example > .test[href]")
Are there any frameworks around that do something like this? And how do they compare with jQuery and friends in regard to performance and size?
EDIT: You can consider this a theoretical discussion topic. I don't plan to use anything other than jQuery in any practical projects in near furure. I was just wondering why there aren't any other, possibly better approaches.

DOM traversal and manipulation are some of the most helpful functions in current popular JavaScript frameworks because of the way they efficiently handle cross-browser issues. If you are working with the DOM, you will eventually need that functionality, and anything you write yourself is bound to be less efficient than the best methods.
In terms of speed, I would imagine the slight performance hit from parsing the selectors would be offset by the optimization inherent in the engine. If you rely on the programmer to specify the path (i.e. your example), you may be missing out on optimization opportunities that you didn't know existed. In your example for instance, let's say that it's ultimately faster right-to-left (find all class="test" with hrefs first, then check parents). You would be relying on the programmer to memorize these optimization quirks.

Notice how much longer that is. Everyone uses CSS-style selectors for a reason.
jQuery's Sizzle library has been optimized for parser speed, so you shouldn't worry too much.

From what I've read these libraries (or JQuery atleast) use the browser native capabilities where possible. This means that you can use css selectors with minimal impact by sticking to simple id's and classes where possible.
Personally I haven't noticed any speed issues from these libraries at all. When building web apps, virtually all your speed issues come from network communications, so the best way to increase the responsiveness of your application is to reduce the number of queries you make to the server.
For example, I'll use JSON to pass and store more data in one go (even if some of it may never be needed), rather than making lots of little queries.
As hinted at by SLaks, css selectors make code readability and long term maintenance much easier and reduce coding time. And as Andrew says, these libraries also deal with the cross-browser issues for you, resulting in a much lower rate of hair loss.

Why would I want to use jQuery? [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 2 years ago.
Improve this question
(I understand that someone else asked a similar question and it was closed as 'argumentative', but I'm really interested in understanding the arguments around this.)
I know JavaScript really well. I've been writing it professionally for years. I've internalized a lot of the cross-browser incompatibilities and sketchiness, know DOM manipulation like the back of my hand, have worked with some of the best web developers in the industry & picked up a lot of their mojo.
I've been checking out jQuery. I understand the point of a javascript library (how many times have I written animation, getElementsByClass, and hide/show functions?). But to be honest, it seems like a waste of time to learn an entirely new syntax that isn't less complex. It seems like I'd be bashing my head against a wall to learn an entirely new interface to the same old JavaScript.
I'm not technically an engineer, so maybe I'm missing something. Could someone spell out the tradeoffs of jQuery? Is it really faster to learn and understand jQuery syntax than to just learn JavaScript?

There are a few big benefits to using a framework over homegrown/handwritten code:
Abstractions. I'm sure you're very proud of the fact that you've slung enough JS to be able to write animations from scratch. You should be! However, abstracting common functionality away from yourself is actually very liberating. You just call the method and know the innards will be executed, and executed well. Even if you're very fast at writing the low-level stuff yourself, that's still time you've spent on that instead of solving today's problems.
Common language. Using a common framework is like speaking a common language. You can collaborate with other developers very easily, and each can pick up where others left off without friction. (Compared to stepping into an application which uses a homegrown library for the things jQuery can do.)
Experts. The people working on jQuery are JavaScript gods. I am really, really good at JavaScript, and you probably are too, but there's a big difference between normal good and jQuery good. A team of insanely good people are constantly poring over a small set of common functionality - tuning it, tweaking it, enhancing it to make it the best it can possibly be. That represents a huge number of man-hours a single person like you or me simply cannot reproduce, no matter how good we are. And if you are as good as the jQuery guys, you can only benefit by combining your talent with theirs and contributing to the jQuery codebase. It's a melting pot of insane talent.

I'm not technically an engineer, so maybe I'm missing something. Could someone spell out the tradeoffs of jQuery? Is it really faster to learn and understand jQuery syntax than to just learn JavaScript?
jQuery is more than "just another interface" to Javascript. It allows you to express yourself in ways that are more compact and succincter than the corresponding Javascript implementation. At the same time, it's clearer and much more powerful. Specifically, the benefits you get include:
Expressiveness. jQuery is essentially a DSL for DOM manipulation and querying. This specificity is a major source of its utility and effectiveness.
Cross-browser. To a very large extent, jQuery is "write once, run anywhere". Even in 2009, this is still a surprisingly rare feat for web-based platforms. It's gratifying and relieving to know that you won't have to waste time debugging obscure problems on IE6 (well, most of the time).
Highly complete documentation. As a developer, I prize APIs and frameworks that have taken the time to spell out what all the moving pieces are supposed to be doing. Nothing is more encouraging than knowing that (1) things are stable enough that writing documentation isn't an attempt to hit a moving target and (2) things are useful enough that they've attracted enough people to flesh out the documentation fully.
In sum, the difference between Javascript and jQuery is analogous to the difference between assembly and higher-order programming languages. Although they're both technically both "an interface to machine language" and can both do similar things, the latter is considered far more powerful because of how easy it is to represent things and develop rapidly.

One thing I don't see mentioned is that the library is written to work cross browser on a wide range of popular browsers and platforms: IE6+, Firefox 2+, Safari 3+
That alone is reason enough to use jQuery then to write your own JavaScript and have to worry about cross browser issues yourself.

You can't learn jQuery without learning JavaScript, and you can't be a jQuery guru without being a JavaScript guru.
That said, it really is much faster to do things with jQuery than with "bare metal" JavaScript. Moreover, the way one works with jQuery is at a far more abstract level than the way one works with "bare metal" JavaScript. In addition, the jQuery syntax is very basic and not at all hard to learn, although the way you think about jQuery is very different from the way you think about "bare metal" JavaScript but enables you do to much more, much more rapidly.

community support
other developers writting and testing code, make it possible for you to do things you simply do not have time to do. Its not about doing anything you do not know how to do, its about doing things quickly, efficiently, and of very high quality (its already been tested).

From the sounds of it, you know much of the same stuff that jQuery knows about the DOM, and I can only assume you've built-up a nice DOM toolset for yourself over the years that incorporates all of this knowledge. In short, No, you don't need to use jQuery. However, some of the rest of us do not know as much about the DOM, and jQuery levels the playing field so we can get on with getting work done for our clients.
That is not to say you should not learn jQuery (as opposed to using it). You may pickup a few things you didn't know. The 3 main features that distinguish it from other DOM libraries (including your own probably) are:
built-in support for CSS selector syntax, useful for finding elements
methods that operate on the set of wrapped elements
chaining. Every method in jQuery.prototype (with "setter" behaviour) returns this
Personally, 1) and 3) don't hold a high premium. But 2) turns out to be huge for me. I never realized until jQuery how much my code tended towards operating on a set of nodes rather than a single node (if someone would have asked me I would have guessed the opposite tendency). 2) virtually eliminated all for loops from my code (or .forEach or however else I tended to abstract it), which was actually quite liberating. Now I notice it's the rare occasion where my code must operate on some single element.

Speed of development and turnaround of code.

One thing I haven't seen mentioned in the other answers is that, eventually, someone else is going to have to maintain your code. If it's all custom, they'll have a rougher time of it than if a more standard library is used. If that's not of any concern to you, and you don't think you're likely to need any of the really slick jQuery modules, then keep on with what you're doing.

For me, there are several benefits, like speed of development, etc.
But at the end of the day, it boils down to one thing:
It removes a HUGE amount of the cross-browser BS that can eat up so much time and resources, so I don't have to deal with it

jQuery allows you to write shorter, cleaner code that's easy to understand. Many people use it, so there are many plugins that work along with it, minimizing bloat. The same may not be true of your own personal library.

If you know JavaScript really well you should also know that jQuery's syntax isn't different from JavaScript's syntax.
What you might be referring to is the chaining idiom (used everywhere in jQuery) which seems to make things look very different from other sort of code. Well there's a reason for that, it's because it bonds really well with how the DOM works.

If you truly know JavaScript, you'll be at running speed with jQuery in under a week's time. If you don't already know your way around JavaScript, adding a layer on top might do more harm than good. But that's just like anything else!
You're going to be writing better looking and easier to understand JavaScript at a faster pace and only once — not once per browser. Downside? You're going to tack on another ~50KB of JavaScript. That's what caching is for :)

Jquery is javaScript in the hand of the designer.
It is as easy as writing CSS styles on an element.
Also Jquery is the easiest to understand, write maintain, add plugins.

I was working on a gallery program for a client (which is now exhibiting inexplicable behavior in IE6 and 7 - surprise, surprise - but I found that when I switched from bare-metal Javascript to jQuery a lot of the work got much easier. To me, it makes available the CSS view of the DOM while writing Javascript - which makes traversal and manipulation much more intuitive. Also, the cross-browser compatibility and brevity is wonderful.

It doesn't really matter if jQuery is great or awful. It's the powerhouse JS library now, used on a huge number of pages, and future browsers will have to accommodate it or be seen as themselves buggy.
What I don't like about jQuery: I'm not that thrilled about how it ignores mobile phone browsers in its test suites. It gets pulled in on all kinds of pages on mobile phones, and yet it makes no effort to ensure it works well on them.

jQuery degrades gracefully and it's one of the fastest (not THE fastest anymore though):
http://mootools.net/slickspeed/
There are many other frameworks out there, and whichever you choose, you probably wouldn't go wrong, but having uses jQuery myself, I'd definitely recommend it.
:)