Unobtrusive Javascript: Is it possible without a framework?

[fzaninotto]

I posted a comparison of the code hassle necessary to add a simple link to a JavaScript function in an unobtrusive way:

http://redotheweb.com/?p=5

My conclusion is that writing unobtrusive JavaScript by hand is not acceptable, the resulting code is just too much.

But, by using both a JavaScript framework (jQuery) and a web application framework (symfony), I managed to reduce the necessary code to about the same amount that would be required to do it in an obtrusive way.

What do you think about the idea, and more generally how do you manage unobtrusive Javascript in complex pages?

[7stud]

But, by using both a JavaScript framework (jQuery) and a web application framework (symfony), I managed to reduce the necessary code to about the same amount that would be required to do it in an obtrusive way.

Of course you have to squint your eyes real tight and look slightly to the left to avoid noticing the 1,000 lines of code from the framework.

[fzaninotto]

mmmh... I don't follow you here. The idea is not how much lines of code are required to make the thing work, but how much a developer has to write. Do you count the lines of C code necessary to make the browser's JavaScript interpreter work?

[mrhoo]

Every developer uses a framework- usually it is a framework he has developed over the years, but there is no reason not to use a framework developed by someone else, as long as it meets your requirements.

Unobtrusive javascript refers to keeping scripts out of the html source, using object detection to avoid loading what a client cannot use, and providing accessible alternatives for generated content.

It is more a strategy than a tactic- use any tools you like to achieve it.

[Kravvitz]

Do you count the lines of C code necessary to make the browser's JavaScript interpreter work?

That's irrelevant. You don't transfer C code every time someone visits a web site. With JavaScript it's beneficial to keep it as lean as possible. (I'm not advocating compression though. I much prefer being able to read code easily.)

I prefer copy-and-pasting code, most of which I've written myself. I have a ~23 KB file that I keep functions and other snippets in.

[MikeFoster]

Ok, I'm going to rant. If you don't want to hear it, stop reading right now.


All the hype surrounding ajax/prototype/jquery etc has produced developers who know even less than and have even worse development habits than those "dhtml fellows" they deride (fzaninotto, I'm not talking about you personally - I'm talking in general). If Prototype is so great, why does Opera ship with a "fix" for it? Last time I looked JQuery was still sniffing. Don't get me wrong, I support all library authors and applaud their work (and I do think Prototype and JQuery are awesome libraries). But the problem comes when there is a general misunderstanding about what those authors have produced and how to use it.

One of the current fads is to be concerned with how many characters you type, which - I admit, is a valid concern. I like the idea you have with the tool, sfUJSPlugin. But now we're talking about server-side script - it's not fair to compare that to client-side-only solutions.

Another current fad is to try to turn Javascript into something it is not. Let's turn Js into Ruby. Let's turn Js into a Class-based language (which it is not). Etc, etc, ad nauseam. However, I have a different perspective on this as well. As a library author I understand the urge to experiment with language features to the point that you can abstract it. For the author (and those who take the time to understand it) the abstraction is very useful and re-usable. But for others, I'm afraid to say, many times it just hides the true language feature.

Only a few years ago noone would accept library functions that were not named according to W3C standard interfaces. But Js developers are blown about with every new wind.

I'm a C programmer and I can see the Js crowd ignoring many, many, proven "best practices". The Js crowd is "fickle" and easily swayed by what appears to be the latest and greatest. Javascript developers have yet to acknowledge that they too are "programmers" - and then accept the responsibilities that go along with it.

Ok, so we rename "document.getElementById" to "$". There's nothing wrong with this and I admit that I like to type less too. But here is what people do with it:

var e = $('myId').method().property.etc...

Wow, we can really type less! Never mind that we won't be able to understand it next year when we have to work on this project again. And this shows one of my biggest complaints about Js developers in general - you rarely see this:

var e = $('myId');
if (e) {
//...
}

Is the word "robust" not in Js developers' vocabulary?

From what I've seen, most of the people using Prototype are developers whose skill level proves that they should not be using Prototype. I admit too that many of the people using my library know very little about all the Js they're sending to the client.

Ok. I need more coffee and I'm sure you're tired of my rant - I know I am

[MikeFoster]

Btw... the concept of unobtrusive Js behavior was around long before 2002

[fzaninotto]

Mike,

I think we all follow the same goal: speed, easy coding, not reinventing the wheel, not repeating ourselves.

The X library is said to be "not a framework", however it consists of functions that depend on each other and that package some reusable features, therefore it is not that different from what I call a framework. To my mind, reusability + dry + general concept (+ talent sometimes) = framework. If you don't agree with the name, I think you can at least agree on the purpose: making your life easier.

So yes, Prototype and jQuery are meant to be used for RAD, and RAD is not always synonym of robustness, edge case handling, good practices. You can do very clean things with jQuery and Prototype, but you can also do very ugly ones (just like with plain JavaScript). But you can't blame the developers of these tools for the bad use some DHTML fans do with it. After all, the development of the rich internet applications (think Yahoo, think google) wouldn't have been possible without such frameworks. Overall, those two projects we're talking about use unit testing extensively, their code base evolves towards consistency and robustness, and provide viable solutions for complex client interactions.

My reference to C code was to express the natural evolution of programming. 20 years ago, you had to write assembly code, then came procedural languages, then OOP, then dynamic scripting languages, and it made programming a lot easier. Can you do much worse with Ruby than what you did with assembly? Sure, but the opposite is also true.

Where I really agree with you is that most of the frameworks published these days also carry a certain level of methodology, but if the code is provided most of the time, the methodology is rarely documented. Unit tests and documentation are what may bring open-source frameworks to success.

By the way, congratulations on your Playground, it's definitely in my bookmars.

[fzaninotto]

Btw... the concept of unobtrusive Js behavior was around long before 2002

ahrg! I should check my sources. Was the WORD "unobtrusive" pronounced before 2002 in relation with JavaScript?

[felgall]

The problem with frameworks written by someone else is that it is much HARDER to strip out all of the functions you don't need to reduce the page size to a reasonable level. If you only use 10% of a framework then it may be easier for you to write that 10% yourself than to figure out where those parts are in the framework so as to delete the rest. If you don't bdelete the parts you are not using then your page will load slower than other peoples and your visitors will go to the faster loading pages instead.

[MikeFoster]

Dang. How many times do I have to tell myself, don't post until you're fully awake! Oh well.

I certainly hope I didn't imply that I "blame the developers of these tools for the bad use some DHTML fans do with it" - because I don't blame them at all. I really appreciate and respect their work. What I do blame is the press and hype that surrounds the tools. But we've always seen these types of problems as paradigms change (and as browsers become more capable, allowing the paradigm changes).

Most of the core functions in the X library are very loosely bound... but I agree that the difference between using the terms 'framework' or 'library' is loose - except maybe to the authors of those tools .

By the way, congratulations on your Playground, it's definitely in my bookmars.

Thank you!

Was the WORD "unobtrusive" pronounced before 2002 in relation with JavaScript?

I don't know... you may be right about that.

The problem with frameworks written by someone else is that it is much HARDER to strip out all of the functions you don't need to reduce the page size to a reasonable level.

You make some great points. And the above relates to the point 7stud made too. I provide a tool, XC, to be used with my library just for that purpose. I think many people do use it, but not as many as should.

You all make some excellent points! Thank you for your professional replies to my unprofessional rant

Unobtrusive javascript refers to keeping scripts out of the html source, using object detection to avoid loading what a client cannot use, and providing accessible alternatives for generated content.

It is more a strategy than a tactic- use any tools you like to achieve it.

Well said!

Now let me finally make a serious (non-rant ) reply to fzaninotto's original post. Take a look at this thread. This is a good example of taking a page that uses event attributes and coverting it to something more unobtrusive. If we were only talking about one link, then yes it might seem like using event attributes (in the html) is easier. But when we have many links you can see that we quickly end up typing much more code (and in the html) than we would by adding event listeners in script.

Also there are other benefits to adding event listeners in script as opposed to adding them in html. And adding event listeners in script doesn't neccessarily make our solution "unobtrusive". Like mrhoo said, it is a strategy, not a Js technique. The strategy affects the way we develop our html and css, as well as Js.

[MikeFoster]

Btw, fzaninotto, Welcome to SPF

[7stud]

mmmh... I don't follow you here. The idea is not how much lines of code are required to make the thing work, but how much a developer has to write.

You're the one that said:

the resulting code is just too much.

You didn't say:

I don't like to type a lot of stuff.

In any case, the "idea" is not how much a developer has to write. If that is your idea, then here is your solution: don't write ANY javascript on a page. The "idea" most website owners are after is to produce the best user experience possible, and as a developer if you can't deliver, then you aren't going to be getting much work. And, as a user myself, if your page is slow, I'm not hanging around. Note to all Flash developers: I have yet to get past one of your stupidly long loading intro pages.

Do you count the lines of C code necessary to make the browser's JavaScript interpreter work?

See Kravitzz's reply. In addition, if you develop a browser using some framework that allows you to create a full featured browser with 3 lines of code, but it takes 90 seconds to load a page, I won't be one of your users.

And this shows one of my biggest complaints about Js developers in general - you rarely see this:

var e = $('myId');
if (e) {
//...
}

Yep.

[felgall]

The difference between the lines of code that make the javascript work and the lines of code in a framework is that the formaer is compiled into your visitor's browser while the latter has to be downloaded from the server. Most monolithic frameworks are so huge that many of your visitors will move on before the framework finishes downloading. With a modular framework on the other hand you can just include the modules you are actually using in the download and then your Javascript download will only be around 50% - 500% bigger than it needs to be.