Slashdot Mirror
Brendan Eich Discusses the Future of JavaScript
snydeq writes "JavaScript creator Brendan Eich talks at length about the future of JavaScript, ARAX, disputes with Microsoft, and the Screaming Monkey scripting engine for IE in an interview with InfoWorld's Paul Krill. JavaScript 2, which Mozilla's Eich expects to be available in some form by the end of the year, will 'address programming in the large.' To do that, Eich hopes to improve the integrity of the language without sacrificing flexibility and making JavaScript 'painfully static in a fixed way like Java does.' Eich does not expect Firefox support for JavaScript 2 until at least Version 3.1 of the browser. As for Internet Explorer, Eich explains how Screaming Monkey will help bring JavaScript 2 to IE should Microsoft drag its heels on providing meaningful support."
is here.
IMO the changes proposed for js 2 aren't very exciting. The biggest problems with js aren't really problems with the language design, they're problems with the lack of standardization in the interface to the browser. I don't see the burning need to make js more oo, more statically typed, or more like java.
What I think really will be cool is the synergy between js and html 5. Html 5 has lots of good features for doing web apps, including audio, persistent storage, and graphics (canvas, inline svg without xhtml). Most of this is stuff you could have done before using java applets or flash, but now you'll be able to do them using a w3c standard that the vast majority of users will probably end up actually having supported in their browsers.
Find free books.
I've used GWT. Here's the long and short of it...
Pros: GWT is very cool in that you can quickly write Java-based interfaces that run in the web browser as Javascript. Because GWT includes a wide variety of components, interfaces are super-simple to create. You can even make your own widgets and reuse them as libraries to make even more complex widgets.
Cons: (Better grab a seat.) It's nearly impossible to debug code outside of the GWT test shell. Which really sucks if your code relies on a web application in some way, but you can't decipher "Error in line 127: b is null". Which brings me to the next major problem. GWT does not integrate with Javascript very well. You can use a JNI-style interface to run bits of Javascript code in a Java method, but for the most part the worlds stay far apart. Which means that you can't easily use GWT objects or Javascript objects interchangeably to solve problems. More often than not, a Javascript object would be faster than the Java code you're writing. But since you can't intertwine them...
Which brings me to the next con. Because the layout is determined by the construction of the built-in widgets, it's often difficult to achieve a layout that meets the specs. Doing simple things like removing spaces from tables, or applying pre-existing styles invariably end up more difficult to do than they should be. And even when you can apply a style, it applies the style to an element which is inside a container element (or vice-versa), thus preventing you from styling the layout of the specific element you're trying to target.
Another frustrating aspect is that GWT dumps out hashed file names. Different hashes for every compile, too. Which wreaks all kinds of havoc with source control systems. Ideally you'll want to generate the Javascript code at compile-time because of this mis-feature. Unfortunately, GWT does not ship with an ANT plugin. You can find a few that people have made, but I haven't yet found one that's of particularly high quality.
Generated GWT code is obviously quite large. Whatever you save with GWT's obfuscator is more than made up for by the fact that GWT compiles in its libraries every time.
Last but not least (and quite possibly the most frustratingly), you can only plug the components together at compile time. Mixing and matching renderers, data models, and I/O backends at runtime is pretty much a no-no. You get it right when you compile it. Period. Which really reduces the flexibility of the technology. Instead of being able to combine plugins at runtime, you have to create a new project for every variation of the component. Alternatively, you can write your code to have a half-billion runtime settings.
--
If you want my advice, learn Javascript. GWT may provide you with a good stop-gap solution, but the trade-offs can be incredibly painful at times. And since Javascript is obviously not going anywhere, you know you'll get a good return on investing in the education. If you need a good place to start, Douglas Crockford has an excellent introduction to the language here. Also, trying READING the Javascript Client Guide. It really does explain the language well, including some of its incredibly advanced features. (That 95% of so-called JS coders have no idea exist.) :-)
Javascript + Nintendo DSi = DSiCade
> "If you could do Java over again, what would you
> change?" "I'd leave out classes," he replied.
"After the laughter died down, he explained that the real problem wasn't classes per se, but rather implementation inheritance (the extends relationship). Interface inheritance (the implements relationship) is preferable. You should avoid implementation inheritance whenever possible. "
Not the same as saying that he didn't want java to be OO.
http://www.javaworld.com/javaworld/jw-08-2003/jw-0801-toolbox.html
Sneak teach kids Algebra using a game
Not the same as saying that he didn't want java to be OO.
Oh, no, that's not the point at all. The point is this:
OO != Classes
And in fact that Classes may not be the ideal way to orient a program around objects. And the bonus point is that the person who implemented what's the arguable current king of OO languages understands this. He's not the only one. The Drupal Devs also have a thing or two to say on the subject.
I'm very familiar with the Allen Holub article you referenced -- stumbled across it three or four years ago, and it eventually led me to buy Holub's book on patterns. The takeaway point about the hazards of implementation inheritance is one that I think he overstates, but it's absolutely necessary given the way most people learn OO programing these days. Most books and tutorials hammer on extends and necessarily use examples of class hierarchies because it's necessary to teach what all the OO syntax does, but this really isn't what OO programming is about.
The interesting thing is that Javascript is one of the few popular languages where this is quite clear. There are weak clases, there is no "extends", and therefore very little magic implementation inheritance. You can code up syntax for this, if you like, as many of the major libraries do, which I think illustrates the power of the model and the language, but by and large, the prototype inheritance method means that you're doing interface inheritance or very explicit implementation sharing. This means the pitfalls Holub points out are easier to avoid, and there's many other bonuses. It also unfortunately means a bit extra work in some cases where implementation inheritance is handy and less dangerous, but it's not all that much, and I think the tradeoff is worth it.
Now, the next version of Javascript will particularly be nice for developers of libraries who have reasons not to trust the developers using what they're producing, because they'll be able to freeze things they can't freeze now with the static typing and class definitions.
But I'm pretty afraid a prevalent culture that seems to have a fairly narrowly scoped idea of object orientation and "best practices" is going to clap their hands and grab onto the familiar classes as they approach Javascript, rather than really understand the breadth of the language, and in 3-4 years, you'll have newly-minted team leads fresh from their recent readings of Fowler and GoF talking about tortured design patterns using static types and classes when a little sprinkling of dynamic language will do the job.
Please, allay my fears by not saying "JS2 finally bring real OO programming to Javascript."
Tweet, tweet.