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.
We can't expect support for Javascript 2 in Firefox until the next version? But I want it to magically appear in the current one!
The only thing is... I'm worried about how much damage its replacement will cause.
Modding Trolls +1 inciteful since 1999
"[...] use JavaScript as kind of an underlying assembly language [...]"
VBScript sucks balls and Javascript is capable of getting the job done.
"Thanks for all the money you paid to us. We've used it to buy off ISO among other things" -Microsoft
I wholeheartedly agree with Brendan that we should at any cost stop JavaScript in particulat and Ecmascript in general from being as painful as Java in any way possible. However what we should do is not only improving all of the ECMA-262 derivatives but to make a systematical progress towards better flexibility and interoperability of various scripting approaches in the future. Take for example the wonderful project by Mehmet Yavuz Selim Soyturk called PJS which is an important step in the direction to allow the Parrot virtual machine, designed to run Perl, Tcl, Javascript, Ruby, Lua, Scheme, Befunge, Lisp, PHP, Python, Perl 6, APL, Java, .NET, et al., to run on JavaScript, so all of those languages could be used together to enhance your browsing experience on the Web. For this to be even remotely plausible the JavaScript must be as flexible and as fast as possible because it would basically mean running high-level language code compiled to the Parrot intermediate representation (PIR, or IMC), that converted to the Parrot assembly language, assembled, linked, converted to Parrot bytecode and then execuded on the Parrot virtual machine or PVM which would itself be a large JavaScript interpreted script running in a Web browser, running in the operating system... You get the picture. A logical step forward would be to include PVM in all of the major browsers to run the Parrot bytecode natively and efficiently in the browser. There are already plans to include PVM interpreter in Firefox which means it will be available as a viable target for scriping dynamic html pages for all of its derivatives like Camino, Galeon and Konqueror. Hopefully the commercial browsers would follow (the Artistic license is not anti-commercial like GPL so there should be no legal problems with the integration). I really look forward to the future of perfect interoperability when every single Web page could potentially run scripts written in literally dozens of programming languages simultaneously. One day we will experience that synergy thanks to people like Brendan Eich,Mehmet Yavuz Selim Soyturk, Larry Wall, et al. if they only agree to work together on one common solution to the big mess of Web scripts that we have today. Let's all hope they will.
Karma: Positive (probably because of superiour intellect)
But really I think it shows the understanding Eich has for the thousands of codemonkeys hammering away at JS for IE. I'd be screaming too if I was coding JS for IE.
On the other hand, I've had the (dis)pleasure of a rollicking night of Victory Golden Monkey followed by a visit from the Beer Monkey. Waiting for MS to make IE support JS2 might cause an additional night or two like that.
FWIW, the Beer Monkey usually howls, rather than screams. YMMV... depending on the quantity of Golden Monkeys consumed.
"Trolls they were, but filled with the evil will of their master: a fell race..." -- J.R.R. Tolkien on Olog-hai
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.
This site has an example of Javascript 2, and a translator from Javascript 2 to the current version. I really like the type-safety features and the MUCH better way to do OO.
In response to the parent, in the article they talk about how Microsoft is fixated on 3.1 and not 4. Hence, there is "Project Screaming Monkey" which aims to create a scripting engine for IE that can run Javascript 2 and not depend on Microsoft to support Javascript 2. Then, IE can support Javascript 2 (through the Flash Player - full details in the article). I wonder if it is possible to do something similar for Firefox. Perhaps via a plugin? But I suspect performance would suffer greatly. Or maybe 4->3.1 translator like at ecmascript4.com that would do an "on-the-fly" translation.
Vivin Suresh Paliath
http://vivin.net
I like
Eich says: "Some of these techniques, like HotRuby, actually translate Ruby into JavaScript."
HotRuby implements, in JavaScript, a VM that executes Ruby 1.9 bytecode; it does not translate Ruby into JavaScript.
That's kind of misleading: What he actually says (from TFA) is "They won't be in Firefox 3. They won't be in probably the 3.1 that we've talked about doing, but they might be in our [nightly] builds, our trunk builds. It'll be like a draft version of the spec, so we might call it JavaScript 1.9 or 1.99. We don't want to get people to confuse it with what becomes the final spec, but we have to be able to test it with real programmers and get usability feedback."
I really like javascript as a language, independant of webapps. When I recently wanted to embed a scripting language in a C++ program I work on, I seriously considered javascript, as I thought more people would know it than lua and python. There does not however seem to be an easy way to embed javascript in an arbitrary program. Is there some reason it isn't suitable for this kind of thing, or is it just the browser writers embed the javascript too deeply?
Combination - fun iPhone puzzling
Here's an overview of ECMAScript 4, the new version of JavaScript:
http://www.ecmascript.org/es4/spec/overview.pdf
It sure looks to me like they are taking all the coolest stuff from Python and grafting it onto JavaScript.[1] The result will be a language a lot like Python, but with code blocks wrapped in curly braces and no significant whitespace.
One of the biggest changes will be a class inheritance model much more like Python's. The prototype-based inheritance will still be available, but I for one will be happy to use the new model.
Already, my favorite features from Python have been grafted on to JavaScript, and are available right now in Firefox 2:
http://developer.mozilla.org/en/docs/New_in_JavaScript_1.7
Steve Yegge has said that he thinks he knows what the "Next Big Language" will be. I think he is talking about JavaScript, and I think he may be right.
steveha
[1] If you are a fan of some other language, it may look to you like they are grabbing cool things from your language. And far be it from me to argue about which language a feature was "really" borrowed from. Python borrowed much of its cool features from other languages anyway.
lf(1): it's like ls(1) but sorts filenames by extension, tersely
I can't believe nobody brought up GWT (http://code.google.com/webtoolkit/) yet.
GWT is a system put out by Google whereby you write your code in a subset of Java and then it compiles the Java down to cross-browser compatible speed and size optimized Javascript.
The implementation of Java is pretty good and includes just about everything you would expect except for threads. It's absolutely effortless to program in compared to hand coded Javascript -- especially for large projects.
The other benefit is "hosted mode" whereby you run your webapp in a special runtime that lets one use Eclipse's modern interactive debugger to fix bugs in the Java code that gets turned into equivalent Javascript.
If you want to see a neat demo of what can be done with GWT check out :
http://www.gpokr.com/
You mean like a formal standard for the language? That's ECMAScript. Do you mean a standard way of interfacing with the browser? That would be DOM. Or do you mean some practical tests of scripting to ensure that different browsers behave consistently? Sounds like Acid3.
What a fool believes, he sees, no wise man has the power to reason away.
unless someone disables javascript ... or uses a browser that cannot do it ... I'll stick with SSL
"Freiheit ist immer auch die Freiheit des Andersdenkenden" - Rosa Luxemburg, 1871 - 1919
Not to be pedantic, but this isn't strictly true. It's very difficult to even write an iterative solution in, say, Prolog, and you'd probably have to abuse a database to do it, and it almost certainly wouldn't be faster. By contrast, tail-recursive calls tend to be optimized in many implementations so you hit speeds on the order of many iterative constructs in interpreted environments.
And at the bottom of this issue is the fact that it's an implementation issue, not a language issue. There's no reason for certain recursive expressions not to be as fast as certain iterative ones.... except the compiler or interpreter doesn't output them that way.
Tweet, tweet.
WebKit and Firefox have their own share of proprietary functions that are supposedly intended for internal/embedded use only.
-- If you try to fail and succeed, which have you done? - Uli's moose
Isn't that more or less what they always say when they come up with some new-fangled language?
Are you adequate?
Some sites already do this, although not with RSA, but with MD5 or some other cryptographic hash, of which there exist JavaScript implementations which are plenty fast. See the LiveJournal login page. There is also HTTP digest authentication, but that requires browser support and users are used to typing their user/pass into an HTTP form, not using HTTP auth.
Centralization breaks the internet.
Eich talked about some reasons for the 3.1 update to the language. Based on what I've heard from both Doug Crockford and Chris Wilson is that it would be a good idea to fix some of the really big issues in the current version of the language before throwing a new OO model and type system on top of it. It's best to build on a good foundation. There are also concerns about making the engine slower, but I'm waiting to see benchmarks before making my judgement. Personally I like the programming model of JavaScript as it is, but I'm a minimalist when it comes to code.
unless someone disables SSL ... or uses a browser that cannot do it ... I'll stick with rot13
Also, non-leading whitespace is not significant in Python.
"Not an actor, but he plays one on TV."
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.
almost all modern browsers should be compliant to ECMA-262 (3rd ed), well, at least the wikipedia entry tells me that is so
As long as you stick to that, you should be totally fine. this is all you'll ever need for docs. I've yet to run into any standardization issues with javascript when coding for ff/ie. If you stick to the basics there really shouldn't be anything you can't do to break on either firefox or ie.
What are all these standardization issue people keep talking about? Can I see an working example? (this isn't sarcasm, I'm just curious what everybody is referring to - like I missed the party)
The ability to communicate via the electronic signals and display results on computerized devices is not Mozilla's or Microsoft's achievement. It is the humanity's achievement.
The international conferences are to be held organized by UN on this subject. We should not allow browsers or other programmes in our countries which are the result of petty squabbles between small groups of marketeers and programmers.
Buggy incompatible browsers should be banned by UN internationally as illegal drugs. Enough is enough. I do not want to see any more these ridiculous "if IE6", "if Mozzilla", etc. There should be the basic standards implemented by the international law, which would provide a safe and effective usage of Internet.
P.S. It's worth noting that trailing whitespace in Javascript may be significant. In particular, under some circumstances, a trailing end-of-line will be treated as if it were a semi-colon...
"Not an actor, but he plays one on TV."
Are you sure you know the difference between the language and the proprietarty APIs the browsers expose to it?
sudo ergo sum
It's not about the speed of recursion, its about the inevitable memory footprint issue. A loop, while seldom as elegant, doesn't carry the memory overhead of a recursive function which must reach its boundary condition before beginning it's calculations.
Using a language like LISP or Scheme, you learn to love recursion for its elegance. But when you start trying to apply that love to real world problems you run into significant memory issues, along with a lot of flack from fellow programmers who don't appreciate being forced to read dense recursive code.
ad logicam Claiming a proposition is false because it was presented as the conclusion of a fallacious argument.
You know, Microsoft's street address also says a lot about their mentality.
That's a good point. I wrote some functions in Haskell to detect irregularities in large text files. I wrote with tail-recursion optimization in mind and got good space and time performance compiling with GHC, which is a *very* smart (and big and slow) compiler. That said, recursion is the natural idiom for a language built around recursively defined data types, which JavaScript isn't.
This is incorrect for the same reason that GWT code is larger than its pure Javascript brethren. For every cycle you save in GWT's compiler, you spend two more on being constrained by Java's class model. Javascript is a LISP-style language. Heavily dependent on concepts like loose object definitions and lambda code. (These's features are one of the reasons why LISP is easily one of the fastest languages in existence.) Jumping through the Java hoops only ensures that you will have more code than necessary, have to perform more operations than necessary, and will generally waste a lot of cycles that could have been eliminated in pure Javascript.
If only that were true. Try loading GWT in Opera sometime and see how well it works. What's that? You wanted to target devices like smartphones and game consoles? So sorry. No can do.
I understand quite a bit about HTTP caching. And having to include the com.whatever.MyClass.nocache.js ensures that older versions of IE will always need their cache cleared before the new component will be available. So you'll forgive me if I'm not impressed.
That's nice. You still have the most of the widget library, JSON library, networking library, and a few other libraries in nearly every component. They're recompiled into your code every time, ad nauseum. This creates an incredible amount of bloat that would be avoided in pure Javascript by separating libraries out into their own, reusable files. Even Google knows this.
IE-specific code should always be kept to a minimum. In my projects, that comes down to conditionally including runtime patches to IE's object model. So I guess you could say that I'm one step ahead of GWT.
You're assuming that most of these libraries are good examples. As it so happens, most common Javascript libs are universally bad. I generally try to avoid them like the plague as they are bad enough to make GWT look like an amazing solution.
GWT is not an amazing solution. It's a decent solution that does a fairly good job for those unfamiliar with Javascript technology. But if you actually know Javascript well, you WILL be regularly frustrated by it.
For the record, I need to stop replying to anonymous cowards. They never know what they're talking about. :-/
Javascript + Nintendo DSi = DSiCade
Both methods are intended to protect passwords, not sessions. Assuming MD5 is sufficiently secure - which it is believed to be for this purpose despite some attacks on it because both methods use a challenge string which is somehow concatenated with the password - someone reading the traffic would be unable to get the user's password and therefore unable to login as them.
On the other hand, the LJ method does not prevent session hijacking by reading the traffic, copying the cookie, and using it before the user logs off or their session expires. LJ does have an optional security measure to allow access from only your own IP, but if an attacker is already reading your traffic, they are probably also on the same network as you so they could send packets as from your IP.
Digest auth goes a bit further and authenticates on every request with the request URI as part of the hash, so an attacker could change submitted POST data or pages sent to the client in attempt to hijack the session, but could not simply steal it and browse any page. That is, the attacker has to be actively changing the communication between the client and server to even hijack a session while with LJ's auth (and in general most auth on unencrypted websites) they only need to read the cookies.
Both methods make no attempt to hide the content of the website or information sent to the website; that's what HTTPS is for. They only make it nearly impossible to steal passwords and make it difficult to hijack another user's session.
Centralization breaks the internet.
It's obviously an internal pot shot at the screaming monkey Steve Balmer.
that you read up on tail recursion and the so-called Tail Call Optimization..
Calling php as the classical example of namespaces are not helping in designing big systems is like a joke.
That'd be a great point if that where what I'm doing, but it's not. I'm pointing to PHP as an example of a language that's thoroughly handicapped -- there is no natural mechanism for namespaces -- but has developers and projects who've almost entirely skirted the issue by using certain conventions.
The moral of the story isn't that PHP is Teh Awesome (it has many, many ugly warts, and even with the increased efforts at seeding a smarter development culture, many PHP devs and projects are still messes). The moral of the story is that with a good convention and initiated developers, many perceived handicaps rooted in missing mechanisms are mitigated or eliminated.
the newer efforts towards standardizing next versions of javascript try to tackle it.
Have these additional tools available may indeed turn out to be helpful for certain situations, but it's really a pretty good thing they haven't existed before now, otherwise, it's fairly likely there'd be even fewer people who understand the alternative philosophy, mechanisms, and convention that already exists. And if the new features dilute a culture where people understand these things, it may not be a net win.
Btw. as for rails, it works because the basic structures are outlined by the codegens rails has, the programmer is basically pushed on rails :-) Which means rails enforces certain structures to bypass certain limitations of the underlying language!
I don't really use Rails or Ruby a ton, but this seems wrong to me. The conventions of Rails have nothing to do with any "limitations" of Ruby. They're abstractions for dealing with certain sets of recurring problems, specifically in one type of broad modeling useful for web apps. Like any abstraction, there are real limits to the breadth of situations it's designed for, but the basic ones behind Rails are quite flexible if you understand Ruby and have more than passing familiarity with Rails. Rails is a case not of convention substituting for missing mechanisms, but convention enhancing and enhanced with mechanisms of a broadly powerful dynamic language.
Tweet, tweet.
There is no memory overhead for tail-recursive calls - they are precisely equivalent to a loop.
"Not an actor, but he plays one on TV."