8 ms·

90% Good parts of jQuery - at only 13% of the size

280 points by mythz 15y ago

numlocked 15y ago
Don't most apps reference jQuery from a CDN source (like Google)? In those cases jQuery is probably served from the browser cache. And if "those cases" are "most cases", is having a smaller version of a similar library particularly valuable?
- pamelafox 15y ago
  The parse time is significant for jQuery, atleast on some mobile devices. For example, in my tests on an Android N1 today, jQuery took 800ms to parse (even when cached) whilst Zepto took 300ms -- saving 500ms.
  - numlocked 15y ago
    Interesting. Is parse time generally a function of code length, or overall complexity/CPU time?
    - pamelafox 15y ago
      (I'm not an expert) but it's more than simply code length - it also depends on if the library runs any functions at parse time, and perhaps also how many variables it puts in the global space. For example: I discovered that my tiny localStorage library was taking 300ms to load, and that was because I was doing feature detection at parse-time and that feature detection attempted to actually set an item in localStorage. I postponed that, and got the load time down to 20ms.
  - DiabloD3 15y ago
    Google in their Page Speed ranking consider 100kb == 100ms. See: https://code.google.com/speed/page-speed/docs/mobile.html#DeferParsingJS https://code.google.com/speed/page-speed/docs/mobile.html#De... BTW, their Page Speed thing is now available online: https://developers.google.com/pagespeed/ https://developers.google.com/pagespeed/
    - dextorious 15y ago
      Parent talks about parsing speed.
      - DiabloD3 15y ago
        So does Google.
    - agentgt 15y ago
      I wonder if there is any better optimization that browsers can do for this (like at least cache the AST if the exact same JS is loaded).
  - ruethewhirled 15y ago
    Do you mind sharing what are you using/doing to benchmark that? cheers
- tfb 15y ago
  I'm considering using it because of a combination of the following: 1) You can't always count on users having cached it from the CDN. 2) If it's included on my own server I can be sure they're getting exactly what I intend and there will be less HTTP requests when I include it with the rest of my JS which will only add ~4kb. 3) I'm a bit of a minimalist when it comes to code - for the web at least.
  - wisty 15y ago
    For small libraries, and users with fast connections, the HTTP request can be the limiting factor.
    - tfb 15y ago
      The idea is to include all javascript in a single HTTP request. Sorry if that wasn't clear in point #2.
  - dextorious 15y ago
    """1) You can't always count on users having cached it from the CDN.""" No, but you can always count the MAJORITY of users will have it cached from the CDN.
    - spjwebster 15y ago
      You need to be careful with your wording here. The "MAJORITY" of the top 1m websites (based on Alexa rankings) don't use Google's CDNs (i.e. load a resource from googleapis.com): http://httparchive.org/trends.php#perGlibs http://httparchive.org/trends.php#perGlibs ...and that's across all versions of all libraries. Quite how that correlates with how many of your first-time visitors will already have the library cached – because they happen to have recently visited another site that uses the same version of the same library – depends on how much your visitor demographic intersects with those sites that use the CDN. You then need to offset that against the DNS lookup time requires for the rest of your visitors to work out whether loading the file from Google's CDN makes sense. If you're talking about repeat visitors, it doesn't matter where the file was served from, so long as you apply the correct cache-controlling headers.
- DiabloD3 15y ago
  No, a lot of HTTPS sites won't because its a security hazard and also requires a CDN that provides HTTPS as well.
  - rsoto 15y ago
    ...Which those CDN provide support as well: https://ajax.googleapis.com/ajax/libs/jquery/1/jquery.min.js https://ajax.googleapis.com/ajax/libs/jquery/1/jquery.min.js
    - ufo 15y ago
      ...but is it really worth it to give Google a "backdoor" into your https app just because you want to load jQuery faster?
      - X-Istence 15y ago
        The user most likely already is giving Google a backdoor into your app ... if they are using Chrome.
        drivebyacct2 15y ago
        What? That's absurd. You understand why that is hyperbolic, right?
        X-Istence 15y ago
        Just as absurd as Google destroying any and all confidence any of us tech people would have in them as a company if they loaded malicious javascript instead of jquery or along with jquery from their CDN's. That is the point I was trying to make.
        drivebyacct2 15y ago
        My apologies. I understand and think you make a very good point.
- jaredstenquist 15y ago
  Even though the Google Jquery libraries are used by a large number of top 100 sites, I prefer to serve my own files. 100k or 200k for the foundation of functionality that jquery provides isn't going to severely affect your visitors in any way. Of course I'm assuming you're using common best practices with cache-control/expires headers.
lunaru 15y ago
The README for this desperately needs the blacklist, not the whitelist. I care a lot more about the 10% that's missing. Unfortunately, the "limitations" sections reads fairly cryptically. I'm probably just a little slow today. Can anyone explain what's actually not included? For example are "Valid Examples" examples of what's allowed or not allowed?
- kellishaver 15y ago
  From the readme, I see two major show-stoppers for me; no .delegate() - or even .live(), and no support for the 'change' event... and I can't tell if selectors support filters like :first, :last, :checked, etc.
  - southpolesteve 15y ago
    Really no .live()? That would be a deal breaker for most of my projects
    - joshmattvander 15y ago
      .live() is lazy. You can always use the parent to delegate.
    - est 15y ago
      As of jQuery 1.7, the .live() method is deprecated. http://api.jquery.com/live/ http://api.jquery.com/live/
  - mythz 15y ago
    I think it's worth adding .delegate() to core, .live() no. I'll dive in to see how much code is required to come along with it. Also note the list to what's in core is not permanent, and can be changed by popular demand :) I still think a large part of jQuery is bloat that is rarely used.
    - kellishaver 15y ago
      Oh, I agree. It would be better to have .delegate() than .live(). I'm not bothered by the lack of .live()'s presence. I just meant that .delegate() didn't exist, and .live() wasn't there in lieu of it.
deleted 15y ago
[deleted]
ryan-allen 15y ago
The 'competitive advantage' JQuery has over the competition is the fact it's been so thoroughly tested in so many browsers for its plethora of features. I hope this library gains some traction, as I'd love to see a JQuery clone that could be modified to pass in targets as named parameters instead of the over-reliance of 'this'. Every tech seems to have an annoying something. PHP it's the order of arguments in stdlib functions, in Rails it's indirect code ruining your day, in JQuery it's 'what does this refer to again in this context?', and 'var that = this', ugh!
- padolsey 15y ago
  The jQuery annoyance you describe is a trait of JavaScript and the idea of bound function contexts. I think most of the "annoyances" that people encounter with jQuery is that "it doesn't do this really cool thing my other language/framework did/does".
  - ryan-allen 15y ago
    I disagree that it's inherent to JavaScript. I think two features that have almost ruined the language is the Function.apply and the new keyword. Function.apply is to JS as Metaprogramming and indirection is to Ruby. Features don't have a priority of use, and programmers reach for the most interesting one (and go to town misusing them). If there was no new and no Function.apply, JS would be more coherent and remain exactly as useful. It means that when an event is triggered or whatnot, rather than changing the meaning of 'this', it passes the target in as a named variable to the anon-function. Which is way better! If you constantly have to look up 'what is this set to in this callback' you're so completely doing it wrong!
    - padolsey 15y ago
      It's not something that can be resolved by simply removing `Function.apply` or the `new` operator. The way that the `this` keyword works is an integral of how JS works. There's nothing stopping you from using `Function.prototype.bind` or defining an event mechanism that retains its assigner's `this` value. That's what's so great about JS -- you have this level of control. As far as events go, having `this` set to the element receiving the event is, IMO, entirely logical, and has been a common pattern way before jQuery came into existence. You can always access the target as `event.target` if you'd prefer. If you have to look up "what is this set to in this callback" constantly, then you just need to learn the API/language.
fooyc 15y ago
I would love to be able to require() jQuery features: require(['jQuery.ajax', 'jQuery.events'], function() { // code using ajax and events here }); Much easier than to manage script tags. (hint: CommonJS / AMD)
- xal 15y ago
  The problem with that is that plain script tags can be started to load once the first TCP package of the HTML source code has been received. Your javascript tag would only be executed after all that has been loaded and the JS parser has been initialized. That can be up to 300ms to 500ms on slow and mobile devices.
  - busticated 15y ago
    RequireJS has an optimizer which concats and minifies - problem solved!
- dpe82 15y ago
  Of course nobody likes Yahoo, but this is one of the really great features of YUI.
pamelafox 15y ago
After measuring the loading performance of my PhoneGap app and seeing that jQuery took 800ms to load (even when cached), I spent the last few days porting from jQuery to Zepto, which boasts a similar API but loads in only 300ms. You can see the load times here: https://docs.google.com/spreadsheet/ccc?key=0Aq_a4WNAMuCEdDdjSlhyWXJaTkQ0TVJFc1k1RzlTTlE https://docs.google.com/spreadsheet/ccc?key=0Aq_a4WNAMuCEdDd... (You can see how I did the measurements in this post: http://www.everyday.im/learning/phonegap-loading-performance.html http://www.everyday.im/learning/phonegap-loading-performance...) While porting 6 jQuery plugins over, I encountered various differences in the APIs and it was a bit of a headache to sort through them (especially the very subtle differences), but it was worth it.I'm writing a blog post currently on my porting experience, as I imagine others might take on the task and encounter similar issues. For people comparing Zepto to this offering, keep in mind that Zepto also offers mobile-specific events, so if your reason for porting is mobile latency, Zepto's a good bet.
- deleted 15y ago
  [deleted]
  - deleted 15y ago
    [deleted]
- pamelafox 15y ago
  Update: I've now written the post about porting from jQuery to Zepto which includes my workarounds for missing jQuery functionality. If you're thinking of porting from jQuery, it should give you a good idea of what sort of stuff you'll run into: http://www.everyday.im/learning/porting-jquery-to-zepto.html http://www.everyday.im/learning/porting-jquery-to-zepto.html
- nicknyc 15y ago
  Users stay on a website for more than 800ms. Wouldn't it be more cost effective (rather than convert/port a whole site to a new js lib) to rewrite your page init JavaScript so it does not require a js lib at all (0ms)? Jquery would be async loaded by the time the user executes actions/buttons; if it had not loaded yet you wait, or show a loading icon, etc. This porting/optimization adds no value to your users 6 months from now who are running a quad core nexus-razr-droid's browser that loads jquery in 300ms.
kemayo 15y ago
"Events passed to your event handers are the 'real' browser DOM events." This is a real deal-breaker for me. One of the absolute best things about jQuery is how it normalizes events, so you don't have to care that, e.g., the source element is event.target in some browsers and event.srcElement in others.
- mythz 15y ago
  The source element is also bounded to the 'this' context. I'm curious where the other breakages are, I've normalized the events where I see that it's needed, e.g. like in the custom `$.key()` function. I think the better approach is to opt-in to receive the cross-browser normalized event in this way, i.e. via another plugin. There are a lot of cases where it doesn't matter and you don't even use the passed in jQuery event and such the overhead is otherwise not welcome.
- mythz 15y ago
  Note: jquery is also removing copying unifid props from the events, instead needing to access it in future via $.originalEvent.srcElement, etc http://blog.jquery.com/2011/11/08/building-a-slimmer-jquery/ http://blog.jquery.com/2011/11/08/building-a-slimmer-jquery/
  - shadowfiend 15y ago
    I don't think that means it's removing unified properties. I think that means that srcElement won't be copied in, but target will still refer to the right thing (i.e., to srcElement if that's what the current browser is providing). It's just not also providing a copy of srcElement for the user.
- netghost 15y ago
  If you're only targeting a subset of browsers, like say ones released in the last 4 years, it's usually fine. Though if you need to handle older versions (not just IE, all the browsers have some oddities), then it's quite helpful to have jQuery normalize them.
deleted 15y ago
[deleted]
mambodog 15y ago
Perhaps this could be jQuery's Merb, encouraging the jQuery developers to reexamine the current monolithic package. I'd appreciate a modular version that can still be built as full-size jQuery for situations in which it is convenient.
nikcub 15y ago
the jQuery project has started doing this[1]. It was at risk of ending up like PHP (in more ways than one). the core team recognizes that the API needs a trim. I also no longer use jQuery and haven't in a while because of the bloat. but I think the way they are approaching it is wrong. They want to trim the API by 10% for the next -1.8- (edit: 1.7) release. This would break semantic versioning[2]. I think they should fork the code now with a new 'jQuery 2' branch and not break any backwards compatibility in the 1.x branch. The 2.x branch should be a complete re-org with browser support as modules (for eg. if you want to support IE 6.0 you enable a module, etc.) For now, the jQuery light branch should be optional in 1.x. There are analogies in this approach with what PHP did between 4 and 5, and what Python did between 2 and 3. jQuery shouldn't be stripping out API functions in point releases, but it definitely, definitely needs a trim (and I would rather this work is done on the mainline jQuery project rather than in forks. I think a lot of devs at the moment have forks of Zepto/jQuery they run (i do)). this project may be the perfect starting point for a jQuery2 branch. i'd definitely be interested in working on that project, and bringing in features from all the various forks and cleaning it up. [1] http://blog.jquery.com/2011/11/08/building-a-slimmer-jquery/ http://blog.jquery.com/2011/11/08/building-a-slimmer-jquery/ [2] http://semver.org/ http://semver.org/ Edit: the deprecated API functions are planned for v1.7, not v1.8 - which means soon. I think it will cause a mess for people who auto-upgrade.
- johnbender 15y ago
  The most important deprecations are of live/die, though they won't be removed until 1.9. Use delegate as the replacement $("#foo").live("click", function(){ }); is equivalent to $(document).delegate( "#foo", "click", function() { });
  - masklinn 15y ago
    > Use delegate as the replacement Actually, use the new `#on` as replacement: it can handle the job of `#bind` and `#delegate` (and `#live` of course), so I'd fully expect it to be the only one remaining in the fullness of time. Warning: the first two arguments are reversed compared to `#delegate`: $(document).delegate("#foo", "click", function() { }); becomes $(document).on("click", "#foo", function() { });
deleted 15y ago
[deleted]
mmaunder 15y ago
jQuery 1.7.0 is 94K. jQuery 1.7.0 gzipped is 33K. I'm performance obsessed since if our biz serves an additional 2K on our widgets it's an extra 1.86TB of transfer/month. However for most on-site content, 33K is the size of a large image. Most delay loading a web page is caused by latency. Latency in the three way handshake to establish TCP connections and latency for each additional HTTP request even with keepalive enabled. Payload is not as big an issue because it needs fast throughput, not fast round-trip times which are impossible to achieve if you're far away from the server. Smaller and faster are always good and always worth striving for (in coding). So I don't want to take away from this, especially since it means more eyes on jQuery. I think it's great work. But keep in mind that the speed increase is not going to be enormous and the cost is running a non-standard jQuery that lacks .css(), .ajax() and $(function()).
- maximusprime 15y ago
  Don't forget the time to ungzip, the time for the js VM to parse etc.
- mythz 15y ago
  It's not just code-base size that affects performance. There's the latency of the extra network hit, parse js time, etc. $(function()) isn't included because it's generally bad practice over having javascript run immediately at the bottom before the </body> tag. If you're site doesn't use $.ajax() why include it? many sites don't use ajax. $.css() isn't included by default because it's implementation is huge. I prefer to addClass/removeClass (which only causes 1 reflow) or set element styles directly.
  - nicpottier 15y ago
    > $(function()) isn't included because it's generally bad practice over having javascript run immediately at the bottom before the </body> tag. Really? I'm not a Javascript expert but I play one on TV and I always thought $(function()) was the standard way of bootstrapping everything safely. Is the new standard really just Javascript blocks at the bottom? Would love to read more on the pros and cons, got any links?
moonboots 15y ago
The google closure tools provides this modularity automatically. The compiler removes unused functions in the google closure library.
- akrymski 15y ago
  yes that should be the way to go, not providing a library in lots of parts (i've yet to try it - how well does it work in practice?). compilers should handle this for you (linking in only the required functions) instead of distributing a library in chunks. i would also like to see jQuery versions for different browsers (kinda like Zepto for Webkit but with 100% of the APIs) - so I could compile using closure against different libraries and serve just the right stuff to different user agents. it shouldn't be hard to add user-agent specific comments to jQuery so the library could be used to produce user-agent specific versions. i think the relative popularity of zepto shows that there's a need for that.
pacomerh 15y ago
Does anyone know of an app/tool to detect only the used parts of jQuery and trim the unused?.
- rkalla 15y ago
  Google closure compiler http://code.google.com/closure/compiler/ http://code.google.com/closure/compiler/
pistoriusp 15y ago
ender.js is trying to solve this problem: http://ender.no.de/ http://ender.no.de/
- aliem 15y ago
  I am a big fan of ender, you can build a framework out of smaller specialized libraries, the Jeesh is very close to jQuery API, add reqwest and morpheus to the stack and you have the missing ajax functionality (with a cleaner interface) and a very nice and fast css tweener based upon MooTools.Tween.
dextorious 15y ago
What he has done is nice, but hardly what he says he achieved. 90% good parts of jQuery? I don't think so. The omissions, like .css, abstracted events, etc make this unfit for the majority of jQuery using projects out there. So it's more like "90% of what the author wants, YMMV" that "90% period".
orthecreedence 15y ago
I like that mootools lets you do this on your own. The builder lets you choose exactly that you want. IMO the only detriment to using Mootools over jQuery is that less people use Moo, therefor less libraries are available.

280 points by mythz 15y ago

Don't most apps reference jQuery from a CDN source (like Google)? In those cases jQuery is probably served from the browser cache. And if "those cases" are "most cases", is having a smaller version of a similar library particularly valuable?

pamelafox 15y ago
The parse time is significant for jQuery, atleast on some mobile devices. For example, in my tests on an Android N1 today, jQuery took 800ms to parse (even when cached) whilst Zepto took 300ms -- saving 500ms.
- numlocked 15y ago
  Interesting. Is parse time generally a function of code length, or overall complexity/CPU time?
  - pamelafox 15y ago
    (I'm not an expert) but it's more than simply code length - it also depends on if the library runs any functions at parse time, and perhaps also how many variables it puts in the global space. For example: I discovered that my tiny localStorage library was taking 300ms to load, and that was because I was doing feature detection at parse-time and that feature detection attempted to actually set an item in localStorage. I postponed that, and got the load time down to 20ms.
- DiabloD3 15y ago
  Google in their Page Speed ranking consider 100kb == 100ms. See: https://code.google.com/speed/page-speed/docs/mobile.html#DeferParsingJS https://code.google.com/speed/page-speed/docs/mobile.html#De... BTW, their Page Speed thing is now available online: https://developers.google.com/pagespeed/ https://developers.google.com/pagespeed/
  - dextorious 15y ago
    Parent talks about parsing speed.
    - DiabloD3 15y ago
      So does Google.
  - agentgt 15y ago
    I wonder if there is any better optimization that browsers can do for this (like at least cache the AST if the exact same JS is loaded).
- ruethewhirled 15y ago
  Do you mind sharing what are you using/doing to benchmark that? cheers
tfb 15y ago
I'm considering using it because of a combination of the following: 1) You can't always count on users having cached it from the CDN. 2) If it's included on my own server I can be sure they're getting exactly what I intend and there will be less HTTP requests when I include it with the rest of my JS which will only add ~4kb. 3) I'm a bit of a minimalist when it comes to code - for the web at least.
- wisty 15y ago
  For small libraries, and users with fast connections, the HTTP request can be the limiting factor.
  - tfb 15y ago
    The idea is to include all javascript in a single HTTP request. Sorry if that wasn't clear in point #2.
- dextorious 15y ago
  """1) You can't always count on users having cached it from the CDN.""" No, but you can always count the MAJORITY of users will have it cached from the CDN.
  - spjwebster 15y ago
    You need to be careful with your wording here. The "MAJORITY" of the top 1m websites (based on Alexa rankings) don't use Google's CDNs (i.e. load a resource from googleapis.com): http://httparchive.org/trends.php#perGlibs http://httparchive.org/trends.php#perGlibs ...and that's across all versions of all libraries. Quite how that correlates with how many of your first-time visitors will already have the library cached – because they happen to have recently visited another site that uses the same version of the same library – depends on how much your visitor demographic intersects with those sites that use the CDN. You then need to offset that against the DNS lookup time requires for the rest of your visitors to work out whether loading the file from Google's CDN makes sense. If you're talking about repeat visitors, it doesn't matter where the file was served from, so long as you apply the correct cache-controlling headers.
DiabloD3 15y ago
No, a lot of HTTPS sites won't because its a security hazard and also requires a CDN that provides HTTPS as well.
- rsoto 15y ago
  ...Which those CDN provide support as well: https://ajax.googleapis.com/ajax/libs/jquery/1/jquery.min.js https://ajax.googleapis.com/ajax/libs/jquery/1/jquery.min.js
  - ufo 15y ago
    ...but is it really worth it to give Google a "backdoor" into your https app just because you want to load jQuery faster?
    - X-Istence 15y ago
      The user most likely already is giving Google a backdoor into your app ... if they are using Chrome.
      - drivebyacct2 15y ago
        What? That's absurd. You understand why that is hyperbolic, right?
        X-Istence 15y ago
        Just as absurd as Google destroying any and all confidence any of us tech people would have in them as a company if they loaded malicious javascript instead of jquery or along with jquery from their CDN's. That is the point I was trying to make.
        drivebyacct2 15y ago
        My apologies. I understand and think you make a very good point.
jaredstenquist 15y ago
Even though the Google Jquery libraries are used by a large number of top 100 sites, I prefer to serve my own files. 100k or 200k for the foundation of functionality that jquery provides isn't going to severely affect your visitors in any way. Of course I'm assuming you're using common best practices with cache-control/expires headers.

lunaru 15y ago

The README for this desperately needs the blacklist, not the whitelist. I care a lot more about the 10% that's missing. Unfortunately, the "limitations" sections reads fairly cryptically. I'm probably just a little slow today. Can anyone explain what's actually not included? For example are "Valid Examples" examples of what's allowed or not allowed?

kellishaver 15y ago
From the readme, I see two major show-stoppers for me; no .delegate() - or even .live(), and no support for the 'change' event... and I can't tell if selectors support filters like :first, :last, :checked, etc.
- southpolesteve 15y ago
  Really no .live()? That would be a deal breaker for most of my projects
  - joshmattvander 15y ago
    .live() is lazy. You can always use the parent to delegate.
  - est 15y ago
    As of jQuery 1.7, the .live() method is deprecated. http://api.jquery.com/live/ http://api.jquery.com/live/
- mythz 15y ago
  I think it's worth adding .delegate() to core, .live() no. I'll dive in to see how much code is required to come along with it. Also note the list to what's in core is not permanent, and can be changed by popular demand :) I still think a large part of jQuery is bloat that is rarely used.
  - kellishaver 15y ago
    Oh, I agree. It would be better to have .delegate() than .live(). I'm not bothered by the lack of .live()'s presence. I just meant that .delegate() didn't exist, and .live() wasn't there in lieu of it.

deleted 15y ago

[deleted]

ryan-allen 15y ago

The 'competitive advantage' JQuery has over the competition is the fact it's been so thoroughly tested in so many browsers for its plethora of features. I hope this library gains some traction, as I'd love to see a JQuery clone that could be modified to pass in targets as named parameters instead of the over-reliance of 'this'. Every tech seems to have an annoying something. PHP it's the order of arguments in stdlib functions, in Rails it's indirect code ruining your day, in JQuery it's 'what does this refer to again in this context?', and 'var that = this', ugh!

padolsey 15y ago
The jQuery annoyance you describe is a trait of JavaScript and the idea of bound function contexts. I think most of the "annoyances" that people encounter with jQuery is that "it doesn't do this really cool thing my other language/framework did/does".
- ryan-allen 15y ago
  I disagree that it's inherent to JavaScript. I think two features that have almost ruined the language is the Function.apply and the new keyword. Function.apply is to JS as Metaprogramming and indirection is to Ruby. Features don't have a priority of use, and programmers reach for the most interesting one (and go to town misusing them). If there was no new and no Function.apply, JS would be more coherent and remain exactly as useful. It means that when an event is triggered or whatnot, rather than changing the meaning of 'this', it passes the target in as a named variable to the anon-function. Which is way better! If you constantly have to look up 'what is this set to in this callback' you're so completely doing it wrong!
  - padolsey 15y ago
    It's not something that can be resolved by simply removing `Function.apply` or the `new` operator. The way that the `this` keyword works is an integral of how JS works. There's nothing stopping you from using `Function.prototype.bind` or defining an event mechanism that retains its assigner's `this` value. That's what's so great about JS -- you have this level of control. As far as events go, having `this` set to the element receiving the event is, IMO, entirely logical, and has been a common pattern way before jQuery came into existence. You can always access the target as `event.target` if you'd prefer. If you have to look up "what is this set to in this callback" constantly, then you just need to learn the API/language.

fooyc 15y ago

I would love to be able to require() jQuery features: require(['jQuery.ajax', 'jQuery.events'], function() { // code using ajax and events here }); Much easier than to manage script tags. (hint: CommonJS / AMD)

xal 15y ago
The problem with that is that plain script tags can be started to load once the first TCP package of the HTML source code has been received. Your javascript tag would only be executed after all that has been loaded and the JS parser has been initialized. That can be up to 300ms to 500ms on slow and mobile devices.
- busticated 15y ago
  RequireJS has an optimizer which concats and minifies - problem solved!
dpe82 15y ago
Of course nobody likes Yahoo, but this is one of the really great features of YUI.

pamelafox 15y ago

After measuring the loading performance of my PhoneGap app and seeing that jQuery took 800ms to load (even when cached), I spent the last few days porting from jQuery to Zepto, which boasts a similar API but loads in only 300ms. You can see the load times here: https://docs.google.com/spreadsheet/ccc?key=0Aq_a4WNAMuCEdDdjSlhyWXJaTkQ0TVJFc1k1RzlTTlE https://docs.google.com/spreadsheet/ccc?key=0Aq_a4WNAMuCEdDd... (You can see how I did the measurements in this post: http://www.everyday.im/learning/phonegap-loading-performance.html http://www.everyday.im/learning/phonegap-loading-performance...) While porting 6 jQuery plugins over, I encountered various differences in the APIs and it was a bit of a headache to sort through them (especially the very subtle differences), but it was worth it.I'm writing a blog post currently on my porting experience, as I imagine others might take on the task and encounter similar issues. For people comparing Zepto to this offering, keep in mind that Zepto also offers mobile-specific events, so if your reason for porting is mobile latency, Zepto's a good bet.

deleted 15y ago
[deleted]
- deleted 15y ago
  [deleted]
pamelafox 15y ago
Update: I've now written the post about porting from jQuery to Zepto which includes my workarounds for missing jQuery functionality. If you're thinking of porting from jQuery, it should give you a good idea of what sort of stuff you'll run into: http://www.everyday.im/learning/porting-jquery-to-zepto.html http://www.everyday.im/learning/porting-jquery-to-zepto.html
nicknyc 15y ago
Users stay on a website for more than 800ms. Wouldn't it be more cost effective (rather than convert/port a whole site to a new js lib) to rewrite your page init JavaScript so it does not require a js lib at all (0ms)? Jquery would be async loaded by the time the user executes actions/buttons; if it had not loaded yet you wait, or show a loading icon, etc. This porting/optimization adds no value to your users 6 months from now who are running a quad core nexus-razr-droid's browser that loads jquery in 300ms.

kemayo 15y ago

"Events passed to your event handers are the 'real' browser DOM events." This is a real deal-breaker for me. One of the absolute best things about jQuery is how it normalizes events, so you don't have to care that, e.g., the source element is event.target in some browsers and event.srcElement in others.

mythz 15y ago
The source element is also bounded to the 'this' context. I'm curious where the other breakages are, I've normalized the events where I see that it's needed, e.g. like in the custom `$.key()` function. I think the better approach is to opt-in to receive the cross-browser normalized event in this way, i.e. via another plugin. There are a lot of cases where it doesn't matter and you don't even use the passed in jQuery event and such the overhead is otherwise not welcome.
mythz 15y ago
Note: jquery is also removing copying unifid props from the events, instead needing to access it in future via $.originalEvent.srcElement, etc http://blog.jquery.com/2011/11/08/building-a-slimmer-jquery/ http://blog.jquery.com/2011/11/08/building-a-slimmer-jquery/
- shadowfiend 15y ago
  I don't think that means it's removing unified properties. I think that means that srcElement won't be copied in, but target will still refer to the right thing (i.e., to srcElement if that's what the current browser is providing). It's just not also providing a copy of srcElement for the user.
netghost 15y ago
If you're only targeting a subset of browsers, like say ones released in the last 4 years, it's usually fine. Though if you need to handle older versions (not just IE, all the browsers have some oddities), then it's quite helpful to have jQuery normalize them.

deleted 15y ago

[deleted]

mambodog 15y ago

Perhaps this could be jQuery's Merb, encouraging the jQuery developers to reexamine the current monolithic package. I'd appreciate a modular version that can still be built as full-size jQuery for situations in which it is convenient.

nikcub 15y ago

the jQuery project has started doing this[1]. It was at risk of ending up like PHP (in more ways than one). the core team recognizes that the API needs a trim. I also no longer use jQuery and haven't in a while because of the bloat. but I think the way they are approaching it is wrong. They want to trim the API by 10% for the next -1.8- (edit: 1.7) release. This would break semantic versioning[2]. I think they should fork the code now with a new 'jQuery 2' branch and not break any backwards compatibility in the 1.x branch. The 2.x branch should be a complete re-org with browser support as modules (for eg. if you want to support IE 6.0 you enable a module, etc.) For now, the jQuery light branch should be optional in 1.x. There are analogies in this approach with what PHP did between 4 and 5, and what Python did between 2 and 3. jQuery shouldn't be stripping out API functions in point releases, but it definitely, definitely needs a trim (and I would rather this work is done on the mainline jQuery project rather than in forks. I think a lot of devs at the moment have forks of Zepto/jQuery they run (i do)). this project may be the perfect starting point for a jQuery2 branch. i'd definitely be interested in working on that project, and bringing in features from all the various forks and cleaning it up. [1] http://blog.jquery.com/2011/11/08/building-a-slimmer-jquery/ http://blog.jquery.com/2011/11/08/building-a-slimmer-jquery/ [2] http://semver.org/ http://semver.org/ Edit: the deprecated API functions are planned for v1.7, not v1.8 - which means soon. I think it will cause a mess for people who auto-upgrade.

johnbender 15y ago
The most important deprecations are of live/die, though they won't be removed until 1.9. Use delegate as the replacement $("#foo").live("click", function(){ }); is equivalent to $(document).delegate( "#foo", "click", function() { });
- masklinn 15y ago
  > Use delegate as the replacement Actually, use the new `#on` as replacement: it can handle the job of `#bind` and `#delegate` (and `#live` of course), so I'd fully expect it to be the only one remaining in the fullness of time. Warning: the first two arguments are reversed compared to `#delegate`: $(document).delegate("#foo", "click", function() { }); becomes $(document).on("click", "#foo", function() { });

deleted 15y ago

[deleted]

mmaunder 15y ago

jQuery 1.7.0 is 94K. jQuery 1.7.0 gzipped is 33K. I'm performance obsessed since if our biz serves an additional 2K on our widgets it's an extra 1.86TB of transfer/month. However for most on-site content, 33K is the size of a large image. Most delay loading a web page is caused by latency. Latency in the three way handshake to establish TCP connections and latency for each additional HTTP request even with keepalive enabled. Payload is not as big an issue because it needs fast throughput, not fast round-trip times which are impossible to achieve if you're far away from the server. Smaller and faster are always good and always worth striving for (in coding). So I don't want to take away from this, especially since it means more eyes on jQuery. I think it's great work. But keep in mind that the speed increase is not going to be enormous and the cost is running a non-standard jQuery that lacks .css(), .ajax() and $(function()).

maximusprime 15y ago
Don't forget the time to ungzip, the time for the js VM to parse etc.
mythz 15y ago
It's not just code-base size that affects performance. There's the latency of the extra network hit, parse js time, etc. $(function()) isn't included because it's generally bad practice over having javascript run immediately at the bottom before the </body> tag. If you're site doesn't use $.ajax() why include it? many sites don't use ajax. $.css() isn't included by default because it's implementation is huge. I prefer to addClass/removeClass (which only causes 1 reflow) or set element styles directly.
- nicpottier 15y ago
  > $(function()) isn't included because it's generally bad practice over having javascript run immediately at the bottom before the </body> tag. Really? I'm not a Javascript expert but I play one on TV and I always thought $(function()) was the standard way of bootstrapping everything safely. Is the new standard really just Javascript blocks at the bottom? Would love to read more on the pros and cons, got any links?

moonboots 15y ago

The google closure tools provides this modularity automatically. The compiler removes unused functions in the google closure library.

akrymski 15y ago
yes that should be the way to go, not providing a library in lots of parts (i've yet to try it - how well does it work in practice?). compilers should handle this for you (linking in only the required functions) instead of distributing a library in chunks. i would also like to see jQuery versions for different browsers (kinda like Zepto for Webkit but with 100% of the APIs) - so I could compile using closure against different libraries and serve just the right stuff to different user agents. it shouldn't be hard to add user-agent specific comments to jQuery so the library could be used to produce user-agent specific versions. i think the relative popularity of zepto shows that there's a need for that.

pacomerh 15y ago

Does anyone know of an app/tool to detect only the used parts of jQuery and trim the unused?.

rkalla 15y ago
Google closure compiler http://code.google.com/closure/compiler/ http://code.google.com/closure/compiler/

pistoriusp 15y ago

ender.js is trying to solve this problem: http://ender.no.de/ http://ender.no.de/

aliem 15y ago
I am a big fan of ender, you can build a framework out of smaller specialized libraries, the Jeesh is very close to jQuery API, add reqwest and morpheus to the stack and you have the missing ajax functionality (with a cleaner interface) and a very nice and fast css tweener based upon MooTools.Tween.

dextorious 15y ago

What he has done is nice, but hardly what he says he achieved. 90% good parts of jQuery? I don't think so. The omissions, like .css, abstracted events, etc make this unfit for the majority of jQuery using projects out there. So it's more like "90% of what the author wants, YMMV" that "90% period".

orthecreedence 15y ago

I like that mootools lets you do this on your own. The builder lets you choose exactly that you want. IMO the only detriment to using Mootools over jQuery is that less people use Moo, therefor less libraries are available.