Java Script Sucks In Browsers
Java Script Sucks In BrowsersJavaScript 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 HTMLn will always be a broken format impersonating true XML. Permitting new <script> blocks to contain && for && would break all the legacy code using document.write('&') instead of document.write('&amp;').
Much of the discussion on this page seems to show off the scars of the writers from the time when they had to tame 4.0 browsers. Wake up folks, it's 2006, and most of the arguments here are irrelevant now.
True. Anyone who subscribes to the thesis of this page should refuse to use http://maps.google.com/ out of protest. -- WardCunningham
Agreed. Many of my earlier complaints seem to be addressed in more recent browsers. And the stuff google does blows me away. Now if I could only get their development tools. -- TomStambaugh
Javascript and the browser menagerie have now matured sufficiently that I've joined the JavaScriptRocks contingent.
This leads me to a dilemma about my comments on the rest of this page. Do I edit them to reflect current reality or somehow indicate that this page is now of primarily historical interest?
-- TomStambaugh
May I suggest, based on my own history in XpIsaPseudoMethodology? (now completely removed, remaining interesting content in EdgeOfChaos), that you could refactor to discuss what your values are (or were, at the time) and how the available implementations failed, and then discuss what specific changes in your own attitude or the technology prompted your change in position? -- StevenNewton
Cons
Close to everyone on this page is arguing against DHTML or even HTML4 in general, failing to target JavaScript at all. The only one who has managed to come up with even half an argument against it is TomStambaugh. JavaScript is a language with an identity of its own; it's not a part of HTML. See EcmaScript.
In short, nearly everything on this page should be moved to TheWorldWideWebSucks?, or perhaps some of it to CommercialismSucks?. -- DanielBrockman
Do you like banners? Do you like pop-ups? Do you like 5 more pop-ups when closing a pop-up? FDSA (definition, please?) If you answered those 3 questions with 'yes', stop reading this page and keep on using InternetExplorer.
And why do Web designers use JavaScript? Because they have to! If you're a good Web designer you should know that JavaScriptSucksInBrowsers. With every new browser version, JavaScript's abilities will grow. But not everyone wants to download new browsing software to be able to read a specific page only...
Basic JavaScript/JScript has never failed me. It was never meant to be a real programming language; rather, it was meant to be a very stripped-down, procedural language for simple Web programming. When used for that, it seems to do its job quite well. Now it's expected to perform DHTML and that's where it begins to fail. How does it allegedly begin to fail?
Perhaps "basic JavaScript" "never failed" the previous contributor because it did so little. I suggest that it "begins to fail" long before any problems with performing DHTML. The unwillingness of Microsoft to provide any real support for developing and debugging "JScript" (their name) under IE, while Netscape continues to add Netscape-specific bells and whistles, has much much more to do with why JavaScriptSucksInBrowsers. JavaScriptSucksInBrowsers because it operates differently on each version of each browser on each platform and because it is virtually impossible to rigorously exercise and test - never mind debug - even the most trivial JavaScript program. Perhaps a defender can suggest even one tool that will, for example, copy the results of "document.write()" to a log where they can be examined by testing tools. -- TomStambaugh
Not that I really see why you would want to, but here you go:
document.oldWrite = document.write;
document.write = function (s) {
/* copy s to a log */
document.oldWrite(s);
};
Not to nitpick, but the above code fragment skips the stupid part. What JavaScript should replace the "/* copy s to a log */"? Don't forget this is JavaScript running in a browser on the client, so no files are allowed (at least directly).
JavaScript doesn't have to run in a browser on a client. The limitation on modifying the client's file system doesn't come from JavaScript, but from the browser. You'll have the same problem no matter what language you use there.
<SCRIPT>
var logger = null;
function log_write(aString) {
if ((logger == null) || (logger.closed)) {
logger = window.open("","log","width=640,height=480,resizable");
logger.document.open("text/plain");
}
logger.document.write(aString);
}
</SCRIPT>
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:
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:
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 <ahem> "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 BookMarklets, 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.
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 <a onclick="javascript:location += '/pageTwo'" class="blueunderlined">Click here to see page two</a>.
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
EditText of this page
(last edited April 21, 2012)
or FindPage with title or text search