8 ms·

My question is if zepto.js is only 2k then why is jQuery 26k? What features are left out of Zepto? What are the drawbacks? Or is it just that jQuery isn't writ

My question is if zepto.js is only 2k then why is jQuery 26k? What features are left out of Zepto? What are the drawbacks? Or is it just that jQuery isn't written as efficiently as it should be?

derekdahmer 16y ago
On the backend Zepto can get away with not having to standardize different browser implementations of and bugs with things like events, DOM manipulation and selectors since its only targeting a small subset of modern platforms. It probably also gets rid of a few utilities. Whats left are what (at least I use) about 90% of the time: querying, manipulation and ajax.
jeresig 16y ago
There are a massive number number of features left out - not to mention critical functionality. Just taking a quick peek, for example if we look at .show()/.hide(): http://github.com/madrobby/zepto/blob/master/src/zepto.js#L51 http://github.com/madrobby/zepto/blob/master/src/zepto.js#L5... http://github.com/jquery/jquery/blob/master/src/effects.js#L17 http://github.com/jquery/jquery/blob/master/src/effects.js#L... There is a major case where Zepto's technique just straight-out breaks: If you are showing or hiding anything that isn't a block element. This includes inline elements, table rows, or inline-block elements. There doesn't appear to actually be anyway to unbind an event once you've attached it. Nor any way to detach all handlers of a specific type. There is not a single bug fix for querySelectorAll - this includes the fact that querying from rooted nodes is completely broken for most cases. I can keep going but yeah - there's a world of difference between Zepto and jQuery. If you're only targeting bleeding-edge WebKit mobile browsers then yeah, Zepto might be fine. However in the jQuery project we take a far more pragmatic view of web development: There are more browsers than just WebKit and the market is much more complex. You can read more about it here: http://jquerymobile.com/strategy/ http://jquerymobile.com/strategy/
- madrobby 16y ago
  John, you do realize that's it like a month old and in 0.1 beta, right?
  - jeresig 16y ago
    Sure - and when jQuery was first released it was super-tiny too. The reality is that: 1) Targeting a single platform will yield a smaller file size at the expense of market share. 2) Shooting for small file size will throw important features and functionality under the bus. I mean - either it's feature complete and it's small or it's not feature complete and its size is unknown. A large portion of the linked-to site is dedicated to the size of the library so I assumed that it was feature complete (as did most of the people in this thread).
- tvandervossen 16y ago
  John, Zepto is _exactly_ intended for targeting bleeding-edge WebKit mobile browsers. Doesn't the README clearly state that?
  - jeresig 16y ago
    Yep - and it's probably fine if you're only building apps for iOS devices - possibly Android as well. Beyond that you're getting into very shaky territory. What about Opera (the most popular mobile browser)? What about Blackberry (the second most popular mobile browser)? What about Symbian (the most popular mobile platform - which uses antiquated versions of WebKit)? http://gs.statcounter.com/#mobile_browser-ww-monthly-200909-201009 http://gs.statcounter.com/#mobile_browser-ww-monthly-200909-... It frustrates me to no end that the only JavaScript tools being developed in this day and age, for mobile platforms, exclusively target the latest WebKit: Sencha Touch, jQTouch, Zepto, etc - they all exclusively focus on the latest WebKits and it's completely baffling. No web developer in their right mind would drop support for IE - no one would hire them - and yet they seem to be fine taking that approach on mobile. Even if these tools are only being built to be used within a "safe" environment like PhoneGap - web developers don't understand that distinction. If the only tools for mobile web developers target WebKit platforms then web developers will only ever target WebKit platforms. As has been shown in the past competition is absolutely critical to the health and longevity of the browser - when one platform dominates and doesn't receive competition the platform will stagnate. Not only is targeting multiple platforms pragmatic, you get more users visiting your sites thus making you more money, but you also help the health of the mobile web as a whole: Pushing more browsers to compete better and provide an improved experience to all users.
    - madrobby 16y ago
      I'm sorry, but I really don't care if it "frustrates you to no end". I want to make the best mobile web apps possible for modern smart phones, and those happen to use WebKit. I don't want to be restricted by implementing something what works on every mobile browser (do you still support WAP?). Again, I want to build the most amazing applications. If that means some browsers can't show it, well, too bad. I'm doing the web a disservice because I release a library that only works with one mobile browser? The web as a whole will suffer from that? What do you know about my customers? What do you know about the sites and apps I want to create? And web developers aren't smart enough to understand the difference between developing for PhoneGap and the web? Please don't lecture me about making money and about making awesome user experiences. I can very well take care of that myself, thank you.
- madrobby 16y ago
  Qoute: "with a jQuery-compatible syntax (lots of the jQuery API is supported!)" That's true. Lot's of it is. Some of it is not. And yes, it targets bleeding edge WebKit mobile browsers. Yes, some of it is broken and doesn't work correctly yet. Some of it fixes bugs that jQuery doesn't fix AFAIK (like memory leaks on asset removal on iOS devices). It's an early beta. And it does it all in 2K. I don't care about what the jQuery project does, and how it takes "a far more pragmatic view of web development"; Zepto.js doesn't want to be a do-it-all-works-everywhere-project; so I really don't get your condescending tone ("just taking a quick peak...", "straight-out breaks", "missing critical functionality", "broken for most cases", "I can keep on going", "...might be fine").
  - jeresig 16y ago
    > Lot's of it is. (Zepto is broken across multiple files so I might be missing some functionality.) Roughly, Zepto has this many properties/method: On $: 5, On $.fn: 32. jQuery has: On $: 95, On $.fn: 146. Phrases like "jQuery-compatible syntax (lots of the jQuery API supported!)" make it seem like you can just rip jQuery out of an application and drop Zepto in - and it'll just work. Zepto only supports about 15% of the jQuery API - I'm very skeptical that any major jQuery plugin would "just work" given the provided API. Framing the marketing within the context of jQuery (or, really, even Prototype) is disingenuous and creates a deceptive message. A better way to market the code would be: "Zepto provides a simple API for making JavaScript awesome in the latest WebKit mobile browsers - all in 2KB!" That's 100% accurate and frames the code in a way that users will be able to grasp (2KB is nothing! It'll make my code simpler when I build my next PhoneGap app!). Whereas framing it within the context of jQuery doesn't benefit Zepto - it doesn't support more than one platform and it doesn't support the full jQuery API.
    - davebalmer 16y ago
      Have to agree with John here. All the zepto promotion efforts I've seen have been playing up "jQuery-compatible", but that's pretty misleading. Seems like using the "jQuery" buzzword to get attention, but not exactly delivering the goods.
    - 16y ago
- fermion 16y ago
  RTFM.
  - mathias 16y ago
    RTFCommentToWhichJohnReplied.
    - fermion 16y ago
      His reply and subsequent clarification of the criticisms is irrelevant, the original premise of the rant was off the mark. Period.
- dam5s 16y ago
  When I developed i.three.com.au for my former employer, I would have loved to have Zepto.js... It's an iPhone and Android only website. Would have been perfect! Zepto.js and jQueryMobile have different purposes, just deal with it.
- superk 16y ago
  I had this problem with XUI (and even Madrobby's brilliant Emile - although that's mostly a proof of concept). The library is just beneath what I consider necessary in terms of flexibility and robustness to be usable in production. Like no error handler in Zepto Ajax - seriously? An Ajax request will never fail... on mobile!? And this could be my perception - and I could be completely wrong - but when something is marketed as 'in only 2K!' or 'in under 50 lines!' there's a discouraging resistence to adding code in order to keep those metrics. On the other hand, most micro-frameworks require the user to take more responsibility for making sure things don't break - which could mean lighter code... a good thing for mobile. For example, Emile does a fine job of tweening integers or colors, but watchout for inherited values - like fontWeight 'normal'. So the user has to take the extra step of defaulting the styles to values the script can work with.
- robinduckett 16y ago
  Come back to reddit, man, we miss you :(
vladocar 16y ago
jQuery is build to support IE end every other browser so contains double code. One for IE and other for every other browser.
- paulirish 16y ago
  You clearly have a problem constructing sentences that contain facts.
points 16y ago
2k = 95% of what you'll ever need. FWIW browser differences are always vastly overplayed by 'framework' developers.
- davebalmer 16y ago
  Yes, it's a giant conspiracy by us "framework" developers to try and save you a little coding effort. :)
  - points 16y ago
    shrug pretty much. The issue is that framework docs are often better than js docs. So instead of people sitting down with a decent js book and learning the right way to do something, they just use a framework. The fact that pretty much all js frameworks periodically announce speedups of 50%+ should ring alarm bells.
    - DaveStein 16y ago
      I can actually code JS fine without a framework. However do I want to keep up to date with all the idiosyncrasies of a growing number of browsers? Do I want to rewrite every function that exists in a framework, such as getting the height of an element or the viewport? No. The speedups in frameworks are realizations of better ways to do things that a group of programmers came up with - which is almost definitely going to be a better way of doing things outside of a community. That argument would only work if your functions were always as fast as possible at start. Don't forget Chrome was already the fastest browser out there for JS, and they still have improvements of 50%+ in updates.
    - davebalmer 16y ago
      Wow, if you code half as well as you can over-generalize, you must be a JavaScript god. But seriously, frameworks and smaller code libraries should be used when do something useful. If you don't find a framework useful, don't use it. And if you find that you're copying code from project to project, make your own library. This is all pretty simple stuff, I guess you just wanted an excuse to flex your amazing JavaScript ninja muscles on the internets. Your point about framework docs being better than JS docs is a little puzzling. I think the folks at Mozilla.org would take issue. Plus, there is at least one very excellent JS book ("JavaScript: The Good Part", Crockford) out there to get people started, and most of the silly "Learn JavaScript in 24hours" type books aren't on any JS dev's bookshelf that I've seen (except as a joke). Relax and go back to coding. :)

My question is if zepto.js is only 2k then why is jQuery 26k? What features are left out of Zepto? What are the drawbacks? Or is it just that jQuery isn't written as efficiently as it should be?

derekdahmer 16y ago

On the backend Zepto can get away with not having to standardize different browser implementations of and bugs with things like events, DOM manipulation and selectors since its only targeting a small subset of modern platforms. It probably also gets rid of a few utilities. Whats left are what (at least I use) about 90% of the time: querying, manipulation and ajax.

jeresig 16y ago

There are a massive number number of features left out - not to mention critical functionality. Just taking a quick peek, for example if we look at .show()/.hide(): http://github.com/madrobby/zepto/blob/master/src/zepto.js#L51 http://github.com/madrobby/zepto/blob/master/src/zepto.js#L5... http://github.com/jquery/jquery/blob/master/src/effects.js#L17 http://github.com/jquery/jquery/blob/master/src/effects.js#L... There is a major case where Zepto's technique just straight-out breaks: If you are showing or hiding anything that isn't a block element. This includes inline elements, table rows, or inline-block elements. There doesn't appear to actually be anyway to unbind an event once you've attached it. Nor any way to detach all handlers of a specific type. There is not a single bug fix for querySelectorAll - this includes the fact that querying from rooted nodes is completely broken for most cases. I can keep going but yeah - there's a world of difference between Zepto and jQuery. If you're only targeting bleeding-edge WebKit mobile browsers then yeah, Zepto might be fine. However in the jQuery project we take a far more pragmatic view of web development: There are more browsers than just WebKit and the market is much more complex. You can read more about it here: http://jquerymobile.com/strategy/ http://jquerymobile.com/strategy/

madrobby 16y ago
John, you do realize that's it like a month old and in 0.1 beta, right?
- jeresig 16y ago
  Sure - and when jQuery was first released it was super-tiny too. The reality is that: 1) Targeting a single platform will yield a smaller file size at the expense of market share. 2) Shooting for small file size will throw important features and functionality under the bus. I mean - either it's feature complete and it's small or it's not feature complete and its size is unknown. A large portion of the linked-to site is dedicated to the size of the library so I assumed that it was feature complete (as did most of the people in this thread).
tvandervossen 16y ago
John, Zepto is _exactly_ intended for targeting bleeding-edge WebKit mobile browsers. Doesn't the README clearly state that?
- jeresig 16y ago
  Yep - and it's probably fine if you're only building apps for iOS devices - possibly Android as well. Beyond that you're getting into very shaky territory. What about Opera (the most popular mobile browser)? What about Blackberry (the second most popular mobile browser)? What about Symbian (the most popular mobile platform - which uses antiquated versions of WebKit)? http://gs.statcounter.com/#mobile_browser-ww-monthly-200909-201009 http://gs.statcounter.com/#mobile_browser-ww-monthly-200909-... It frustrates me to no end that the only JavaScript tools being developed in this day and age, for mobile platforms, exclusively target the latest WebKit: Sencha Touch, jQTouch, Zepto, etc - they all exclusively focus on the latest WebKits and it's completely baffling. No web developer in their right mind would drop support for IE - no one would hire them - and yet they seem to be fine taking that approach on mobile. Even if these tools are only being built to be used within a "safe" environment like PhoneGap - web developers don't understand that distinction. If the only tools for mobile web developers target WebKit platforms then web developers will only ever target WebKit platforms. As has been shown in the past competition is absolutely critical to the health and longevity of the browser - when one platform dominates and doesn't receive competition the platform will stagnate. Not only is targeting multiple platforms pragmatic, you get more users visiting your sites thus making you more money, but you also help the health of the mobile web as a whole: Pushing more browsers to compete better and provide an improved experience to all users.
  - madrobby 16y ago
    I'm sorry, but I really don't care if it "frustrates you to no end". I want to make the best mobile web apps possible for modern smart phones, and those happen to use WebKit. I don't want to be restricted by implementing something what works on every mobile browser (do you still support WAP?). Again, I want to build the most amazing applications. If that means some browsers can't show it, well, too bad. I'm doing the web a disservice because I release a library that only works with one mobile browser? The web as a whole will suffer from that? What do you know about my customers? What do you know about the sites and apps I want to create? And web developers aren't smart enough to understand the difference between developing for PhoneGap and the web? Please don't lecture me about making money and about making awesome user experiences. I can very well take care of that myself, thank you.
madrobby 16y ago
Qoute: "with a jQuery-compatible syntax (lots of the jQuery API is supported!)" That's true. Lot's of it is. Some of it is not. And yes, it targets bleeding edge WebKit mobile browsers. Yes, some of it is broken and doesn't work correctly yet. Some of it fixes bugs that jQuery doesn't fix AFAIK (like memory leaks on asset removal on iOS devices). It's an early beta. And it does it all in 2K. I don't care about what the jQuery project does, and how it takes "a far more pragmatic view of web development"; Zepto.js doesn't want to be a do-it-all-works-everywhere-project; so I really don't get your condescending tone ("just taking a quick peak...", "straight-out breaks", "missing critical functionality", "broken for most cases", "I can keep on going", "...might be fine").
- jeresig 16y ago
  > Lot's of it is. (Zepto is broken across multiple files so I might be missing some functionality.) Roughly, Zepto has this many properties/method: On $: 5, On $.fn: 32. jQuery has: On $: 95, On $.fn: 146. Phrases like "jQuery-compatible syntax (lots of the jQuery API supported!)" make it seem like you can just rip jQuery out of an application and drop Zepto in - and it'll just work. Zepto only supports about 15% of the jQuery API - I'm very skeptical that any major jQuery plugin would "just work" given the provided API. Framing the marketing within the context of jQuery (or, really, even Prototype) is disingenuous and creates a deceptive message. A better way to market the code would be: "Zepto provides a simple API for making JavaScript awesome in the latest WebKit mobile browsers - all in 2KB!" That's 100% accurate and frames the code in a way that users will be able to grasp (2KB is nothing! It'll make my code simpler when I build my next PhoneGap app!). Whereas framing it within the context of jQuery doesn't benefit Zepto - it doesn't support more than one platform and it doesn't support the full jQuery API.
  - davebalmer 16y ago
    Have to agree with John here. All the zepto promotion efforts I've seen have been playing up "jQuery-compatible", but that's pretty misleading. Seems like using the "jQuery" buzzword to get attention, but not exactly delivering the goods.
  - 16y ago
fermion 16y ago
RTFM.
- mathias 16y ago
  RTFCommentToWhichJohnReplied.
  - fermion 16y ago
    His reply and subsequent clarification of the criticisms is irrelevant, the original premise of the rant was off the mark. Period.
dam5s 16y ago
When I developed i.three.com.au for my former employer, I would have loved to have Zepto.js... It's an iPhone and Android only website. Would have been perfect! Zepto.js and jQueryMobile have different purposes, just deal with it.
superk 16y ago
I had this problem with XUI (and even Madrobby's brilliant Emile - although that's mostly a proof of concept). The library is just beneath what I consider necessary in terms of flexibility and robustness to be usable in production. Like no error handler in Zepto Ajax - seriously? An Ajax request will never fail... on mobile!? And this could be my perception - and I could be completely wrong - but when something is marketed as 'in only 2K!' or 'in under 50 lines!' there's a discouraging resistence to adding code in order to keep those metrics. On the other hand, most micro-frameworks require the user to take more responsibility for making sure things don't break - which could mean lighter code... a good thing for mobile. For example, Emile does a fine job of tweening integers or colors, but watchout for inherited values - like fontWeight 'normal'. So the user has to take the extra step of defaulting the styles to values the script can work with.
robinduckett 16y ago
Come back to reddit, man, we miss you :(

vladocar 16y ago

jQuery is build to support IE end every other browser so contains double code. One for IE and other for every other browser.

paulirish 16y ago
You clearly have a problem constructing sentences that contain facts.

points 16y ago

2k = 95% of what you'll ever need. FWIW browser differences are always vastly overplayed by 'framework' developers.

davebalmer 16y ago
Yes, it's a giant conspiracy by us "framework" developers to try and save you a little coding effort. :)
- points 16y ago
  shrug pretty much. The issue is that framework docs are often better than js docs. So instead of people sitting down with a decent js book and learning the right way to do something, they just use a framework. The fact that pretty much all js frameworks periodically announce speedups of 50%+ should ring alarm bells.
  - DaveStein 16y ago
    I can actually code JS fine without a framework. However do I want to keep up to date with all the idiosyncrasies of a growing number of browsers? Do I want to rewrite every function that exists in a framework, such as getting the height of an element or the viewport? No. The speedups in frameworks are realizations of better ways to do things that a group of programmers came up with - which is almost definitely going to be a better way of doing things outside of a community. That argument would only work if your functions were always as fast as possible at start. Don't forget Chrome was already the fastest browser out there for JS, and they still have improvements of 50%+ in updates.
  - davebalmer 16y ago
    Wow, if you code half as well as you can over-generalize, you must be a JavaScript god. But seriously, frameworks and smaller code libraries should be used when do something useful. If you don't find a framework useful, don't use it. And if you find that you're copying code from project to project, make your own library. This is all pretty simple stuff, I guess you just wanted an excuse to flex your amazing JavaScript ninja muscles on the internets. Your point about framework docs being better than JS docs is a little puzzling. I think the folks at Mozilla.org would take issue. Plus, there is at least one very excellent JS book ("JavaScript: The Good Part", Crockford) out there to get people started, and most of the silly "Learn JavaScript in 24hours" type books aren't on any JS dev's bookshelf that I've seen (except as a joke). Relax and go back to coding. :)