8 ms·

Zepto.js, a jQuery-compatible mobile JavaScript framework in 2K (presentation)

30 points by joshuacc 16y ago

bentruyman 16y ago
Now let's get all phone manufacturers to adopt the same version of WebKit.
- madrobby 16y ago
  Zepto.js actually goes in and fixes certain things cross-webkits; but yes, it would be good if the vendors start to make things more compatible.
- davebalmer 16y ago
  Oh how I wish. Actually, in the mobile space, this is happening. Slowly. Painfully at times, but it's not exactly too far down the horizon (bliss).
marcusbooster 16y ago
Unfortunately, as i recently saw at a demo for Windows Mobile 7, not every mobile browser uses WebKit. When the guy told me the native browser is based on IE 7, I just wanted to cry.
NathanKP 16y ago
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?
- 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. :)

30 points by joshuacc 16y ago

bentruyman 16y ago

Now let's get all phone manufacturers to adopt the same version of WebKit.

madrobby 16y ago
Zepto.js actually goes in and fixes certain things cross-webkits; but yes, it would be good if the vendors start to make things more compatible.
davebalmer 16y ago
Oh how I wish. Actually, in the mobile space, this is happening. Slowly. Painfully at times, but it's not exactly too far down the horizon (bliss).

marcusbooster 16y ago

Unfortunately, as i recently saw at a demo for Windows Mobile 7, not every mobile browser uses WebKit. When the guy told me the native browser is based on IE 7, I just wanted to cry.

NathanKP 16y ago

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?
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. :)