Saying a language sucks is not the same as saying that it is broken and that it can’t be used to do interesting or flashy things. Saying javascript sucks could mean many things, ranging from complaints with the syntax, scoping, quirks, inflexibility, or last-gen-ness.

You claim that the existence of code-generation tools does not indicate that the language sucks. This is mostly true. However, if the populace typically needs the sort of functionality provided by a code-generation tool, this indicates that the language could probably be more flexible in some regard. For instance, if you compare dealing with lists in C (malloc, free, ptr magicks) to dealing with lists in an interpreted scripting language like Ruby or Python, you can see that certain things are easier to capture in different languages. If you really need lists, and you don’t need speed, then why write in C? The same could go for javascript. It doesn’t suck, it just doesn’t meet the needs of the community.

Now, your claim that the existence of tools implies that javascript is not horrible.. this strikes me as rather audacious. The fact that there are development suites for managing and writing javascript grows from the fact that this is the ONLY method of obtaining the so-called “web-2.0″ goodness that everyone is hyping. There IS no other client-side scripting language that offers more. Javascript, in this light, looks more like a monopoly or a last resort. It’s the only thing we’ve got, so rather than force users to adopt some janky newfangled browser with a better client-side scripting API, we just use javascript.

Thar’s my two cents.

While the state of browser scripting is much, much better than it was several years ago, it is true that it still isn’t great.

There isn’t a whole lot of choices however. You could build an app in Flash (which coincidently uses a variation of javascript) to run in a browser, or bypass the browser altogether and run a standalone application. Many years ago I was involved with a project that was essentially a swing applet but ran by launching a new swing window so the users felt they were working with a desktop app. It worked great but that isn’t plausible for public facing applications.

I guess it all boils down to what you consider a rich web client. Is it a client than runs over HTTP, but not a browser? Does it run in the browser, say via Flash or even XUL for firefox?

Oh well…

Thanks for the comment!

BUT, on the other hand I do agree that the whole Javascript-shebang is fundamentally not the right solution for the problem of building rich web clients.

Why is it so prevalent and why do us poor developers need to spend many frustrating hours fighting with the beast? “Only” because there’s these millions of people abusing the original static-document-oriented web-stack for all kinds of weird stuff, and getting spoiled by people with time-to-waste (;-)) that end up building these nice-looking responsive/interactive/what-have-you/… web-sites.

We would have been much better of if someone would have been able to say 10 years ago : “Whooo, hold your horses and let’s revisit this internet/browser thing a bit for the new scope that needs to be addressed!”

End-result: the best we can come up with, is to hide the dirty non-standardized magic stuff (magic as in non-maintainable) behind a properly-designed facade, such as YUI, GWT etc.

(even things like dojo give me the creeps. tried the most basic usage of a floating panel, worked fine on Firefox, sucked on IE (apparently only for my application and seems to work great for the rest of the world) but how do you start debugging such a thing on IE??)

so, let’s start a boycot against all this web 2.0 stuff now, and first force the whole world to move to a better technology stack before we start spoiling them again!

cheers