Hacker News Reader

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").

> 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.

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.

I'm not sure why anyone would disagree. A perfectly perfectly balanced reply in context.

Zepto has been positioned as compatible with jQuery - inviting opinion on the subject.

As the comparison was one of the core selling points of the argument for Zepto, it's actually wide open for discussion.

my response to all this craziness since I forked the original project: http://blog.millermedeiros.com/2010/10/zepto-js-and-mobile-j...

John, Zepto is _exactly_ intended for targeting bleeding-edge WebKit mobile browsers. Doesn't the README clearly state that?

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-...

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.

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.

First of all, my company just released a private beta for a large "desktop class" web application where our client flat-out told us to ignore Internet Explorer, to not use any Flash (audio playback is a big part of what it does), and to concentrate our efforts on creating the best possible user experience on Chrome, Safari, and Firefox. So much for "no one would hire them".

Right now it makes a lot of sense to only target WebKit browsers simply because it's the only decent rendering engine that's available on decent mobile phones. Zepto could easily support a mobile version of Firefox or IE once Firefox catches up in terms of performance and size and IE catches up in terms of support for HTML5, CSS3 and other emerging web standards.

Finally, stating that "web developers don't understand that distinction" sounds slightly derogatory, don't you think?

At best developing exclusively for bleeding-edge platforms is a niche-market. Is there enough interest now to hire a few developers to build HTML 5/CSS 3/etc.-only experiences? Absolutely. Is this a tenable position for anything more than a minor fraction of the web development market? No.

Companies like making money (naturally). iOS provides a clear path for them: They build an app, it goes on the app store, out to millions of people, and the money comes in. That is undisputed - you can absolutely make a nice living targeting exclusively iOS devices (by extension, WebKit-only platforms).

However this is conflating the problem space of "building mobile web applications" with "building mobile apps that use web tech". Buiding web-tech mobile apps is, functionality-wise, a sub-set of building mobile web applications. Any functionality that you would need to build a mobile web app you would also need to build a mobile app (albeit you can skim far more off the file size and functionality by targeting just apps - as Zepto has done).

jQuery is targeted at supporting "building web applications" and "building mobile web applications" - the two harder problems in the space. When you compare Zepto (designed to make it easy to build mobile apps targeted at a single platform) to jQuery (designed to make it easy to build mobile web applications targeted at many platforms) the difference is night and day.

This is the disingenuous part of this discussion: Zepto is, apparently, exclusively positioning itself against jQuery - even though they are completely dissimilar. However to the lay user that distinction is completely muddled when the API of one is directly compared to the other - when, in fact, they are nothing alike.

A better comparison would be comparing Zepto to XUI: http://xuijs.com/ XUI also targets the best-of-breed mobile platforms and makes it easy to build mobile apps.

Agree with a better comparison being XUI, but adding "jQuery" to the description gets more attention.

I have to say though John that your view of what makes a great app framework doesn't necessarily matter to everyone. I think your philosophy is executed quite well in jQuery Mobile, but that doesn't make your approach the best one for all cases.

Your choice to go for broad support actually weakens the showing of jQuery Mobile on more shiny devices compared to products which have them in mind to begin with. Does that make jQuery Mobile then inferior? Hell no! It's great, does what you set out to do, and does it well.

Thomas' pretty obvious use of the jQuery name to get some attention aside, there's nothing wrong with zepto's philosophy. It differs from yours, but it will undoubtedly have an appeal to some people or for certain projects, just probably not the same projects where someone would find jQuery Mobile appealing.

I don't think Zepto is trying to positioning itself _against_ jQuery. I think it's merely using the jQuery chaining API because it considers it an elegant design (that's actually a compliment) and to give developers something of a migration path in case their application outgrows Zepto.

> " 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."

No consumer in their right mind would use IE on a mobile :/

FWIW my webapp is 20% Chrome, 55% Firefox, 19% IE (All mainly desktop users). So dropping support for IE isn't that insane.

IE or Gecko on mobiles don't have any real significant in usage, despite IE having a board deployment. Users of less capable devices with less capable browsers will less likely use highly interactive websites because their crappy browsers can't simply handle them.

However, everyone here is constantly ignoring Opera. Opera's Presto competes head-on with Webkit in standards support and performance and has higher market share. And Opera Mobile has the best mobile UI in the market (although that's debatable due to personal preferences) and biggest feature set.

What's really a disservice and plan stupid is to outright ignore Opera and even worse not mentioning it entirely when discussing mobile app or mobile web app development.

John I tend to agree with you - and applaud the effort you've been doing with jQuery Mobile - but I also think the focus should be on mobile data usage, not device sales. In our case (and YMMV) mobile users are 80% iPhone, 10% Android and 10% everything else. That seems to be pretty par with most US-centric e-tailers. In addition the price-per-order on iPhone is much higher than the rest. Presumably because the experience on other devices doesn't lend to hanging around and buying stuff. Do we really want to develop for platforms that aren't there or for which the device handicaps the experience?

Mobile devices don't have the staying factor of desktop browsers (most users upgrade their phone/plan every 2-3 years). Shouldn't we target the best devices going forward to ensure that adoption of technology keeps up and everyone is entitled to the best experience overall?

I don't see the point of targeting webkit only for a mobile app, when mobile opera still has such a huge market share. I can see a client thinking only webkit matters because they are their minds are wrapped around buzzwords and iphones. But that is not realistic thinking - that is the client having their heads in the clouds. They won't know better than a developer, so we can either entertain them and make something target bleeding-edge only, or actually make a mobile app that more devices can see. In this office it seems like everyone in the world has a phone with a webkit browser right on it, but I know that my personal community is not the world.

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.

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.

John, you do realize that's it like a month old and in 0.1 beta, right?

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

Come back to reddit, man, we miss you :(

RTFM.

RTFCommentToWhichJohnReplied.

His reply and subsequent clarification of the criticisms is irrelevant, the original premise of the rant was off the mark. Period.