I suppose it all depends on what their licensing terms are today at this given moment.

Yes, 99% of websites "on the Internet" could perform their current functions without javascript. You're right.

The question is: of those websites, how many of them do their current functions better than if they didn't have javascript?

This is not a question of whether or not it "can work" without javascript; it's a question of whether or not the user interface, user experience, functionality, etc., is enhanced through javascript.

The argument that "it was working without javascript!" is a very poor one. Operating systems worked without GUI's. Typewriters worked without "edit" mode(s). Transcribers worked without word processors. For that matter, computers worked without monitors!

The question is, again ... is it better (or worse) with javascript/ajax/whatever. If it's better, then why not? If not, then you have a point.

Arguing that it "could" do it without is silly. In my experience, there are some site functions that are vastly improved with something like ajax... for example, being able to upload a file while filling out a form and and not having to wait for the upload to finish before pushing Submit on the form. Or making sure you do the form first and then the upload. Or having to do the upload at hte same time as the form. It can improve efficiency by allowing you to do two things at once. Multitasking on a site without javascript or some scripting thing would be more difficult. Unless, of course, you use frames, or something like that. But 99% of the websites on the Internet could perform their current functions without frames.

Meh. 99% of the websites on the Internet don't need to exist. ;)

Are you sure? If you distribute an application you have to share the code under GPL. If you distribute the JS, even in an obsfucated state, aren't you distributing the application? They are running code on their browser. They got it from somewhere. I would think that qualifies as distribution, and therefore they have the right to the source. Please, correct me if I'm wrong.

A lot of people may think, it's web client code, who cares, but for some of us web client code is becoming more and more like any other application code.

There's one important difference.

Web client code, by its' nature (it has to run on the client) isn't something you can hide. Any obfuscation can be de-obfuscated given enough incentive (and the fact that you've tried to hide it is "incentive enough" for some people). They HAVE to have the source to run it. (and this ignores the whole "performance hit from obfuscation" issue).

Sure, stick your copyright notice on it, but don't classify it the same as "any other application code". It's out there in the open. The real meatballs and gravy will always be on the server side in any data-driven web app.

the existence of dynamic framework compilers such as Google Web Toolkit [google.com] and Pyjamas [pyjs.org] makes it perfectly possible to accommodate "multiple broken browsers".

in the pyjamas case, the result of the compilation command is no less than FIVE completely separate applications: one for each (wildly incompatible) browser. user-agent string detection then redirects at run-time to the correct application.

this is just a "merging" trick that is applied at compile-time, by taking two ASTs (python abstract syntax trees), walking the top-level looking for classes and functions of the same name, and merging them. the resultant "munged" AST is then passed to the compiler, and used to spew forth javascript. the process is repeated for each of the five platforms.

this "trick" is actually something that even the developers can take advantage of. see browserdetect [pyjs.org] for the absolute most basic example (source code 2 levels below).

The question is: of those websites, how many of them do their current functions better than if they didn't have javascript?

Slashdot, for instance?

I much prefer the old interface.

This is not a question of whether or not it "can work" without javascript; it's a question of whether or not the user interface, user experience, functionality, etc., is enhanced through javascript.

In my experience, most sites don't enhace anything, they rather make it more annoying.

For instance, various sites with images now do this annoying thing where clicking an image makes a sort of modal window appear in the middle of the page, expand and show the photo. Yeah, fairly cool looking for about 5 seconds. Then it becomes very annoying because the effect wastes time, and it typically breaks the "open in new tab" middle click function, which makes it hard to show the image to somebody else.

I actually changed the place I shop for computer stuff at because of issues like that. The shop I use displays all the products in a category in a plain table, which can be sorted by any column.

The question is, again ... is it better (or worse) with javascript/ajax/whatever. If it's better, then why not? If not, then you have a point.

IMO, the functionality can be used well, but rarely is. Pretty much anything that makes something like AJAX the main focus of the site overdoes it and ends up making it horrible to use.

Though I'll admit I don't like the whole concept of web applications in the first place and generally avoid using anything that looks like one.

The argument for many companies to need IE6 is that existing intranet applications would break if they moved to another web browser (version). Now I'm reading that you're making a new intranet application for IE6?!

We'll never get rid of this pest at this rate. Though I guess it's a good thing that you're keeping other web browsers in mind, too...

in the pyjamas case, the result of the compilation command is no less than FIVE completely separate applications: one for each (wildly incompatible) browser. user-agent string detection then redirects at run-time to the correct application.

And this is the problem. Web browser sniffing is bad, because it duplicates code and breaks lesser-known web browsers because you can never test in all of them (including future browsers). It's the new version of "Best viewed in My Favourite Browser(TM)". While there is a perfectly viable alternative that's called feature sniffing.

This is the rallying cry of the anti-Web-app crowd. "I liked the good old Internet."

The problem is that the good old Internet kind of sucked.

Look at the original MapQuest vs. Google Maps. I spent large amounts of time trying to find things on MQ back in the day. When Google Maps came out, it changed the way mapping worked. Dragging the map around to pan alone was worth having to suffer slow (now much better) JavaScript interpreters. Now, of course, MQ uses a Google Maps-like JavaScript UI for that very reason.

The issues you raise are valid, and I think we're about to exit the age of one-off JavaScript UIs for that very reason. Some standardization needs to take place in order to bring back the sense that knowing how to use "the Web" means that you know how to use any given Web page, even if the domain-specific information on that page might not be comprehensible to you. Things like opening a link in a new tab (Gmail, I'm looking at you) are very important, and should be well supported. On the other hand, as a publisher, I want things like the image-popup you mentioned because it allows me to publish images in a way that maintains my site's flow (e.g. the ability to navigate to the next image in a set, comment on an image, and so on). These features need to be revised, smoothed and made more friendly to the kinds of browsing that people do and the way they expect their browser to behave, I agree, but throwing away the JavaScript UI isn't the way to do that.

I'm currently working as a contractor at a large company on a project that has three different web front ends for portions of the application. One is written in ExtJS, the other two are mainly straight HTML with some MS-Ajax controls. To be honest the ExtJS one is probably the most well-liked, it's slick and works well. The down side is too few of the other developers have the skill or inclination to come up to speed on using JS well enough to be proficient in the front end development of this application.

It's pretty sad, but the more advance web front ends get, the fewer people that are proficient in both the front end scripting as well as the backend, at least the communications layer. In this case it's using a WCF webservice backend, and the generic MS JSON Serializer. I've been about the only person working on this part of the set of applications since I started as a result.

Why not just refuse to use non-standard features, browser sniffing, etc.

A good developer uses them for the same reason they use anything else that isn't technically essential: To improve the experience. Granted, a lot of people do things for a lot of bad reasons, but that's another issue.

Accommodating multiple broken browsers just perpetuates the "we don't need no stinking standards but our OWN!" mentality.

A web browser is a tool, both for the user of the websites in question and the developers. As a professional web developer, I would prefer everybody perfectly and identically implemented all standards. That's my mentality; it would make things much easier for me. That said, while it's a shame that things are implemented so differently in different browsers, it won't prevent me from supporting them in reasonably up-to-date browsers if it's feasible to do so. "Reasonably up-to-date" at this point means IE6 or better to me. If somebody really, reeeeally wanted IE 5.5 support I would probably agree to it -- but they're going to pay for every last extra minute it takes, and that's probably going to be a lot of money.

"But my customers want it to work in their browser!" is not an argument when better browsers are freely available.

Why? Because "I don't give a crap as long as it works in MY browser" is so much more reasonable?

We're web developers. Our job (and in my case, my passion) is to create things that help people get things done, not to change the world. It would be awesome if some things were easier and/or more consistent across browsers, but to give people an inferior product because it takes extra work doesn't help anybody and doesn't progress anything.

Life isn't a fairy tale where everybody does the Bestest Thing Evar(tm) all the time. It's hard enough to keep an income stream when you're competing with people from India working for fractions of what you do without outright refusing work because they won't let you play to your pet projects. SOMEBODY is going to be doing the work, that's the reality of the world and of the capitalist system in general. So long as an employer/client can simply replace me by going to the next guy in the list, I have no power to change how fast outside organizations develop and implement standards. Wishing doesn't make it so.

What next - make a version that works for IE3 or Mosaic because someone is still running WFW3.1?

Like pretty much everything else in life, it's a trade-off. Or to steal one of those evil business terms, a cost-benefit analysis. Two years ago, refusing to support IE6 would have shut out 34% of potential customers. One year ago it would have been about 20%, and today it would be around 12%. Two years ago it's a no-brainer to support it, pretty much regardless of how much time it takes. Simply turning away one in every three potential customers that come to you isn't going to get you anywhere. Today, it's not as clear.

Why do you feel this incredible need to consistently resort to hyperbole as if there aren't reasonable intermediary steps? Nobody is going to develop for IE3 or Mosaic; the differences (and thus costs) are too great and the benefit too small. These days, pretty much no client I've come across even cares about IE 5.5. They do care about IE6, for now. Maybe not next year. What's unreasonable about that? Particularly if there are enough people out there who care that they develop things like, oh I don't know, JavaScript libraries that abstract away the differences for me?

We benefit from standards for everything else - electricity, water, sanitation, food, health, ram, tires, gasoline, soda pop containers, air quality, asbestos, drugs, alcohol, etc. - and yet in this one area, we tolerate immaturity. Why?

For starters, most of these comparisons are pretty lame.