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: Richard Cornford on 16 Jul 2010 14:06 Kenneth Tilton wrote: > Richard Cornford wrote: >> Kenneth Tilton recently demonstrated a similar inexperience >> based short-sightedness in his 'this site is a train wreck' >> warring; where everything on the screen is put there by >> javascript, including the warring that things may not work >> correctly, then when the javascript doesn't work correctly >> the odds are pretty good that the warning will not be shown. >> The path of the reasoning is obvious, but you have to be a little >> more experienced in the field in order to take the >> first step. > > Yeah, I am really worried about people who have JS turned off > during this stage of development when I am just running the > site to keep my morale up and sharing with programmers who > might be interested in driving qooxdoo from lisp. Not. "When the javascript doesn't work correctly" necessitates javascript's being enabled, else the javascript does not work at all. Remember that your page throws an exception as it loads, which means its initial state is not as designed (unless it was designed by a lunatic). So whatever happens after that has already become uncertain. <snip> > Tilton's Law: Solve the right problem. In this case, if the > problem is that a JS library has a bug, the solution is to > fix the bug, not burn the library and have every programmer > who wants to put up a web page spend five years learning HTML > and CSS and browser variability. <snip> Or the difference between javascript not working correctly (in the sense of 'not as designed/intended', but rather just as programmed) and javascript being disabled. It is interesting to observe that since my comments that their SELECT element imitations were flawed in that they would drop the list box out of the viewport of the browser window (rendering the contents inaccessible/unusable) qooxdoo have added some position checking code that moves the list into the viewport and puts up scrollbars when necessary. They haven't quite got this right yet as there are circumstances where if the control is partly obscured off the edge of the viewport the contents jump to move the control into the viewport (not a bad idea in itself). Unfortunately the calculations for the size/position of the list box happen before this jump, so when the jump happens it can push the edge of the list box back off the viewport, rendering parts of its content (and likely one scrollbar handle) inaccessible again. When I originally commented on this deficiency in their SELECT elements I noted that adding the code to fully reproduce the facilities that the browser would have provided was going to slow things down, and this is what I found with the new version. Viewing the qooxdoo demos on a machine with a 3.2GHz quad core processor the drop-boxes were appearing fractionally before I re-clicked the button, assuming that I had either missed or not clicked 'hard enough'(to trigger the switch) the first time. The effect was sluggish to the point of being unsatisfying, and is going to be problematic on a 2Ghz processor (or anything less powerful, which includes a good proportion of laptops and netbooks these days). Presumably qooxdoo are still hoping that Moore's law will speed up the general environment before they have finished getting all of the normal HTML facilities working properly in their UI code. Richard.
From: Garrett Smith on 17 Jul 2010 03:03 On 2010-07-16 07:40 AM, Richard Cornford wrote: > Stefan Weiss wrote: >> On 15/07/10 15:23, Richard Cornford wrote: >>> On Jul 15, 1:43 pm, Stefan Weiss wrote: >>>> No, it really did simplify the development, and it saved me >>>> a day of work. Here's the case story: a relatively simple >>>> website which didn't use a lot of JavaScript ... Lightbox >>>> clones out there. The best clone I found was a jQuery plugin. >>>> I gave it a shot and it worked very well. It may have all the >>>> drawbacks that jQuery brings with it, but in this case, I >>>> didn't care anymore. They wanted Lightbox, I gave them Slimbox2, >>>> and didn't look back. >>>> >>>> I'm not a fan of jQuery by any means, and I know its weak points >>>> well enough. In this case, however, it did save me a lot of work. >>> <snip> >>> >>> Doesn't that story boil down to 'JQuery allowed me to take the >>> money and run'? >> >> I suppose you could see it that way, > > Particularly as I tend towards the cynical. > >> if you assume the jQuery + Slimbox combination is going to cause >> trouble in the future, but Prototype.js + script.aculo.us + >> Lightbox (the customer's original request) would be >> stable. > > The 'if' supposes that those were the only two alternatives. > >> From my point of view, this replacement was already a (minor) >> improvement I was not obligated to do. >> >> In other circumstances, I would probably have bitten the bullet >> and created a Lightbox replacement myself. In this particular >> case, they'd already got 4 times the work they should have for >> my fixed fee (which they still haven't paid, by the way). > > Sometimes there are client who get what they deserve. Unfortunately > there are also clients who do not deserve what they get. > >> As a >> result, leaving them with jQuery doesn't pose a big moral problem >> for me. You can't expect me to add an additional day of work in >> this environment, just to save them the trouble of uploading a >> new jQuery version every couple of years. > > The "trouble" isn't just uploading a new JQuery version every couple of > years, it is uploading a new JQuery version and then doing a full > regression test of the functionality of the whole site, and then fixing > anything that may have been broken by non-back-compatible changes in > JQuery (and that may not be necessary every couple of years, but instead > following a first update rapidly followed three or four similar cycles > as bugfix releases rapidly follow a major version release (based on > previous releases)). Of course formal (or even effective) QA/regression > testing is nearly unheard of in general web development so its implied > expense is avoided, and in return the expense is experienced in the > negative impact of non fully functional websites going unnoticed for > indeterminate periods of time and not achieving whatever they were > intended to achieve during that time. > >> I did hesitate, and I did look for alternatives for over an >> hour. The next time I have to make this decision, hopefully >> with a fairer contract, I might go ahead and create a >> stand-alone Lightbox clone. The ones I've seen were much, >> much worse than the jQuery one. >> >> One more thing. I am a JS developer (among other things), and I >> am able to create these things if I want to. Other people, >> including many web designers > > Does "web designers" mean (effectively) graphical designers working > on/producing websites? (as distinct from 'web developers' responsible > for code/application architecture design, UI interaction design, > database design (in relation to websites), server configuration design, > and so on.) > >> and amateur bloggers, webmasters, etc, don't have that >> experience. > > No, they (mostly) do not. That is not an unexpected situation as > realistically most people do not have experience in most (more than > slightly) specialised things. Generally that is not a problem as > (effectively) we sell our own specialised experience in order to > purchase the experience (or products of the experience) we need/want of > others. And faced with a lack of experience/knowledge in an area most > people are happier (and probably better off) purchasing that experience > than trying to do it themselves. > > Almost nobody, for example, would contemplate making their own china, > even though it would not be at all physically difficult to do so (at > least using available fabrication techniques that do not include > throwing posts on a potter's wheel). There are many interesting things to do in the world and many of them are also dangerous. [...] > > So the inexperienced can easily make their own china, but they risk > doing significant harm to themselves in the process, and could create > something that is hazardous to use and unacceptably short lived. There > is much to be said for understanding the consequences of actions, > particularly in terms of avoiding the bad ones. > >> They can either use the best existing script they can find, >> or do without the functionality of Lightbox & co. I have no >> problem whatsoever when these people are using jQuery and >> its plugins. It enables them to do things they otherwise >> couldn't. The moral dilemma I was facing does not apply to >> them. > > A different moral dilemma might apply to them. Granted, if you are > talking about a complete armature doing what they like to please > themselves then any consequences (good or bad) fall only on them. But as > soon as someone is acting in the role of 'client' is involved the > consequences of design decisions are no longer local. Yet without the > experience that would have informed the 'designer' about what > consequences were likely to follow from particular design decisions no > anticipation can be exercised, and negative consequences cannot be > avoided. Which doesn't mean that there necessarily will be negative > consequences, everything may be just fine, but the point is that the > inexperienced designer will not know one way or the other. > Experience without knowledge isn't much use. I would say there are posters of this NG that are more experienced than I am (I base this on having read their stories of Netscape 3, etc), yet these same posters still post up code examples that seems to me to be in very poor judgment, using conditional comments to identify which browser might support attachEvent, etc. I was interviewed about two years ago by a senior front end engineer with 15 years experience. The first and only technical question was to build a rich text editor. He asked me to start with a TEXTAREA, and so I wrote that HTML on the whiteboard. I suspected that he was going to fall into the trap of trying to add HTML to the textarea's value and sure enough, he did just that. We proceeded for probably not much more than a minute when I mentioned that setting the TEXTAREA's `value` property to have '<' and '>' characters would result in those characters being rendered as text. I think I may have dropped that as a question, as "how are you going to get '<b>' to be parsed? I assume that he realized the problem because he ended that question right there and the interview finished soon thereafter. The rest of the interview revolved around Ext-js. Another type of thoughtless experience is copying. A third type of thoughtless experience is outright bs. Recall the example of the "enterprise level" jQuery developer who was using a namespacing technique which was nothing more than a useless call to `Function.prototype.apply` and did not create any namespace. There is no substitute for knowledge [Deming]. Blindly copying the wrong thing does not improve the situation and although it may result in a desirable outcome (as you point out below), it is only by limited luck. Recommend reading (for anyone reading this message): Carefully review each of Deming's 14 points listed on Wikipedia and for each point, consider how it applies to software development. You may find it enlightening: <URL: http://en.wikipedia.org/wiki/W._Edwards_Deming> [...] > Just yesterday I encountered what was probably another example of this > on a site that I use fairly frequently. It was my first visit to the > site since its UI had been redesigned (and AJAXed) and as I logged out I > noticed IE 8 show that strip at the top that announces that it has > blocked a pop-up. Ah, I thought, that is going to be survey about what I > think of the new UI, and as I wanted to tell them that they had rendered > it significantly slower, more clunky and expended the number of clicks > between me and what I actually wanted to do (figuring that they would > only have tested it locally and be under the impression that they had > somehow improved the site with AJAX), I used the 'allow the pop-up' > option. IE then re-loads the page in its 'pop-ups allowed' state, but of > course, being AJAXed, the site has lost its context and no longer thinks > it is my first visit to the new UI, and so no longer wants to show me > the survey pop-up. A cynic might think that the designers of the new > AJAXed UI had done that deliberately in order to avoid the survey > generating negative feedback, but, on the principle that you should > never attribute to malice anything that can be explanted by ignorance, I > concluded that web developers responsible where too inexperienced to > have taken into account the (default) behaviour of IE 8 with regard to > pop-ups. > That seems out of touch. Surveys aren't a big part of the user story. Like help (F1), these don't get top priority in testing and I've worked at out-of-touch companies that had such surveys along with foreseeresults, and omniture. They employed these because they were out of touch with the end user, did not have user stories (!) and were probably required to show some sort of accountability to the parent company (eBay). It is a public site I worked on and need not be mentioned here (it is embarrassing, but was well-paid). The problem with the survey is that when the site has problems like that, the user may just move along to the next site, unless he feels like being helpful. Instead, it is better build a user experience design that lets the user get done what he wants easily. -- Garrett
From: Stefan Weiss on 17 Jul 2010 11:59 On 17/07/10 09:03, Garrett Smith wrote: > On 2010-07-16 07:40 AM, Richard Cornford wrote: >> Stefan Weiss wrote: >>> One more thing. I am a JS developer (among other things), and I >>> am able to create these things if I want to. Other people, >>> including many web designers >> >> Does "web designers" mean (effectively) graphical designers working >> on/producing websites? (as distinct from 'web developers' responsible >> for code/application architecture design, UI interaction design, >> database design (in relation to websites), server configuration design, >> and so on.) >> >>> and amateur bloggers, webmasters, etc, don't have that >>> experience. >> >> No, they (mostly) do not. That is not an unexpected situation as >> realistically most people do not have experience in most (more than >> slightly) specialised things. Generally that is not a problem as >> (effectively) we sell our own specialised experience in order to >> purchase the experience (or products of the experience) we need/want of >> others. And faced with a lack of experience/knowledge in an area most >> people are happier (and probably better off) purchasing that experience >> than trying to do it themselves. >> >> Almost nobody, for example, would contemplate making their own china, >> even though it would not be at all physically difficult to do so (at >> least using available fabrication techniques that do not include >> throwing posts on a potter's wheel). > > There are many interesting things to do in the world and many of them > are also dangerous. The (snipped) story about the dangers of home-made china, while interesting, is not a very good analogy to what amateurs are doing on the web. At the very least, the analogy grossly exaggerates the consequences: build your own china, and people can die from lead poisoning; use a substandard script you copied from somewhere, and your homepage could break for a certain percentage of visitors. I realize that this is going to be a minority opinion in a technically oriented group such as this, but I still think that everybody - even the most clueless newcomers - should be allowed, and even encouraged, to play on the web any way they like. Let them use huge animated GIFs, background sounds, <blink> tags, UA sniffing, jQuery or any other JS library, let them proclaim that "this site is best viewed with {browser}", etc. Anything to get them interested and give them a sense of achievement. Some will become fascinated enough that they'll eventually learn how to do it right. Other's will not. I'm firmly convinced that the low barrier of entry, combined with the openness of the basic technologies is what allowed the Web to become widely accepted and grow to what we see today. Had it been necessary to hire a professional to build a homepage, none of this would have happened. The low barrier of entry has its downsides, of course. Fred (to use a random name) looks at the source code of a document, decides to try this out for himself, writes 'alert("Hello, world")', and is delighted with the result. Three days later Fred's applying for a job as a JavaScript developer. At the time, there isn't any useful certification process or formal training which can be used to decide if Fred really knows what he's talking about. I know that some companies use certifications to screen applicants, but that's a very bad practice, IMO. Many of the most talented people I've met are self trained. I've also seen some of those certifications and heard some enlightening anecdotes about how to get them in a few days, provided you know the right people or are willing to invest some cash. The technology is too new and moves too fast for these types of indicators to work. This leaves us with a gazillion web/software "developers" and even so-called "engineers", and no objective way to tell what that means. If he's got a nice homepage, and the interviewer doesn't know the right questions to ask, Fred may even get the job. And maybe he'll even grow into it, who knows. These are not the people I'm competing with. As far as I'm concerned, they're playing a completely different game. I don't offer "scripting" or "web design" or "programming". I'm hired for my experience, past successful projects, my network of colleagues with different special areas, the infrastructure I can supply, and my ability to talk to both customers and colleages in a friendly and professional manner. But the main difference to people like Fred is experience. I wrote my first program at 13. In the past 11 years, after dropping out of university, I have worked with many different OSs, on different hardware architectures, in very different organizational environments, used different languages (computer and natural), different frameworks and paradigms, alone or in teams, client side and server side, etc. This gives me a perspective that newcomers cannot possibly have, and that experience goes into my hourly rate (the project mentioned earlier notwithstanding). After hiring 2-3 Freds, customers usually want to "do it right this time" and hire an expert. >> There is much to be said for understanding the consequences of >> actions, particularly in terms of avoiding the bad ones. Absolutely. >> A different moral dilemma might apply to them. Granted, if you are >> talking about a complete armature doing what they like to please >> themselves then any consequences (good or bad) fall only on them. But as >> soon as someone is acting in the role of 'client' is involved the >> consequences of design decisions are no longer local. Everybody starts at square one. I'm not particularly proud of the work I did 12 years ago. Looking back at that time, I certainly wasn't qualified for some of the tasks I was given, but that was at the height of the dot-com bubble, and companies were desperate to hire just about anybody who knew what a computer looked like. So I got to work on real projects. I don't see any other way for newcomers to get hands-on experience. Of course, they should be honest and not inflate their own abilities, or call themselves "gurus" or "ninjas" after a year or two. Or ever ;-) > I was interviewed about two years ago by a senior front end engineer > with 15 years experience. The first and only technical question was to > build a rich text editor. Write a rich text editor from scratch? Did he want that with or without a flight simulator plugin? What an odd thing to ask as a demonstration from a job applicant. (quote reordered) > Experience without knowledge isn't much use. .... > There is no substitute for knowledge [Deming]. I respectfully disagree (with you and Prof. Deming). Knowledge can be acquired in a short time, if necessary, but experience can't. Deming died before information systems like the web made it trivially easy to retrieve required facts from online references. For example, I often don't remember the exact name or order of arguments for a method, but I know from experience that such a method exists, and that I can look it up when I need it. If I can't find the required information, I know (again, from experience) where I can ask questions and how to formulate them. There's a German expression which unfortunately can't be directly translated into English: "Fachidiot". The word describes a person who is an expert in a limited area, but ignorant about everything outside his field of expertise. Such a person would have a lot of knowledge about his area, but _experience_ goes further than that. It implies that you've seen things fail when you thought that was "impossible", it implies that you've learned how to deal with difficult co-workers, and it also implies that you can judge the consequences of your implementation on systems outside of your own area. For example, from a JS point of view, that would include issues relating to server-side proxies, security, network problems, version control, and even psychology: an experienced person will have heard about ways to improve the user perception of a piece of software, and the best way to formulate error messages. A knowledgable newcomer will still have to learn these things. -- stefan
From: John G Harris on 17 Jul 2010 12:55 On Sat, 17 Jul 2010 at 13:13:21, in comp.lang.javascript, Tim Streater wrote: <snip> >What makes anyone think that F1 is Help? <snip> Once upon a time, when IBM made Personal Computers, they invented a design standard for Graphical User Interfaces. It said, for instance, that the menu bar had File at the left hand end and Help at the right hand end. And it said that F1 is the Help key, preferably context sensitive. This standard became so common that people still assume that F1 will be the Help key, and they are often right. John -- John Harris
From: Jeremy J Starcher on 17 Jul 2010 13:55
On Sat, 17 Jul 2010 18:44:41 +0100, Tim Streater wrote: > In article > <g77VLEHICeQMFws6(a)J.A830F0FF37FB96852AD08924D9443D28E23ED5CD>, > John G Harris <john(a)nospam.demon.co.uk> wrote: > >> On Sat, 17 Jul 2010 at 13:13:21, in comp.lang.javascript, Tim Streater >> wrote: >> >> <snip> >> >What makes anyone think that F1 is Help? >> <snip> >> >> Once upon a time, when IBM made Personal Computers, they invented a >> design standard for Graphical User Interfaces. It said, for instance, >> that the menu bar had File at the left hand end > > Really? Before Apple did it? When was this then? Oh yes. [File] on the left hand end was common long before Apple. You *do* realize that we used computers long before they had graphics, don't you? Text screens that still used a 'quasi GUI' by drawing 3D effects and shadows .... I can't swear to it ... but it seems like Turbo Pascal for the CP/M machines had a 'file' drop down in the left corner and I do have a word processor for my Sol/Helios machine (running PT-DOS on an 8080 S100 bus) that has 'File' in the correct place. The next oldest machine I have prints direct to paper, so we won't count that. |