Open dfabulich opened 14 years ago
Definitely jQuery. Because of:
• The most popular JS Library, by far, based on the support forum number of discussions, shear amount of blog posts about it, and even its number one searched term based on Google trends http://kauriproject.org/wiki/g1/g4/g2/69-kauri.html.
• Extensive documentation, books, many real world examples and active support.
• The sites and companies who use it: Google, Twitter, Amazon, Microsoft (integrated into Visual Studio 2010) and even the company I work for, Amdocs, uses it as a standard now. http://docs.jquery.com/Sites_Using_jQuery.
• More than 1000 well tested plug-ins; which all are easy to implement, use, and work with each other http://plugins.jquery.com/. Plug-ins covers every aspect of Client Side programming, allowing you to focus your effort on BL only (no need to worry about Cookies, QueryString handling, JSON, XML request etc).
• Works with other JS libraries (has its own namespace).
• Animation!
• UI widgets!
• Very fast and lightweight (23kb).
• Truly cross browser, cross browser versions, and cross OS platform. Write it once, and don’t even bother checking it out in other browsers. It will behave exactly the same. http://docs.jquery.com/Browser_Compatibility
• Very easy to learn & use – even for non programmers.
• Sexy syntax (fun to use!)
• Features such as: Selectors (combination of CSS and XPath), chaining, easy attributes manipulation, easy DOM manipulation, AJAX and JSON native support (for example http://www.javascriptkata.com/2007/05/29/3-reasons-why-i-use-jquery/)
We can start by replacing small navigation parts, one at a time, until the entire site UI is jQuery based. Replacing the ChoiceScript can be done last (or someone can work on it at the same time).
It doesn’t take much time to do things with jQuery, with 2 people I estimate this could be done in two weeks.
What do you say?
For my part, I'm not excited about switching to jQuery, but I could be convinced, especially if someone (Eran?) submitted a few small, comprehensible, obviously valuable patches that used jQuery. (i.e. Don't just switch to jQuery, fix a bug with jQuery.)
Here's why I'm not so enthusiastic:
1) I don't know any jQuery, so I'd have to take time to learn it.
ChoiceScript is not my primary job, so time here is quite precious. Two weeks to replace infrastructure (without fixing bugs) doesn't sound great to me.
2) We don't use jQuery where I work (we use Dojo, a lot of it) so I couldn't really transfer that knowledge to my job.
3) I'd figured that when I switched to a JS library, I'd want one that supports Google Closure's Advanced Compilation http://code.google.com/closure/compiler/docs/api-tutorial3.html so I could cut out all the crap in the library I don't use. For now, only Google Closure supports Advanced Compilation (naturally!) and so I'd strongly considered switching to Google Closure, not jQuery.
Some people say that jQuery is so small and wonderful and lightweight that I'd never want to cut out the "crap" ... but you can really feel JS parse time on mobile phones, which is where ChoiceScript needs to perform well. (Compression doesn't reduce parse time.)
I'm concerned about the investment of time right now. Eran's arguments make some sense for why we should switch to a JS library eventually, but there's a lot of work that needs to get done on improving ChoiceScript and the development environment for ChoiceScript, and I'm not currently convinced that this should be a priority.
I'm also quite concerned about the performance issues that Dan raised-- it's vital that ChoiceScript run as fast as possible on mobile phones.
1+2) It took me couple of minutes to start writing jQuery code that actually did things. For example (taken from jQuery landing page) this code: $("p.neat").addClass("ohmy").show("slow"); Will find all paragraphs with "neat" class, add "ohmy" class to them and show them with animation. One of the cool things about it is that you can start using is gradually - and only use it when you need it. For example, I started using only the selectors, to find very quickly DOM elements (jQuery selectors are one of its best features). Then I started changing styles with .css(style-property,new-value) function. After a while I started using it more and more until it reached a point where I can't write JS without it. You can write in a few lines of jQuery what will take hundreds of native JS lines. And, you can have your time learning it slowly, since (like you suggested) I can start making small changes to site code - no need to replace the entire site in one time. As for the two weeks, this estimation takes into account that I too (like you all), have a job and life..
3) jQuery IS complied with Google Closure Compiler (http://jquery14.com/day-01/jquery-14). There is no need for partial compiling, since jQuery core functions are very light weight (23kb).
As for parse time, their latest version (1.4) has a tremendous performance improvement: http://www.stevesouders.com/blog/2010/01/15/jquery-14-performance/ As for mobile performance, go to here http://www.cs.helsinki.fi/u/pervila/Gradu/index.html Download the pdf "Gradu_final.pdf". It is the result of an extensive research done on mobile phone AJAX performance. One of the libraries they tested was jQuery (page 36), and it’s among the fastest libraries. But don’t believe me; believe Nokia that will use jQuery in all their phones from now on: http://www.geekinterview.com/blogs/152-nokia-now-on-board-with-jquery.html And soon other companies will follow.
BTW the latest jQuery version can be taken live from both Google Code and Microsoft CDN servers ( http://jquery-howto.blogspot.com/2009/09/host-jquery-on-microsoft-cdn-servers.html)
It is true that using native code CAN be faster than using a JS library, but a) It is not necessary IS faster. There are many way to do the same job with JS, and not always you know the “Best Practice” way, especially when it requires a little hacking. JS is not an easy language to write the “fastest” code with, unless you are an expert with it. b) Writing everything from scratch takes a long time, especially when you want to do it the right way. And in the end you remain with your very own private, untested JS library. Who to say it is better than other libraries? I will be very surprised if anyone can write a better performing JS code than the jQuery guys. c) The other “reason” not to use a library is that it will bring a lot of “unused code”. Well jQuery is very small, so even if you don’t end up using 100% of it, it will still be worth the extra 10k download. And that code will NOT run, since JS doesn’t run code which is not called. d) In the end there is a limit of what you can do without a library. So why wait until it’s get too complicated to change it? Trust me, when you have 10 times the amount of code you currently have, you will be very frustrated you didn’t made the switch a bit earlier.. e) And as for the effort, leave it to me. You continue working on the ChoiceScript engine (and learn a bit of jQuery) while I convert to site UI to jQuery, so there will be little waste from your time. f) And finally, look at it this way. I am currently not in the development team, so it can’t be my “waste of time” or that I have “other priorities”. If you don’t want to take my offer, than I can’t join and help you (since I am not as good with native JS like with jQuery). However, if you accept, and I join you, then you have earned yourself a “free” jQuery conversion (with the potential of my future help).
So, what will it be?
A) Accept the offer, start using jQuery, and add a good developer to your team. B) Deny the offer, passing on a great opportunity for collaboration.
You can take your time before pressing the “Next” button :)
There isn't really a "site UI" to convert to jQuery except for the ChoiceScript game itself. choiceofgames.com is nothing more than the game, three static web pages and a WordPress blog! :-)
Where jQuery would come in handy for choice script is selection of DOM elements and creation of DOM elements, also events if these are needed. It will make coding of these sections negligiiby easy.
var form = document.createElement("form"); main.appendChild(form); var self = this; form.action="#"; form.onsubmit = function() { safeCall(self, function() {self.resolveChoice(options, groups);}); return false; };
form.appendChild(document.createElement("br")); becomes something like
var safeCall = this; $('
').appendTo(body).submit( function () { safeCall(self, function() {self.resolveChoice(options, groups);}); return false; });and 9 lines of code become 5. That is about the savings I see when converting all DOM heavy javascript code to jQuery. Converting Prototype to jQuery gets slightly less but still significant savings. Not sure on Dojo.
When pulling the jquery code from the google repository, you get the benefit that most browsers already have this code cached since they have likely visited sites doing the same thing before.
Another benefit is that there are a lot of people out there that can write jQuery but cannot write javascript. Lots of designers. This would open the door for them to contribute to the hacker side of choicescript.
But I really don't know how much DOM manipulation or element selection or javascript events choicescript uses. If it doesn't do alot of these things then there isn't a lot to be gained by switching to jquery.
I fail to see the value add of jquery or yui or any other similar js lib.
But which one?