Dan Webb makes an excellent observation about the difference between programming in JavaScript for the browser compared to programming just about any other language in any other environment:
File size / download time arguments aside, the less code you can get away with having the browser parse and execute the better off you are. Less for the browser to do. Less to go wrong. Less to try to understand. In JavaScript development, I think this need for minimalism is as important as the need to write code for re-use which is one of the major aspect in which it differs from traditional software development wisdom.
With that said, he then goes on to list the basic JavaScript functions that he uses time and time again. The usual suspects are in there: event handling, getting elements by class name, etc. It’s pretty similar to Robert Nyman’s somewhat-provacatively titled The only JavaScript library you’ll ever need.
Like Robert, I have a very cautious attitude when it comes to the wholesale use of third-party libraries. Let me clarify something , though: I am not anti-library. I just think that they need to be used correctly by people who know how they work (an attitude that Stuart Langridge characterises as “elitist”).
Building up your own library, on the other hand, is something I wholeheartedly approve of. I’m pretty sure it’s something that just about every developer does anyway, but it really is a great way of accumulating wisdom… wisdom being knowledge over time.
The danger, then, is knowledge without the benefit of personal experience. This is where third-party libraries could be hazardous (I really need to qualify everything I say here for fear of getting branded as being zealously anti-library, which I am not). But it’s complete understandable when developers simply don’t have the time to truly grok JavaScript because deadlines are looming and the site they’re working on needs to be done right now. My sympathies are with those developers and I completely understand how libraries are a godsend in that situation. I guess what I really don’t like isn’t the libraries per se, but the situations in which they’re often used (if only we could write a library that abstracted deadlines and obfuscated bosses).
Something I very much like about libraries is that they provide a motherlode of code from which developers can pluck the gems they like. Rather than an “all or nothing” approach, I think it’s healthy to see people sifting out the bits they really like, be it an elegant Ajax shortcut or a time-saving replacement for long-winded DOM methods.
I haven’t really looked very closely at the licenses under which the major libraries are released, but I’m assuming that this kind of scrapheap scavenging is allowed, or possibly even encouraged. Of course, I could be completely wrong about that so I’d better go and have a closer look at the fine print before I decide to appropriate a useful function for my own personal code collection.
Posted by Jeremy on Thursday, January 11th, 2007 at 1:09pm
Comments
Well, I do agree with you that the extense use of libraries is a problem, however I’m not sure I agree with the reasons.
One caveat that is inherent to the web is that is very easy to copy and paste some code and actually have something very quickly.
If you are the kind of guy that hdan’t a particular idea in mind when started (like a real designer would), you may be pleased with just about anything under the sun. If someone else enjoy your work, you are halfway to be a self-proclaimed web-developer or web-designer.
I think libraries are just a facet of this wider problem.
Of course if you write your on library is because you are good enough to be using it, and that gives a sure shot about quality. But if the web is to be even more resourceful and start to show features that today are only available to standalone applications, then, 3rd party libraries will be necessary, just as they are today in traditional SW develpment.
Even further, if Ajax is to succed, it will probably be managed through some standard libraries, instead of handcrafted code, which will be a nice thing for serious developers, as well as the bad ones.
Oops, I think I should have written a shorter comment, sorry for that.
# Posted by Guilherme Zühlke O'Connor on Thursday, January 11th, 2007 at 2:56pm
When digital music technology became affordable in the late 80s, similar things were said - an "elitist" attitude was that it allows people who know nothing about music to make music, and that undermines the artform as a whole. A "grass roots" attitude was that this is a good thing, because then creating musical art is no longer the preserve of highly trained specialists and the rare few who are naturally gifted - now anyone can do it, and surely that can only be a good thing?
The difference is that making music doesn’t come with accessibility problems built in - nobody relies on techno to pay their bills; you don’t need drum ‘n’ bass to read the news and keep in touch with the world, and if house music makes no sense to you then you haven’t actually lost anything in practical terms.
But with web development it’s different - it matters that what we produce is right under the hood, because what you don’t see does matter! And that’s why I side with the "elitist" view in this case - frameworks and APIs are useful for fast prototyping, they have a role to play in allowing for more agile development cycles, but the vast majority of them pay no regard to accessibilty, and those that do still need to be handled with care and skill.
Therefore I would hesitate to use any framework without knowing exactly how it works, and testing it myself in every target environment. It’s not that I don’t trust Mr Resig, it’s just that every situation is unique and it’s impossible to predict every contingency - it’s not until you have your code running in it’s final situation that you can test whether it really works.
# Posted by brothercake on Friday, January 12th, 2007 at 12:47am
Jeremy, I agree with you completely! Excellent blog entry.
# Posted by Stephen Stchur on Friday, January 12th, 2007 at 5:43am
Agreed on the point about libraries being hazardous. What I’d like to see is libraries deliberately encouraging people to use progressive enhancement, and penalising those who don’t. One example I just thought up over at ppk’s blog is that of having the library refusing to attach onclick handlers to an A element with an href of "#" or "javascript:*". I’d like to see library owners take some social responsibility for the quality of the code that uses them. This is where the @media "guns in the hands of children" argument is thrown into sharp relief; gun manufacturers take the NRA "guns don’t kill people, people kill people" approach to responsibility, where you just say "it’s not our fault if people use our product wrong". Making a gun that knows who it’s pointing at is hard. Making a library that knows how it’s being used might be hard and might not; no-one’s really tried very hard (because the NRA abdication of liability approach is a lot easier). Why don’t we start thinking about that; we could (at least try to) fix one of the major objections to libraries by having them explicitly act as a force for good?
# Posted by Stuart Langridge on Friday, January 12th, 2007 at 8:23am
Stuart: Penalising people for doing things wrongly is quite a hardcore. I’d prefer libraries that make progressive enhancement the path of least resitance rather than just not letting you do certain things which seems a little bit patronising to me.
Making the ‘best practice’ ways to do things easy in the case of a JS library would be things like making DOM navigation easier, providing a DOMContentReady event cross browser and easy and performant ways of selecting elements via CSS selectors or class names. jQuery does quite well at this and for that reason we see alot more unobtrusive code coming out of the jQuery camp than say the Dojo or Prototype camps. Prototype is actually missing alot of functionality in these important areas at the moment which is why I put together Low Pro. It contains all the bits missing from Prototye than I needed to code unobtrusively.
# Posted by Dan Webb on Friday, January 12th, 2007 at 10:53am
Dan: I do see your point, but it doesn’t work. The whole point of "trusting" people to Do The Right Thing relies on the fact that they know what the right thing is. People like that are people like you, like Jeremy, like ppk, like me, and we’re not really using libraries much. I’m trying to reach out to people who don’t know what the Right Thing is and help them to do it that way. Now, one way of doing that is with lots of examples, all of which demonstrate the correct way to do things, but it’s jolly hard to teach a mindset (which is what we’re trying to do here). You’re a perfect example here: you didn’t feel that the existing libraries did the stuff you wanted, so you wrote your own library. What do we do with the people who don’t have the ability to do that (or don’t have the time to learn how)? Too much, I feel that the answer is (not necessarily from you, but from some people) that they should just not use JavaScript because they don’t know enough: that’s why I characterised that view as elitist.
# Posted by Stuart Langridge on Friday, January 12th, 2007 at 11:18am
I like the idea of a library not allowing programmers to do something they shouldn’t (your example of using href = "#" or "javascript:" is a good one).
But I have to imagine anyone who writes a library wants people (a lot of people) to use it. Not only that, but authors would probably like to see their libraries adopted as quickly as possible. On the off-chance that someone writing a library has actually considered your idea Stuart, I wouldn’t be surprised if it was decided against simply for fear that it would hinder the rate of adoption.
I’m not necessarily saying that’s a reason not to do what you suggest; I’m just saying perhaps it’s one of the reasons we haven’t seen it done yet?
# Posted by Stephen Stchur on Friday, January 12th, 2007 at 10:00pm
Stephen: perhaps. That’s what I meant about taking some responsibility, though. If library authors are doing it for the fame and popularity rather than, say, to make the world of JavaScript better, then they shouldn’t be. (I personally don’t think they are; the ones I know, at least.)
# Posted by Stuart Langridge on Saturday, January 13th, 2007 at 12:01am
I totally agree with your conclusions. I don’t want to call it a personal library - but my common.js file.
I don’t want big classes for handling events - I just need my addEvent() function. I have a collection of such very useful functions in my common file - it can be called a library.
If anyone wishes you want to create a ‘personal library’, Dustin Diaz, top 10 functions would be a good starting point. http://www.dustindiaz.com/top-ten-javascript/
# Posted by Binny V A on Monday, January 15th, 2007 at 8:35am
Basically, we’re on the same page here, Jeremy. I don’t dislike all libraries, but rather how they’re often used and somewhat also encouraged to be used. The attitude is somewhat like "This will solve all your JavaScript issues, lean back and we’ll take care of it for you", and people go for it (that was partly the reason for my ironic naming of my post; no library can ever be the ultimate one).
I’m all for people using libraries, if they truly understand how they, and JavaScript itself, work. However, as long as libraries are out there, the people most prone to using them (of the people I’ve seen; I might be wrong here and it is not meant to offend anyone), all the time, are the ones most stressed and/or least skilled when it comes to JavaScript development.
Regarding Stuart’s idea about having some kind of unobtrusive/accessible code-check, it’s interesting, but not the only solution to it all. In the end, I think it’s the web developer’s responsibility to know what they’re doing, but nevertheless, maybe we can take some baby steps in that direction. What I did when I developed ASK ( http://www.robertnyman.com/2006/02/08/ask-ajax-source-kit) was to make sure that links dynamically getting content through AJAX could only be applied to links in the page.
In the end, I think it’s fair to ask of someone using a tool to know at least the very basics of how it works. To me, that’s not elitist but rather something that they themselves will benefit from in the long run. It’s for their own good, not for the sake of excluding them.
# Posted by Robert Nyman on Tuesday, January 16th, 2007 at 9:04am
I do web development for a living and I’m pretty well versed in javascript. For the life of me I can’t understand how using a library or API with it’s code-bloat for your own personalized project is any easier than writting things out from scratch. I just don’t get why anyone needs an AJAX framework, library or API like Googles or Yahoos etc. I do my own AJAX thing using HTML, DOM, XSLT, XML & ECMA JavaScript with TextPad as my IDE and get along just fine. Some of these commercial AJAX libraries remind me of ColdFusion that try too hard to reinvent the wheel (for non-techies) by creating their own markup/scripting language. Could someone please email me and explain it, I’m clueless.
# Posted by Chris Phillips on Wednesday, January 17th, 2007 at 5:18am
Chris: did it take you a while to test your Ajax calls in Firefox 0.9, 1.0, 1.5, 2.0, Opera 6, 7, 8, 9, IE 5.1, 5.5, 6.0, 7.0, IE for the Mac, and Safari? I imagine that after you did all that testing you’d put yourself together a little "do_ajax()" function which takes care of the minor inconsistencies between browsers. Do you then copy that function to each new project you use, or do you reconstruct it from scratch and from first principles every go? If you copy it, then…it’s a library. It may be your own personal one, but it’s still a library.
# Posted by Stuart Langridge on Wednesday, January 17th, 2007 at 10:30am
Sorry. Comments are closed.