JavaScript never ceases to disappoint. Although it was launched with great expectations and has found reasonable penetration, both JavaScript authors and their (sometimes unwilling) users find something to dislike about most every deployment. This is most certainly due to either the clash of titans that surrounded its birth or the wallowing of low-lifes that turn everything into spam. This page contains mostly bickering about the extent of this tragedy. A future refactoring will draw some lessons from the experience and maybe even point toward alternate futures. -- WardCunningham
----
'''The worst sin''': Because JavaScript emulated Java and went with '''&&''' for ''and'', and because web browsers _must_ forgive sloppy editing in Notepad, XHTML is now a dead letter, and HTML''n'' will always be a broken format impersonating true XML. Permitting new
Now, document.write looks something like this (though none of this is exercised):
document.write = function (s) {
log_write(s);
document.oldWrite(s);
};
All this, (don't forget the cut-and-paste hack that has to follow) just to be able to see what actually gets sent to the document!
This example illustrates that JavaScriptSucksInBrowsers because there is '''no''' support from any vendor. Even the Mozilla tools, which come closest, are woefully buggy and unreliable in comparison to any of the current commercial language environments. Embracing JavaScript means, for me, either developing my own tools or exposing my customers to sloppy, untested, and unoptimized code.
''JavaScript doesn't suck. JavaScript support in popular browsers sucks. There's an important difference. If you use JavaScript outside the browser all of the criticisms of it go away.''
Why on '''earth''' would I or anyone else use JavaScript outside of a browser? Do you use EmacsLisp outside of Emacs?
''The same reasons one would use any scripting language outside a browser. If Perl had lousy browser support, would that mean Perl sucked?''
To the extent that JavaScript ever had a purpose, it was to run in a browser "to do simple web programming".
If Perl were as spectacularly bad at fulfilling its design purpose as JavaScript, yes that would mean that Perl sucked. If, for example, Perl behaved completely and unpredictably different on each platform that claimed to support it, it would suck. If Komodo 2.0, ActiveState, CPAN, or none of the myriad of Perl user groups didn't exist, it would suck. If each platform announced its own utterly incompatible "extensions" to Perl, it would suck.
Are you saying that you use JavaScript outside a browser, and that you feel it is a better language in that context than Java, C++, C, Smalltalk, Lisp, Perl, Python, etc? If so - whatever floats your boat.
Oh, and by the way, I '''do''' use the Emacs scripting language outside of Emacs - it's called Lisp (well, actually MockLisp, but who's counting).
''JavaScript isn't bad at fulfilling its design purpose. Multiple variant implementations and DocumentObjectModel definitions are the problem, not JavaScript itself. I've used JavaScript outside a browser. I wouldn't claim it is better than any of those languages, but it doesn't suck. It's a powerful ScriptingLanguage.''
So let's see if this horse is dead yet. Suppose that the basic C libraries (things like stdio) worked differently on every platform and well on none. Suppose that every C compiler was buggy, crashed unpredictably, and generated code that sometimes worked and sometimes didn't. Suppose that there were no C debuggers, no user groups, and no vendors providing C compilers, libraries, and tools.
I suppose one might claim, given all that, that the "language" didn't suck - after all, it would still be C (for better or worse). I think that the overwhelming majority of developers and users would find your distinction worse than useless.
Why don't we try by examining the JavaScriptDesignPurpose. Let's see if we can reach agreement on that. Then let's re-examine the question of how successfully the language has accomplished it.
''Your analogy doesn't work. There are JavaScript interpreters that aren't buggy, don't crash and follow the EcmaScript standard. You're thinking only of JavaScript in the browser. I have no idea what the design purpose of JavaScript was. I know from personal experience that the language is powerful, useful and easy to work with. -- EricHodges''
Here is an excerpt from the ECMAScript standard:
: ECMAScript was originally designed to be a Web scripting language, providing a mechanism to enliven Web pages in browsers and to perform server computation as part of a Web-based client-server architecture
The overwhelming majority of JavaScript programs run in browsers. I've cited the design purpose of JavaScript. Someone (I don't know if it was you) agreed earlier that "JavaScript support in popular browsers sucks."
You seem to be arguing that you've had a better experience outside a browser - you've said it is "powerful, useful and easy to work with".
I stand by my claim that if I want "a mechanism to enliven Web pages in browsers and to perform server computation as part of a Web-based client-server architecture" that JavaScriptSucksInBrowsers and that a several superior alternatives now exist. -- TomStambaugh
''I'm arguing that the problems folks have with JavaScript aren't caused by the language but by variant implementations and DOM issues (which has nothing to do with JavaScript at all). The purpose of JavaScript is as relevant to its suckage as the purpose of C. C was invented to write system software, but it has been successfully used for much more than that. -- EricHodges''
I suppose we'll have to agree to disagree. I suggest that had the system software written in C been as bogus as the results of using JavaScript in popular browsers, C would have died an early death. Further, I suggest that when used outside of popular browsers, JavaScript suffers in comparison to virtually every other choice (save perhaps VisualBasic). Conversely, C, when used outside of system software, was still comparable or preferable along multiple dimensions (expressivity, quality of compiled code, conciseness, flexibility, etc) than most or all of its competitors. -- TomStambaugh
''Check out the language. Ignore the non-standard implementations, ignore the DOM bindings, focus on the language itself. From a language definition perspective, I prefer it to Java. Here's the spec: http://www.ecma-international.org/publications/files/ecma-st/Ecma-262.pdf -- EricHodges''
Yes, I found and posted the same link in JavaScriptDesignPurpose. I agree with you that, purely from a language definition perspective, JavaScript is superior to Java (''"the simplicity of C++, the performance of Smalltalk"''). Of course, I also think that JavaSucks. -- TomStambaugh
''Then we have widely variant thresholds for suckage. -- EricHodges''
----
Is Javascript in browsers getting better? AjaxWebApplications
----
JavaScript doesn't suck. TheMultipleBrowserUniverseSucks. If we could just get everyone to buy the same hardware and software life would be so much easier for us. -- EricHodges
[Thank you, Bill Gates.]
''As asked below, why do people confuse JavaScript with Java? Not to put words into your mouth, Tom, but it sounds like you expected JavaScript to do what a real programming language could. JavaScript wasn't originally made for that; rather, it was made for Web scripting. It's just a stripped-down procedural language and nothing more which is why I said it never failed me. Yes, it didn't do much at all, but it did exactly what I needed it to do for the Web.''
I wouldn't say dynamic typing, dynamic member lookup, polymorphism, inheritance, higher-order functions, dynamic class extension, and lexical closures are things you would normally find in a "stripped-down procedural language." JavaScript even beats "real languages" in some aspects. For example, it doesn't force you to create a Better'''''String, like JavaLanguage does. -- DanielBrockman
----
''As asked below, why do people confuse JavaScript with Java? Not to put words into your mouth, Tom, but it sounds like you expected JavaScript to do what a real programming language could.''
I am well aware of the differences between JavaScript and Java. I expect a language to do what its language definition says it will do - and the above paragraph from DanielBrockman summarizes just some of what JavaScript claims for itself. I also expect a language to be supported by its suppliers/vendors, where support includes at least minimal debuggers, development tools, and maybe even some testing. JavaScriptSucksInBrowsers because it fails to achieve even this very low bar - in comparison to, for example, VisualBasic (the Microsoft scripting language), Emacs macro language, or Perl (which, in this context, is the JavaScript-equivalent of the various Unix shell languages). -- TomStambaugh
''VisualBasic (the Microsoft scripting language)''
I'm sorry to interrupt, but Visual Basic is not a scripting language, it's a full programming language. VBScript IS a scripting language, but not Visual Basic
----
'''Arguments against JavaScript:'''
* Interpreting a language in a Web browser is a bad idea. ''Why?''
* Increases code size of browser: requires more resources to run, provides more opportunities for bugs. Poor design results in security problems: cross-site scripting exploits, automatic execution of code in HTML mail, etc. However, it's here already and in all popular browsers, so that's not a reason not to ''use'' it.
* JavaScript provides non-programmers with an easy way to put code they don't understand into their pages. This encourages the spread of pretty but useless widgets.
* Encourages newbies to add spiffy rollovers and rollouts to buttons instead of having straight-up HTML links. Just like image maps, this make navigation durn near impossible for older browsers, handicapped visitors, and people who shut off Javascrapped and images to get some speed out of their 26K dialup connections.
----
''SimpleProgrammingLanguagesEncourageBadPrograms. Maybe we should all stick with Assembler, and only produce worthwhile programs.'' -- LeonGierat
Are you suggesting that assembly isn't simple?
''Ok, I guess it doesn't get a lot simpler than writing in the base instructions that a CPU understands, but writing it isn't that accessible for someone new to programming. To write assembly, you need to be thinking like a computer. With 3GL languages you can think in more abstract terms, which, while not quite like natural human thinking, are a lot closer to it than thinking about registers and shifting bits. -- LeonGierat
----
Speak for yourself. It is a perfectly reasonable activity to point out how much something sucks - why, just look at all the reasonable and mellow '''' "discussion" on any of the CategoryRant pages. Eh? The Lisp and XML pages come to mind immediately.
----
'''Most Annoying Programming Language Ever''' ~ until you consider all the others
Limited and flakey, you can never depend on the execution environment being fully functional, the duelling implementations (ExplorerVsNetscape) held back client side scripting for years, and given the installed base most likely will for quite a few years to come.
On the other hand, there are times when not much else will do.
TIP: Plan on doing two versions at least, test it on both of the 4.0 browsers, and if one doesn't work, wrap your page in a server side agent detection script and write two versions, it'll take less time than writing one that will work on both targets. ''This is a sound use for PhpLanguage.'' Or any other server-side language.
''This has nothing to do with JavaScript. The fact that the environments where JavaScript is housed are shoddy should not be allowed to reflect badly on the language itself.''
Well, there's the language design, and then there's the language environment. Both have an effect on how much work you have to do. Sun, for example, owns Java and can create a specification for the Java Virtual Machines - meaning that if you write standards-based Java, you can be sure that someone else with a JVM (of the right version) will be able to run. (In some ways, it seems like Sun's grip on Java is too tight for its own good, but that's another kettle of fish entirely.) JavaScript had no such standardization, and so suffers from these sorts of wide-spread deployment problems. The effectiveness of a language depends on more than just its syntax.
Another issue is that this is generally a problem when you send code directly to the client for interpretation. End-users don't know that much about which interpreter is running in their browser - and really, why should they care? In the case of, say, a non-standard C++ compile instruction, you can at least put up a FAQ somewhere and explaining which compilers support what, and some programmers might go to the trouble of changing their environment. But try detecting the end-user's browser, then putting up a window saying "You're running the wrong sort of browser; please change to Mozilla" - you probably wouldn't get very far.
----
Which isn't the whole story - as EcmaScript doesn't cover the real interesting stuff in JavaScript - how to interact with the DocumentObjectModel - http://www.w3.org/DOM/ -- MartinWebb - http://www.irt.org/
----
Surely that's the interesting stuff in the DocumentObjectModel ;-) Seriously, it's worth remembering the separation between the language and the environment in which it's hosted. This is the confusion that lead to the "limited and flaky" comment above - JavaScript has never been particularly flaky, but the browsers hosting it sure have. -- NickFitzsimons
----
Yes, a big problem with writing JavaScript for the browser is the inconsistencies of its implementation across the various browsers. Take a look at JsUnit. It's a unit testing framework for running JavaScript unit tests inside the target browser. A nice side-effect of this is that you could run your tests in all your target browsers. -- EdwardHieatt
''I think part of the problem is that HTML browsers (with JavaScript and DOM) are optimized for "e-brochures" in both implementation and protocol design. Such apps tend to get messy when people start to use that model for non-trivial business forms. In my opinion, what is needed is an HTTP-friendly protocol (and browsers) designed JUST for business forms. Candidates include XUL, XWT, Curl, Droplets, SCGUI, and Kenamea. ''
This is an intelligent comment.
If you use BookMarklet''''''s, the cross-browser compatibility questions are at least reduced to tiny scripts. -- fp
MozillaXul seems to unfortunately be drifting to FatClient type of applications rather than Web-based.
RemoteGuiProtocols
----
'''''Most Annoying Programming Language Ever''' ~ until you consider all the others''
That's the programmer side of it. As an unwilling user of JavaScript and part time victim of JavaScriptAbuse, I resent being forced to execute code when I came to the site looking for data (DataAndCodeAreTheSameThing).
I despair when I read about the "cool thing you can paste into your HTML to stop other people right clicking on images and stealing them". I completely fail to see the point of '''Click here to see page two'''.
''The point is to force users to turn on Javascript before they will be allowed to navigate. Then, when they've turned it on, you spam them to death and do other intentionally evil things that are greed-motivated. A lot of other tricks are also frequently done to purposely render pages unusable to punish users who try to escape from popups and other evil tricks by disabling Javascript.''
----
'''Standalone options'''
''Is there some environment for Javascrapped that'' isn't ''tied to a browser? A standalone JS interpreter or something? Tcl, Perl, and others have these implementations for Windoze boxes - does JavaScript/ECMAscript?''
Mozilla has a product called RhinoInterpreter, which runs JavaScript from Java. It includes a command-line interface. http://www.mozilla.org/rhino/
Mozilla also has a C version called SpiderMonkey that also has a command-line reference implementation. http://www.mozilla.org/js/spidermonkey/
Microsoft has WindowsScriptingHost, which hosts scripts completely separated from any browser. Also, it's not just for JScript.
Apple has a plugin that lets JavaScript plug into their OpenScriptingArchitecture, to do the same things that AppleScript does.
----
Blaming a language for the environment it runs in, and the programs people write with it seems a little unfair - just because there are terrible applets out there, it doesn't mean that JavaSucks.
I think the BrowserWars are to blame more than anything for the things people are complaining about above. JavaScript is a great scripting language with the implementation of a 'System' host object, JS could be used for the sort of things that might currently use 'sh' or 'perl' for. -- LeonGierat
----
The use of the word sucks in a page title has proven to be a useful way to bring proponents into a discussion regarding strengths and weaknesses of whatever "sucks". It sucks people into discussion and is another way of saying JavaScript - "Let's talk about it".
----
(moved text to JavaScriptAbuse)
----
There is still too much focus on shoddy JavaScript code. Written right, it can save numerous form posts until the form has validated ok, it doesn't need to check on every form entry field, it can be written in a manner that could be considered 'GoodProgrammingStyle', and it can be designed to be optional, so that it is also validated on the server, allowing non js enabled browsers to still use it. It seems harsh to condemn the whole idea of browser scripting just because some clueless people out there write junk code.
----
You seem to think JavaScript is only used on the client; many of us use it on the server too. And on our workstations for writing quick scripts. Classic ASP if often done via server side JavaScript. JavaScript is a great language, powerful, flexible, dynamic, object-based - what's not to like?
----
Shoddy JavaScript code is not a problem with JavaScript. We had to choose whether or not to put JavaScript in our pages, and we chose not to, for the following reasons:
1) Duplicated code. As was said before, we would have to duplicate the validation in JavaScript we had in the server (in Java) OnceAndOnlyOnce.
2) We could not do all the validation in JavaScript. Sometimes, we were validating stuff like account numbers, which required a call to another service actually. This would mean that some error messages would only appear when you submitted the page.
3) We couldn't be arsed with making it work on multiple browsers.
We could have done validation generation automatically, (something like LittleLanguage), and generate the JavaScript like that, but you'd still have the problem with 2). So we ran away screaming, and didn't use it. -- MatthewFarwell
''You can use the XmlHttpRequest object to call services from JavaScript without submitting a page. This is most of what enabled AjaxWebApplications. If you don't want to make it work on multiple browsers, make it work on the browser with the biggest market share. -- EricHodges''
----
Really, see AjaxWebApplications
----
CategorySucks, CategoryRant, CategoryJavaScript