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).
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.
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.
@metachris sorry the video format didn't work for you, but you're lucky I made quite a few takes with it -- my first try was 37 minutes of unfocused babble (instead of only 12 minutes of unfocused babble).
I plan to have followup videos which walk through coding up an app from scratch. Actually, I find screencasts tedious to make. I'm very comfortable giving talks in front of people, but something about sitting and talking to my laptop doesn't sit right. :)
And persistence is underway. Jo is built from my game UI library that is about a year old now. Jo is also my fifth JavaScript framework, and first to be made open source. I'm in it for the long haul. :)
@karanbhangui Thanks! The nice part about mitigating most platform issues through CSS is that apps should degrade pretty well without much JS fiddling. I plan to continue to push into less capable web platforms, though I really could use some help testing from folks who have those devices.
Check the docs: http://joapp.com/docs/#Class%20Heirarchy a lot of the widgets are up and running. Noticeable gaps which are due to be in the beta are: select (popup selection), knob, slider, checkbox, tab, option, and typed input like numeric and email. These have been lower on my list because they're all extension of core Jo UI elements.
- it runs all the JavaScript files through jsure (similar to jslint but more configurable) to look for possible parse errors in the code
- it builds jo.js, which is the library baked into a single file
- if you have jsmin, it also makes jo_min.js which is the same thing but with no comments and extra spaces (smaller JS file). jsmin is not a strong compressor, but it is safe and readily available. Any JS compressor will work, and the Makefile will be a bit more flexible in the future to let you configure your preferred compression util.
- make also builds a local copy of the documentation (found in docs/html) from the source code and any *.mdown files in the directory tree.
Now, that's all developer stuff. If you just want to use Jo, you only need jo_min.js. Also, unless you're ready to make your own CSS, you should grab the files in css/aluminum.
I'm a Yahoo! webdev alum, and I have most of the original YUI team on my buddy list. I've paid a lot of attention to YUI3, and have some differing opinions in our approaches; probably enough to warrant a blog post... thanks for the topic idea. :)
Hopefully this month I'll have something more official. The news got leaked on Twitter a bit early, but hey, nothing like instant feedback to keep the fingers flying. :)
That said, it does play nicely inside browser-based apps, and should work alongside jQuery and other browser-centric libraries. That's something that may get explored later, but downloadable apps are definitely Jo's focus from an architectural standpoint. Thanks for your feedback, by the way.
@jafl5272 -- Jo is brand new, so it's nowhere near the maturity of YUI or jQuery yet, agreed. As for progressive loading, Jo is geared more for downloadable apps (using PhoneGap, OSX widgets, Opera widgets, Chrome Apps), so the rules of engagement are a little different (and flexible). Also, jsdoc does not have the flexibility out of the box to even handle custom events (though YUIdoc does) -- I've used both extensively, and still wanting more. I liked the idea of natrualdocs, but preferred markdown as a better plain text standard. Very readable in the source, and easy to produce decent HTML with. joDoc is primitive at the moment, but it does munge markdown comments together with auto-links and an index for now. Seems like a good start. :)
@aaronbrethorst -- this was leaked a bit earlier than I expected, so I'm scrambling to put together some more interesting sample apps. Please stay tuned, or better yet, collaborate on GitHub and help make one. :)
@detrus -- agreed that it needs a good "positioning" summary, interesting suggestion. :)