jquery vs dojo vs yui etc
in [JavaScript]
|
Prev: Interactive web-based graphs for iPads?
Next: FAQ Topic - How can I disable the back button in a web browser? (2010-06-17)
From: Bwig Zomberi on 18 Jun 2010 02:27 Joe Nine wrote: > Bwig Zomberi wrote: >> Joe Nine wrote: >>> I've seen enough examples of code that's using jQuery on here to know >>> that I don't want to become a jQuery programmer - it's like it's own new >>> language with an ugly perl-like syntax. I guess it's one for the >>> programmers that prefer unix. I'm a windows guy myself and like "classic >>> syntax" languages. I guess that's why I've never got into complex >>> regular expressions either. >> >> Javascript syntax is based on C or Java if you like. > > I know. I imagine everyone here does. > >> C was first written for Unix, which was written for the most part in C. > > I learned that in class too. I don't see the relevance to anything though. > >> jQuery is born ugly. Unix played no part in its birth or parenting. > > I doubt anyone thinks it has any relation to unix. Good to know that you know. Then why imply Unix/Linux users should be the ones to like jQuery, when those guys would mostly prefer C or C-like languages. Classic syntax is a mainstay of many Unix-origin languages - it is not a Windows-only trait. Difficult syntax is not alien to Windows - Hungarian notation used in VC++ for example. -- Bwig Zomberi
From: Bwig Zomberi on 18 Jun 2010 05:19 Tim Streater wrote: > In article > <7313e001-78c8-4b17-aa39-72e5a420eb2c(a)i28g2000yqa.googlegroups.com>, > Matt Kruse<matt(a)thekrusefamily.com> wrote: > > [stuff] > > After all these posts, I'm none the wiser: what is the problem these > libraries are trying to solve? > A single and smaller codebase for users to implement special effects if sites like Smashing Magazine are to be believed. The libraries are expected to do the heavy lifting and fix browser issues. Libraries also seem to provide shorthand for JavaScript. I never got tired of using document.getElementById or DOM array parsing. In fact, I feel safe with it. -- Bwig Zomberi
From: Thomas 'PointedEars' Lahn on 18 Jun 2010 08:11 Garrett Smith wrote: > Thomas 'PointedEars' Lahn wrote: >> Garrett Smith wrote: >>> Thomas 'PointedEars' Lahn wrote: >>>> Garrett Smith wrote: >>>>> I've looked for, but found no unit tests. If I'm going to use >>>>> something, I want to run tests on it to verify the edge cases. >>>> What's wrong with JsUnit?<http://www.jsunit.net/> >>> [...] >>> * No asynchronous testing features. >> How do you propose that to be implemented? > > wait and waitForCondition can each use setTimeout. > [...] > I explained a little recently in MessageID: > hv3v71$km$1(a)news.eternal-september.org Thanks. >> Which alternatives to JsUnit are you recommending? > > The most relevant I found at the time I was searching was YUI Test > > I've run into too many problems with that. [...] > In 2007, I found that YUI Test was attractive. The limitations have > become so burdensome that it is time to move on. This reads to me as if you are saying that you do not like several aspects of JsUnit, but you do not know anything that is better. Would it not be a good idea to help improve JsUnit then? Please trim your quotes to the relevant minimum. PointedEars -- realism: HTML 4.01 Strict evangelism: XHTML 1.0 Strict madness: XHTML 1.1 as application/xhtml+xml -- Bjoern Hoehrmann
From: Thomas 'PointedEars' Lahn on 18 Jun 2010 08:37 Tim Streater wrote: > Matt Kruse wrote: >> Tim Streater wrote: >> > After all these posts, I'm none the wiser: what is the problem these >> > libraries are trying to solve? >> >> The goal of any library/framework/layer/abstraction is to simplify the >> solution to one problem, so it can be used as a foundation for solving >> a bigger problem. > > [snip] > >> JS Libraries, as a way to abstract away the problems with browser >> scripting, may not be the *best* solution. But it is one solution, and >> it works very well for many people. I think it's great to argue for >> different ways to abstract away the problem, and pick the option that >> is best. But IMO, rejecting the abstraction altogether because of its >> shortcomings is short-sighted. Web development will move on without >> these detractors. Libraries will be used and improved, because people >> don't want to have to deal with the whole nasty, confusing browser >> scripting layer. They want it solved, at least to a degree that they >> are comfortable with, and presented in a nicer, easier-to-use form. >> That's what libraries like jQuery do, and that's why people so >> overwhelmingly choose to use them. > > Mmm, thanks. The concept is clear, I'm not sure whether I buy the > argument. Add me. Matt is still not getting that (JS) libraries as a concept are not the issue, but the people writing them. If those are clueful, experienced individuals, the library can grow naturally from practice, evolutional from the general case to the special one so that one reliable abstraction layer is placed upon another *when necessary*, and it can become useful for both a single project and several projects, both for the original authors and other people. If instead the individual or group of authors are actually clueless newcomers in the field and/or people with delusions of grandeur, who like to present themselves as gurus, ninjas, and the like to begin with, the library they will be writing will end up being bloated, unmaintainable code that attempts to solve problems that did not need a solution in the first place. It must fail badly at doing so, and it will create more problems than it claims to solve. It only takes a few equally unexperienced and naive people to use it and, from superficial testing, advocate using it to other equally unexperienced/naive people for it to become a hype, even a cult, then. The evidence for this can hardly be ignored. > I've had a brief look at JScript, looks harder than JavaScript to me. How so? You are involuntarily writing JScript if you are writing "JavaScript"/"Javascript"/"javascript" for IE/MSHTML, so it can't be that hard to do. PointedEars -- Prototype.js was written by people who don't know javascript for people who don't know javascript. People who don't know javascript are not the best source of advice on designing systems that use javascript. -- Richard Cornford, cljs, <f806at$ail$1$8300dec7(a)news.demon.co.uk>
From: Matt Kruse on 18 Jun 2010 10:12
On Jun 18, 7:37 am, Thomas 'PointedEars' Lahn <PointedE...(a)web.de> wrote: > Matt is still not getting that (JS) libraries as a concept are not > the issue, but the people writing them. Umm, that's not at all what the mantra has been in here for years. Over and over and over it has been said by many that general-purpose javascript libraries are a bad idea. My point has always been that general-purpose js libraries are a _must_, and if the people with the skill to write them correctly don't do so, then someone else will. And other people have. jQuery has lots of problems. The coding of it and its design and the way the authors attack problems are all quite poor. But it fills a need. Even when someone like DM comes along and writes "His Library", he's missing the point. He may get the technical aspects more correct, but he lacks the vision and social grace required to make the library actually useful to most developers. It's like he's created a better mousetrap, but completely drops the ball on manufacturing, marketing, and distribution. Whereas something like jQuery suffers from poor quality, but gets the other stuff right. Turn on any infomercial and see how ridiculous the product is, yet see how many people buy it and how rich the creators are. It doesn't matter how great of a product you create if you can't get it out to the masses! And if the masses are creating terrible web sites full of broken script, and this is the problem that DM is trying to address, then he's doing it wrong. Even though it seems to drive DM crazy, the truth is that John Resig is a much better salesman, and his product is beating the pants of DM's "higher quality" product. I still believe that the way to combat jQuery and to help fix all the junk that it has spewed on the web is to create a library with a compatible subset of the jQuery API, and implement it correctly. Then people can switch over to it easily and comfortably, and get the benefit of more robust code. Matt Kruse |