Putting Java in our Script, our unfortunate doom
There is much talk and concern lately about the latest implementation proposals of JavaScript 2.0, largely based off of ECMAScript 4 which unfortunately, is starting to look a lot like the Java programming language. Despite the hoorah of bug fixes which actually, I’m in favor of, we’re beginning to see Classical paradigms not only sneaking into JavaScript, but overtaking it. With language “features” (*sigh) like classic notions of Class definitions, interfaces (which comes with implements), constants, static private functions, generic functions (whatever that means), namespacing, packaging, formal extending, constructors, and of course, the ability to strictly type your application; this is no longer JavaScript. JavaScript 2.0 is a new language that just so happens to have JavaScript support.
Why?
No, really. Why? Why bother implementing all these features that introduces another object-oriented style into a language that already has one. Having both classical and prototypal systems living in the same engine is a horrible decision, unthoughtful, and silly. Horrible because they’ve probably doubled the size of the interpreter (despite the optimizations they made on algorithmic operations). Unthoughtful because they’re forgetting who 90% of their users are: Web Developers. Silly because they’ve just made it more confusing and elevated the possibilities of incompatibilities.
Confused? Stand with Microsoft?
Despite an angry, but good spirited open letter from Brendan Eich (inventor of JavaScript) toward Chris Wilson of Microsoft, it seems as though the only ones who can save us from a tragic overhaul of the beautiful language is Microsoft. And from the looks of it, smaller, open-source browsers seem to be entirely on board with these language modifications. This basically leads me to want to lean on the shoulders of Microsoft (and the Internet Explorer team) and let them use the muscles they’ve been known to have in the past.
Don’t get me wrong
It’s not that I’m not for the proposed ECMAScript 4 language features, it’s that I’m against the adoption of those features into JavaScript 2.0. It’s at that point where it’s simply not JavaScript. Besides, most object-oriented idioms already have a way of being applied to the JavaScript language without introducing these so-called features. JavaScript (as it stands) is a supremely lightweight, expressive language that allows us to apply classic design patterns that most didn’t think were even possible.
As a brief segue (and not to distract from the original intention of this post), if you are so inclined to know more about these patterns, buy my book JavaScript Design Patterns and see for yourself that the current state of JavaScript is completely capable of implementing factorys, singletons, adapters, bridges, composites, private and privileged methods, multi-inheritance, chains, observers, commands, flyweights, decorators, proxys, namespaces, and much much more.
So now what?
As one fellow Engineer at Google put it, “… in ten years, if and when this stuff finally gets fully supported across major browsers, I hope to be retired by then and won’t have to worry about it.” I wish that were true for me. And although it might not seem like a big deal now, for the very reason that it won’t be for ages until this is usable, this is the future of the web and web applications. Woe will be the day when a new generation Frontend Engineer walks up to you and says “What’s a prototype?” Then you’ll know you’re old-school. In the meantime, if you have something to say, say it now. Just keep my name out of your open letters ;)
November 14th, 2007 at 6:57 pm
Go, Dustin, Go! Yeah, I’m with you on the Javafication of the language. Once you’ve got to the bottom of the language I think it’s really easy to appreciate how cunningly lightweight but totally flexible it is. You don’t get much as standard but what you do get is the ability to do is build your own language constructs: If you want classes you’ve got the tools to build classes, if you want mixins - you can, if you wan’t to program in a totally functional style its all there. You can prise my constructor functions from my cold, dead hands!
I’ve wanted a lot from the language but almost none of it is what’s being given to us in ECMA 4.
November 14th, 2007 at 7:22 pm
First, let me say that I disagree with your premise that ES4 makes JavaScript into Java. If anything, it makes it into Python. ES4 has modeled its syntax after Java’s, but that’s nothing new; JavaScript was originally designed to “look like” Java and it would be silly to move away from that convention now.
(Also, ES4 isn’t “starting to” look like Java; we’ve had glimpses of this syntax ever since the first Ajax Experience 18 months ago, when Brendan gave the first widely-publicized talk on the matter. ES4 has an active mailing list. This language was not drafted in secrecy; where were these complaints one year ago?)
I admit that I will never use 80% of what is being added to the language. The other 20%, on the other hand, is freeze-dried awesome — getters and setters (which are in SpiderMonkey but not in ECMA-262), operator overloading, magic methods, iterator/generators, block scope, the intrinsic namespace, and much more. I have no personal interest in the optional type annotations, but if they help secure the language itself and get it onto more devices then I’ve got no problem with them.
Ideally I’d want a language that’s not as expansive as ECMAScript 4, but far more expansive than the “ES3.1″ that Crockford is talking about. I would much rather use only 20% of ES4 than be stuck with a language that fails to meet my needs.
Because of all this, and because nitpicks about ES4 will simply delay its implementation in all browsers, I’ve accepted what I perceive to be bloat in ES4. Standards bodies are about compromise.
Your language isn’t going anywhere, Dustin. Arguing that it should no longer be called JavaScript is an appeal to semantics; mourning the soul of the beautiful language you loved is an appeal to aesthetics. These issues aren’t unimportant in the general case, but they fail to sway me in this case: you can continue to write ES3-style code for the rest of your life, romping around in a field of bunny rabbits and daffodils.
How can one survive the world of client-side web development if one is not a pragmatist? My job is all about solving problems.
November 14th, 2007 at 8:03 pm
I would tend to agree and submit that PHP5 is a good example of this problem. While there are some good additions and fixes in PHP5, the effort to make it more Java like is serious turn off.
November 14th, 2007 at 10:00 pm
Hi Dustin,
You wrote: “Besides, most object-oriented idioms already have a way of being applied to the JavaScript language without introducing these so-called features.”
But this is vacuous. You can apply “most object-oriented idioms” in C, or Fortran (well, Ratfor anyway). But why should you have to bend over backward like that? The same question goes for JS, which while flexible has severe limits when pushed to large scale and hostile environments.
Two questions:
* Can you prevent someone from adding properties to your objects, possibly confusing your code (or others’ code) into mistaking them for objects of a different “type”?
* Can you make names in the global object that mean what your code thinks, that won’t be hijacked by some other code, or inadvertently clobbered?
The idea that JS as it is today is a thing of beauty, I find disingenous. Doug Crockford at least hits the Ecma-standardized language with as much criticism as praise, and tries to sell his “good parts” subset as the one true way. But I’m sure many others, possibly including you, could not agree on that one-true-way subset. That’s because there is no such subset for all users, and there never was.
Meanwhile, in spite of books making a valiant attempt to teach people to make do with too little, JS is under withering assault on the web from languages hosted by runtimes such as Silverlight and AIR. And for good reason: JS1.x can’t even offer two crucial integrity features that the questions I pose above point to.
In my view, siding with Microsoft as they stall the web is only going to make your books obsolete sooner, as C# on Silverlight and WPF rises.
Oh, and drop the “they’re making it Java!” line, please — no one paying attention is buying it.
/be
November 14th, 2007 at 11:15 pm
Interesting. I would have thought that concepts like namespacing and packaging built into the language would be a positive for you. While its true that there has been lots of negative stuff written about ES4, its seems weird that people are overlooking the positives:
* things like optional data typing will help make JavaScript run faster in web browsers;
* private functions, namespacing and packaging will help keep libraries from trouncing each other;
* a real Map object instead of hacking Object;
* lots of other stuff you could like or not like;
There is a lot in ES4 that could really help JavaScript libraries, for instance. ES4 isn’t for everyone. That 90% you mention can keep using their current level of JavaScript. They may never need ES4, just like they may never need JavaScript Design Patterns. Why should JavaScript languish while other languages evolve? I’m not really shocked over the ES4 debate, it seems to happen anytime a language wants to move forward.
November 14th, 2007 at 11:15 pm
“it seems as though the only ones who can save us from a tragic overhaul of the beautiful language is Microsoft”
Oh the irony…
I think JavaScript is pretty neat as it is, it should be kept simple. I don’t think it was intended to be a full-blown programming language, and to me, it isn’t. It’s useful for making web pages interactive, above and beyond standard HTML.
November 14th, 2007 at 11:40 pm
[…] Putting Java in our Script, our unfortunate doom […]
November 15th, 2007 at 1:03 am
Two cents:
1) I haven’t read the ES4 spec, but I’m guessing it’s not specifically a Java thing, but rather to make JS into an OO language.
2) My only wish is that the industry can standardize on, at most, two browsers. I waste too much time makin’ it all work.
I think it’s time to become a DBA.
November 15th, 2007 at 2:30 am
Dustin,
Out of interest, what would you propose instead? Am I right in thinking that you’d prefer fixing/extending JavaScript that we have today keeping it in line with its roots - as opposed to extending it into a language which is similar to Java?
I do appreciate where you’re coming from. If it were me I’d be inclinded to fix/extend the current JavaScript language in tune with its heritage and, if required or inclinded to, develop a new and completely separate “Language X For Browsers” - that has its roots in the Java/C#/.. type head space.
Al.
November 15th, 2007 at 2:58 am
This reminds me a bit of the transitional period Flash had. Even now the prototype keyword is still allowed although rarely used in favor of traditional oo structures. Unlike Flash though, front end engineers will have quite a wait until adoption would be high enough for use.
November 15th, 2007 at 3:06 am
Dustin:
“Who 90% of their users are: Web Developers”.
That sounds to me like trying to portray front-end developers as web scripters, coding their 10-line scripts without any design/architecture in mind. Maybe nobody else dares to touch JavaScript with a 10-foot pole. Would be nice if ES4 could change that.
Grant:
Keeping JavaScript clean and lean I can understand. Bending over backwards to implement features that the language was never designed to support (like the famous module pattern), producing code that works but is unreadable and cluttered, that I cannot understand.
If as you say all the design patterns can be implemented as it is, adding syntax sugar to actually have them readable hardly makes the compiler twice the size. (Which sounds like FUD somebody should address soon.)
And the things that are not possible right now (like optional strong typing) have potential to both speed up the language and ease development.
November 15th, 2007 at 7:20 am
I think first JavaScript must be cleared from current language errors ( things link with(), globals, reserved words used as object literals, ….) and then to look for adding new staff, that is mostly wanted by people who never work with JavaScript. I personally like a lot prototype -cal nature of JavaScript. And if some want to change the entire language, why they don’t create brand new language…
November 15th, 2007 at 10:32 am
“Why bother implementing all these features that introduces another object-oriented style into a language that already has one”
Because the OO style the language already has is a black art - it’s barely documented, and when documented (outside of Crockford’s efforts), it is often poorly written and inconsistent. Developers from other backgrounds frequently throw up their hands in disgust at the language’s “quirks” - the warts and lack of documents make the language a disaster for maintenance and bringing new resources to large projects.
Just because you’re an expert at it doesn’t mean it’s best for the future of Web. It might have been nice if Javascript / Actionscript had gone more the way of Python (as opposed to Java), but you need to consider the needs of the many. While the non-typed nature of our current Javascript eases speedy development for small projects and 1-offs, the future direction will inevitably help projects (and estimation) become more predictable.
November 15th, 2007 at 11:31 am
At first I wasn’t too concerned about the ES4 spec, but after a while I decided to change my mind.
I agree with you Dustin that adding much, not necessarily all, of the OO parts to JavaScript can only impact performance negatively.
That’s really my big issue with ES4. If I were to suggest changes to the current form of ES, I would suggest that the same origin security model be replaced with something better, and a few other bugs like the reserved words can’t be object properties unless they are quoted need to be resolved. The security model is the big issue though.
Since I am a web developer, the ES standard doesn’t mean a whole lot to me directly. The browsers work off of it, so really I rely more on the browsers. Most of what web developers would like is to be able to code the same regardless of the browser. It’s such a huge pain to have to code for IE, FireFox, Opera, and others rather than just coding. I don’t care how the internals are implemented, just provide a common “API” to use.
November 15th, 2007 at 4:15 pm
Java is that Coffee from Jamaica?
November 16th, 2007 at 7:25 am
JavaScript with “multi-inheritance”? You must be kidding, No one can achieve this feature with the single prototype chain, and for ES4, you think the Microsoft can save the old classical JavaScript? damn, Microsoft has never improve their js interpreter, and the IE team have updated their js interpreter except for some security bugs for over 7 years, Chris wilson is lazy guy who never want to improve something which is buggy and broken. I expect the new version of ECMAScript and JavaScript, And the best testment for the new language is the web developer, you can choose to write the prototype like code or to use the class style code, Do not too much take care about it, it is just a innovation of the language, but for the core language it is still based in prototype chain or something like the scheme and lisp. And JavaScript 2.0 will be seen by the web users most quickly will be next year’s winter the firefox 4, and flash programmer with as3 likes the new class style very much.
November 16th, 2007 at 11:20 am
I had considered writing a post expressing similar views. Now I get to let you take all the heat and just nod silently in agreement like a coward from my cube (sigh of relief).
November 16th, 2007 at 12:41 pm
What the h**l f*****g s***t **** ***** *** ** ******** is happening?!?
Please, wake me, I’m having a nightmare!
:)
No, really, some of us spent a life to learn Javascript and love it.
I hope they won’t be so stupid….
November 17th, 2007 at 5:40 am
I’m not in favor of most of the proposed changes either.
Javascript’s biggest problem right now is not the language itself (although eliminating those unnecessary reserved words and fixing up some minor details would be nice), but rather the poor standard library.
I’m particularly baffled by the type annotations. Type safety as a programming pattern is bs for a dynamic, interpreted language — very few programming errors are due to having the incorrect type in a loosely typed language (or in a strongly typed language for that matter). Once you introduce strong typing, you then wind up just needing kludgy workarounds like generics to gain back the flexibility that you had to begin with. People have been using void* in C for 30+ years and type errors are simply not common enough to justify the loss in flexibility. You could theoretically continue to use containers of Object, but then people start whining about type safety and you’re forced back to the kludgy stuff.
Packages would be nice to have, but honestly this is a job for an offline pre-processor, not a language feature.
Classical classes are basically a big “meh”. It’s sugar that does nothing meaningful.
Interfaces could be cool, but the gain is almost entirely in terms of documentation rather than actual practical gains.
Static — pointless, I can just add it to the base object rather than the prototype and it serves the exact same purpose.
Overloading — awful, awful idea that just leads to bad code. There’s a reason why so many C++ and Java style guides frown upon overloading (especially operator overloading, probably the worst idea in the entire C++ language)
Assuming language features like private members or strong typing are going to make your app any more secure is laughable. If somebody was able to inject code into your page, you’re screwed no matter if you’re using ES4 or not.
Again — the only people who think that the problem with JS is the language itself are people who don’t really work with the language and simply want it to be more like one of the C++ clones (C++, Java, C#, etc.). People who work with it every day are finding that the real issues are that the libraries we have suck, DOM sucks, the security model sucks, and buggy implementations suck.
Keep your classes and interfaces, just give me a real socket (or at least HTTP) library instead of the dirty hack known as XHR. I don’t give a damn about type safety, how about access to binary file contents? How about a standard xml parser?
It’s the library. Improving the language but making us use the same crappy library is not going to improve the lives of any developers, it’ll just make people who aren’t even writing JS anyway stop saying that it isn’t a “real” language just because they don’t understand prototype or functional programming.
November 17th, 2007 at 7:30 am
After one day, I have thought this problem even more deeply, that is to say, my opinion is JavaScript is simple, ye that is right, and ES4 haven’t change the scope chain and prototype chain of the JavaScript’s core feature right? And ye many web developers are learning the JavaScript, and found to master this kind of flexible and smart language and feel very successful, but that is not good for the whole web developping, And old OO style with class interface package ….this old OO style wrapper is quite convenient to many java c++ programmers, and for them it is good for them to use js2.0 to alter the DOM, so that is good for the whole web developping, and It won’t change the smart and flexible spirit of the JavaScript
November 19th, 2007 at 10:29 am
I mostly agree with Justin’s observations, and want to add this:
Why Fix Something That Is Not Broken?
JavaScript has been through many years of development. Albeit, there has not been as much bug fixing as I would like to see; however, the language is stable and works on all platforms. By making such a drastic change as JS2, you risk all the stability and interoperability that has been nearly perfected. (yes, JavaScript is interoperable; it is the DOM implementation that most browsers differ on).
What Is Wrong With A Prototype Based Language?
JavaScript is a prototype based programming language. There are other prototype based languages. There is nothing wrong with prototype based languages. It is just another OOP paradigm with advantages and disadvantages, as with classical OOP.
The Solution:
Do not change JavaScript. Keep JavaScript as JavaScript. There is no reason to throw away 10 years of best practices and community development because some people are too lazy or drank the “Classical OOP” cool-aid. Take ECMA 4 and create a new scripting language. There has not been a new scripting language added to the browsers for years and ECMA 4 is different enough from JavaScript to be an entirely different language. This way you get the best of both worlds. Everything ever written in JavaScript will still work and you do not divide a community, and everyone who would rather use classical OOP has that opportunity.
Also, now would be a great time to fix bugs in JavaScript and create a uniform DOM implementation across all browsers. Actually, the later would be a much greater accomplishment that JavaScript 2.
November 27th, 2007 at 8:28 pm
I still remember when back-enders would recommend server-side browser-sniffing to send custom js to Netscape. Scope would creep like a SoCal wildfire once you got into DHTML.
Then a grip of companies died or went dormant, and guess what? Javascript blew up and spearheaded the real internet boom.
The Javascript language needs to be static so that its developers can be dynamic. Contrast that with Java, where its devs are too busy fighting about how to use it to do any innovation. JDO vs. EJB, JSF vs. JSP, JRuby etc.
December 1st, 2007 at 6:58 pm
I don’t understand how anyone can be opposed to a specification that’s 100% backwards compatible with the existing implementation.
If you don’t want the new bits, you don’t have to. use them. Just pretend they’re not there and carry on as you are today.
New bits are important to draw people away from proprietary solutions that are already starting to make an impact. Clarification of existing bits is always welcome, as far as I’m concerned.
December 5th, 2007 at 1:26 pm
Ben, as far as I can tell the biggest fear is that the added bits will impact performance (insert sarcastic “blazing speed of Java” comment here). I don’t know if that is a valid fear or not.
There does seem to be another fear that plays into it, the “Please, wake me, I’m having a nightmare!” demographic that spent a long time learning the ins and outs of the current language and fear changes away from it. But as you said, if it is 100% backwards compatible then this is a non-issue. Unless best practice becomes something that uses the new features, and they have to learn new stuff. Then they are screwed.
May 28th, 2008 at 7:36 am
Unless best practice becomes something that uses the new features, and they have to learn new stuff. Then they are screwed.
It’s not a matter of having to “learn new stuff.” I think most of us know how to use “classic OO.” For in-browser code and many other uses, some of us find the prototype model a better fit. I worry that the Java/C++/whatever systems guys, who tend to run the show on most projects and who never liked or really got our hippie object system anyway, are going to be the ones who decide (without ever having used the language) that “best practices” preclude using the object system as we’ve done.
Because the OO style the language already has is a black art - it’s barely documented, and when documented (outside of Crockford’s efforts), it is often poorly written and inconsistent. Developers from other backgrounds frequently throw up their hands in disgust at the language’s “quirks” - the warts and lack of documents make the language a disaster for maintenance and bringing new resources to large projects.
So the solution to a lack of documentation is to bolt on an entire extra object system?
May 28th, 2008 at 8:02 am
@kevin: right on. I think you hit every nail square on the head.