Beta

Slashdot: News for Nerds

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Brendan Eich Discusses the Future of JavaScript

ScuttleMonkey posted more than 6 years ago | from the everyone-should-know-a-little-javascript dept.

Programming 164

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."

cancel ×

164 comments

My $0.02 worth (-1, Troll)

Archangel Michael (180766) | more than 6 years ago | (#23910563)

If the future of Javascript doesn't end with a wimper, then it can't be good.

Re:My $0.02 worth (1)

Gewalt (1200451) | more than 6 years ago | (#23910625)

The only thing is... I'm worried about how much damage its replacement will cause.

Re:My $0.02 worth (2, Insightful)

famebait (450028) | more than 6 years ago | (#23913869)

Are you sure you know the difference between the language and the proprietarty APIs the browsers expose to it?

1-page version (5, Informative)

taupin (1047372) | more than 6 years ago | (#23910587)

is here [infoworld.com] .

Re:1-page version (-1, Flamebait)

Anonymous Coward | more than 6 years ago | (#23911791)

Please kill javascript. It makes pages load much slower. The gratuitous use of javascript to load pages is silly, especially when it is right beside a plain html link that does the same thing.

Javascript is dangerous and can hijack your browser to an unknown and unwanted malware site.

There is very little that javascript offers that needs to be done at all. Please eliminate it from you web sites.

Regards,

Mike Monett

Really? (3, Insightful)

Goaway (82658) | more than 6 years ago | (#23910595)

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!

Re:Really? (1)

UnknowingFool (672806) | more than 6 years ago | (#23910683)

Considering Javascript 2 isn't really done until the end of the year, there's no reason it should be in the current version. Remember 3.1 will be a point release not a full release so 6 months away to the next point release isn't unreasonable.

Re:Really? (1)

Twigmon (1095941) | more than 6 years ago | (#23910889)

Also, the technology used in web development lags about 2 years behind current browser technology.

Unfortunately, it is going to be a very log time until Javascript 2 is used in the real world.

Re:Really? (3, Informative)

Demiansmark (927787) | more than 6 years ago | (#23912279)

RTFA. The interview ends with a discussion about how they may be implement JS 2.0 with or without the support of IE through Screaming Monkey, and if it rolls out with Firefox 3.1 then the normal cycle of waiting years for the majority of browsers to support it shouldn't apply.

Re:Really? (1)

Mongoose Disciple (722373) | more than 6 years ago | (#23912723)

You're assuming everyone uses the most current version of their chosen browser. That would generally be the smart thing to do, so of course it's not what people as a whole actually do. :)

Here's what Javascript 2 looks like (4, Informative)

vivin (671928) | more than 6 years ago | (#23910871)

This site [ecmascript4.com] 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.

Re:Here's what Javascript 2 looks like (4, Interesting)

weston (16146) | more than 6 years ago | (#23911487)

I really like the type-safety features

Fortunately, the type safety features will be optional.

and the MUCH better way to do OO.

This is a matter of opinion, and is definitely contested.

Q: "If you could do Java over again, what would you change?"
A: "I'd leave out classes" - James Gosling

Re:Here's what Javascript 2 looks like (5, Informative)

Pastis (145655) | more than 6 years ago | (#23912855)

> "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 [javaworld.com]

The Point: OO != Classes & imp. inheritance (5, Interesting)

weston (16146) | more than 6 years ago | (#23913099)

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 [drupal.org] .

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 [holub.com] . 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."

Re:The Point: OO != Classes & imp. inheritance (3, Interesting)

MemoryDragon (544441) | more than 6 years ago | (#23913819)

Actually I personally saw it always as the weak point javascript of providing class like constructs and no inheritance, instead exposing the virtual method table directly. (Prototype is nothing else) This basically ended in, colliding namespace constructs, different incompatible inheritance constructs by third party libraries etc... You cannot really design big systems without those two constructs, and javascript exactly is moving into that arena without being properly equipped for it.

In the end javascript is the classical example of a 95% academic language. Looks nice on paper, it is very fast in designing small systems, it is very flexible which makes the academic crowd cheer but fails utterly once you have to design bigger systems because the productivity of the language goes down the toilet due to the fact that vital 5% of the language are missing.

Re:Here's what Javascript 2 looks like (0)

Anonymous Coward | more than 6 years ago | (#23913583)

Javascript is OO without classes.

GP, if I understood it correctly, was not talking about leaving OO out, but about Class-based OO vs. Prototype-based OO. Because GGP mentioned a "_way_ of doing OO"

Re:Here's what Javascript 2 looks like (1)

MemoryDragon (544441) | more than 6 years ago | (#23913797)

This depends on the point of view, there was a time between 92 and 2000 when implementation inheritance was seen as the goto of the 90s, due to the strong binding of code it provides. The view has changed somewhat, also due to the fact that without implementation inheritance you have to rely on delegation a lot and you get a huge code bloat. To my knowledge the goto still is an antipattern, implementation inheritance never fully made it onto the anti pattern list and again is an accepted pattern among others.

Re:Here's what Javascript 2 looks like (1)

zoips (576749) | more than 6 years ago | (#23912683)

I really like the type-safety features and the MUCH better way to do OO. Javascript never really got prototypes right. I think the looks-like (duck typing) way of doing OO is very nifty, and prototypes (true prototypes like in Io and SELF) is probably one of the best ways of doing it.

Re:Really? (2, Funny)

Pollardito (781263) | more than 6 years ago | (#23911259)

since the last version prior to 3.0 was 2.0.0.14 [wordpress.com] , 3.1 might be further off than it sounds

Re:Really? (1)

Aaron B Lingwood (1288412) | more than 6 years ago | (#23913389)

I typed about:config but couldn't set dom.javascript2.enabled to true.

Ow. (4, Funny)

taupin (1047372) | more than 6 years ago | (#23910637)

This statement made my mind hurt:

"[...] use JavaScript as kind of an underlying assembly language [...]"

Re:Ow. (2, Informative)

Anonymous Coward | more than 6 years ago | (#23910821)

It means that the target language of the compiler is JavaScript. In this case, Ruby code, which the browser does not understand, is compiled to JavaScript code, which the browser can run. The association is that normally computer languages are compiled to some sort of assembly language, which is then compiled to object code.

Re:Ow. (0)

Anonymous Coward | more than 6 years ago | (#23911369)

This statement made my mind hurt:


"[...] use JavaScript as kind of an underlying assembly language [...]"

Morfik (proprietary) and GWT (open source) does this already. I must admit although it feels weird for some time, you get used to it.

History repeating itself - Javascript is the new assembly. And yet I wonder if devs of common browsers will ever introduce lower level primitives or ways to access to their Javascript runtime environments in the name of optimization and efficiency.

Re:Ow. (3, Interesting)

PCM2 (4486) | more than 6 years ago | (#23911571)

And yet I wonder if devs of common browsers will ever introduce lower level primitives or ways to access to their Javascript runtime environments in the name of optimization and efficiency.

I've heard it said that the JavaScript code output by GWT often gives better performance than hand-coded JavaScript, because the GWT compiler is free to use every dirty syntactic trick in the book to wring the most performance out of the code. By comparison, hand-coded JavaScript has to be read and maintained by humans. Almost everyone sacrifices a little bit of performance for the sake of being able to maintain the code. But since you don't ever maintain the JavaScript part of the GWT application -- you write in Java, maintain the Java code, and treat the JavaScript pretty much as bytecode -- there's no need to worry about whether the JavaScript is written in the "cleanest" way possible. It's OK for GWT to generate code that favors performance over any other criteria.

Javascripts popularity is no real suprise (2, Insightful)

pembo13 (770295) | more than 6 years ago | (#23910647)

VBScript sucks balls and Javascript is capable of getting the job done.

Re:Javascripts popularity is no real suprise (4, Insightful)

vivin (671928) | more than 6 years ago | (#23910751)

Javascript has the potential to be really useful. Well, it already is. I was at JavaONE earlier this year and I went to a few Javascript sessions. One of the most eye-opening sessions was the one where the presenter described Javascript as a LISP-1 language that just happens to look like C.

As far as improvement, I think it needs a proper object oriented model (the current one is far too confusing), and also should be friendlier to implementations that require recursion. You can write recursive code in Javascript now, but it's very slow. Iterative solutions are faster.

Re:Javascripts popularity is no real suprise (2, Informative)

pembo13 (770295) | more than 6 years ago | (#23910865)

Well iterative solutions are almost always faster across languages.

Iterative vs Recursive is an implementation issue (2, Informative)

weston (16146) | more than 6 years ago | (#23911897)

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.

Re:Javascripts popularity is no real suprise (2, Informative)

JohnnyBGod (1088549) | more than 6 years ago | (#23910935)

You can write recursive code in Javascript now, but it's very slow. Iterative solutions are faster.

Which means... it's pretty much like every imperative language on the planet?

Re:Javascripts popularity is no real suprise (3, Informative)

vivin (671928) | more than 6 years ago | (#23911141)

You can write recursive code in Javascript now, but it's very slow. Iterative solutions are faster.

Which means... it's pretty much like every imperative language on the planet?

Recursive solutions in other languages are slower than iterative solutions but not by as much as a factor when compared to recursive vs. iterative solutions in Javascript.

The Javascript interpreter in browsers does not really optimize recursive code. Compare this to other interpreted languages [acm.org] (this paper talks about LISP, and Javascript incidentally, is a LISP-1 language), or compilers. This is why most tips for Javascript optimization talk about removing recursion because of bad performance of recursive code in Javascript.

So if you're able to optimize for recursion in Javascript 2, it wouldn't impact performance as much as it does now.

Re:Javascripts popularity is no real suprise (1)

rolux (99682) | more than 6 years ago | (#23911233)

If you consider what these [crockford.com] guys [ejohn.org] are doing with JavaScript 1, then can anyone tell me why we need JavaScript 2?

(Hint: We *don't*.)

faster math for RSA (0)

Anonymous Coward | more than 6 years ago | (#23911397)

If JS was fast enough to encrypt in RSA with a a decent key length, you could use it for secure password authorization without the need for SSL. The server sends a public key, the browser uses it to encrypt the password in an onSubmit(). That would be great. The max I was able to do was RSA-16 (or something ridculously low) on a Pentium III when I tried a few years ago. Any more than that and a "stop script?" dialog popped up. You can't use a one-time pad because you have no secure way to send it to the browser.

Re:faster math for RSA (1)

gullevek (174152) | more than 6 years ago | (#23911853)

unless someone disables javascript ... or uses a browser that cannot do it ... I'll stick with SSL

Re:faster math for RSA (1, Insightful)

Anonymous Coward | more than 6 years ago | (#23912721)

unless someone disables SSL ... or uses a browser that cannot do it ... I'll stick with rot13

Re:faster math for RSA (1)

AnyoneEB (574727) | more than 6 years ago | (#23912119)

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 [livejournal.com] . There is also HTTP digest authentication [wikipedia.org] , but that requires browser support and users are used to typing their user/pass into an HTTP form, not using HTTP auth.

Re:Javascripts popularity is no real suprise (0)

Anonymous Coward | more than 6 years ago | (#23911405)

That's a really naive question.

It's not always what you can do with something but how it is done.

Why a c when there is asm. A c++ when there is c. I can go on for hours.

Syntax and built in functionality do matter and javascript is years behind in both.

Re:Javascripts popularity is no real suprise (-1, Flamebait)

Anonymous Coward | more than 6 years ago | (#23911601)

Crockford is a total douchebag. But not as much as javascript 2. Shitty solution for a non-existent problem.

Re:Javascripts popularity is no real suprise (1)

famebait (450028) | more than 6 years ago | (#23913879)

So we don't need to jump through the hoops that they do?
_possible_, they're supposed to make them easier too.

*rolls eyes* (1)

Estanislao Martnez (203477) | more than 6 years ago | (#23912089)

One of the most eye-opening sessions was the one where the presenter described Javascript as a LISP-1 language that just happens to look like C.

Isn't that more or less what they always say when they come up with some new-fangled language?

Re:*rolls eyes* (0)

Anonymous Coward | more than 6 years ago | (#23913171)

Except Javascript isn't "new-fangled", and Javascript IS Lisp-1.

Re:Javascripts popularity is no real suprise (1)

MemoryDragon (544441) | more than 6 years ago | (#23913855)

Problem with javascript is it looks nice on paper but fails miserably productivitywise in bigger systems. The main issues are, no dedicated namespacing which makes mixing of various libraries a real hell (no worries propotype will fix everything by simple hijacking the dollar operator which then is also used by jquery and others, also it makes huge sense to simply override the array so that other libraries fail....), the other really weak point lies in the way it exposes inheritance. It has semi like class constructs (everything is a function, even classes are functions) and then simply provides the virtual method table. The result was that every library added its own sometimes broken sometimes not but often incompatible way of inheritance to deal with the bigger codebase.

The third and biggest problem is the browsers themselves, javascript most of the times is used in browsers and then you have to program against a central singleton/beast out of hell. The dom tree with behavior different over most browsers. This singleton is an antipattern in itself, instead of having small page parts which are not influencable by others every code targetted against the page has to rely on this singleton and has to hope that no other code does some modifications which break things. Componentization is a hell in itself in such an environment. There are solutions to the problem but they only work on exactly one browser and leave the others out.

And yes javascript is very Lisp alike with functions being the core of everything if you drill down. It is a functional language in its core which looks like C, but that does not clear up its deficiencies for bigger systems. Sorry for that. I spend 90% of my coding time currently in javascript doing component programming and I really see the problems with it. The academic crowd might cheer, but I always love it when I have to leave javascript land for a while programming in other languages other areas of programming simply are way less painful. Javascript once things become bigger feels a lot like C++ in the pain it can inflict on the programmer, actually it feels way worse!

Re:Javascripts popularity is no real suprise (3, Informative)

famebait (450028) | more than 6 years ago | (#23913895)

That's what TFA and Javascript 2 is about: JS1 is the way it is because it was meant to be small and simple. Usage has changed and thus requirements, and JS2 is the first opportunity to fix the big things.

Re:Javascripts popularity is no real suprise (1)

Twigmon (1095941) | more than 6 years ago | (#23910901)

Well.. We will just use whatever tools we are given to accomplish what we need to do. Javascript is *almost* everywhere, and it is simple to build a site that degrades gracefully on unsupported browsers.

VBScript is not available on the number of customer machines as Javascript is.

Insightful (4, Interesting)

Mensa Babe (675349) | more than 6 years ago | (#23910667)

I wholeheartedly agree with Brendan that we should at any cost stop JavaScript [wikipedia.org] in particulat and Ecmascript [wikipedia.org] in general from being as painful as Java [wikipedia.org] in any way possible. However what we should do is not only improving all of the ECMA-262 [ecma-international.org] 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 [fulladsl.be] which is an important step in the direction to allow the Parrot [parrotcode.org] 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.

Re:Insightful (2, Funny)

lightversusdark (922292) | more than 6 years ago | (#23910709)

You can't spell superior.
Or use line breaks.

Re:Insightful (2, Insightful)

Red Flayer (890720) | more than 6 years ago | (#23910809)

Don't worry about it. Troll, (s)he is... better ask Surak. Or one of the other sockpuppets.

Re:Insightful (1)

Simon (S2) (600188) | more than 6 years ago | (#23910743)

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.
Just a quick note: Konqeror does not use jecko, the HTML rendering engline ff uses, but KHTML.

Re:Insightful (1)

Simon (S2) (600188) | more than 6 years ago | (#23910763)

jecko = gecko...

Re:Insightful (0)

Anonymous Coward | more than 6 years ago | (#23911567)

jecko = gecko...
jingo!

Re:Insightful (1)

Anonymous Coward | more than 6 years ago | (#23910761)

Mensa_Babe, did you ever hear of paragraphs or are they somehow beneath you?

I see loads of shit about parrot but frankly I can't focus on it (free as in too-much-beer). I like register based VM's and Tamarin (cool as it is) is never going to give other VM implementations (excluding luaJIT) the ass-kicking they so richly deserve.

Can you please do a cliff notes version for this inebreated AC? Many thanks...

Re:Insightful (1, Interesting)

Anonymous Coward | more than 6 years ago | (#23910943)

What I wonder is does the idea of embedding the Parrot VM into Firefox mean that the Mozilla developers have re-thought their stance on the "no threads in JavaScript" issue?

To me this is still the single missing feature that makes me believe that JavaScript is still a toy language that really shouldn't be used for anything major. Without dedicating a thread to the UI, there's absolutely no way to ensure that you have a responsive UI. It also makes unit testing certain things a huge bitch. The other serious issues that are being addressed in JavaScript 2 (packaging, typing, etc) are all basically annoyances compared to this issue.

Re:Insightful (1, Informative)

Anonymous Coward | more than 6 years ago | (#23913051)

You can sort of do threads in JavaScript.

Well, except you can't touch any UI, that's all single-threaded main-thread-only. That means you can never do it for web pages, because those things have a global object that's, umm, the window. As in, a UI thing. Oops.

Using threads in JS XPCOM components that never touch the DOM (which would be analogous to what a hypothetical Parrot VM would be doing; see also PyXPCOM) would work. Mostly. (The global object there is "BackstagePass")

You just have to ignore a few assertions.

Re:Insightful (1)

jo42 (227475) | more than 6 years ago | (#23912933)

That reads like marketing pablum...

screaming monkey? (3, Funny)

Red Flayer (890720) | more than 6 years ago | (#23910719)

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.
Maybe it's just me, but I'm curious why he would name it "Screaming Monkey". I could see maybe an allusion to speed ("screaming" is sometimes a term used to describe something going really, really fast so s/Grease/Screaming makes sense, I guess).

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 [urbandictionary.com] . 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.

Re:screaming monkey? (0)

Anonymous Coward | more than 6 years ago | (#23910825)

Oh, that's named after Ballmer, no doubt.

Need I mention the screaming and jumping he made when he showed off I don't know what product?

Re:screaming monkey? (4, Interesting)

larry bagina (561269) | more than 6 years ago | (#23911015)

"Spider Monkey" is the mozilla/firefox javascript implementation. I read screaming as "kicking and screaming" -- ie, IE will get javascript 2 whether they want it or not.

Re:screaming monkey? (1)

seanonymous (964897) | more than 6 years ago | (#23911365)

It's because lots of Vodka was consumed during development. 'Screaming' is bartender 'code' for 'vodka'.

Re:screaming monkey? (0)

Anonymous Coward | more than 6 years ago | (#23911515)

The current javascript engine for Mozilla products is called "Spidermonkey."

Re:screaming monkey? (0)

Anonymous Coward | more than 6 years ago | (#23912419)

Screaming monkey boy... DEVELOPERS DEVELOPERS DEVELOPERS etc.

Be silent, caps filter

Re:screaming monkey? (0)

Anonymous Coward | more than 6 years ago | (#23912695)

Others have already mentioned SpiderMonkey [wikipedia.org] being the current Mozilla JS engine; there's also plans for ActionMonkey [mozilla.org] , being the marriage of ActionScript (i.e. Tamarin, the Adobe JS engine) with SpiderMonkey.

Oh, and IronMonkey [mozilla.org] for possibly running Iron[Python|Ruby] (i.e. CLR-ish things) with Tamarin.

It's also easier to buy screaming monkey [thinkgeek.com] mascots.

Re:screaming monkey? (1)

rrohbeck (944847) | more than 6 years ago | (#23912851)

I had to think of Steve Ballmer [youtube.com] immediately.

Re:screaming monkey? (1)

mkcmkc (197982) | more than 6 years ago | (#23912923)

Maybe it's just me, but I'm curious why he would name it "Screaming Monkey".
Use IE for a while and you'll know...

synergy with html 5 (5, Interesting)

bcrowell (177657) | more than 6 years ago | (#23910811)

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.

Re:synergy with html 5 (1)

dukoids (194954) | more than 6 years ago | (#23911209)

Fully agreed. Maybe I'd like to see a class keyword that extends the object literal syntax to allow simple prototype definition, though...

class Person {
  prettyName: function () {return firstName + " " + lastName}
}

Ok, perhaps also something like new Person() {firstName: "Bernd"})

Re:synergy with html 5 (3, Interesting)

Actually, I do RTFA (1058596) | more than 6 years ago | (#23911811)

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.

It may not by a w3c standard, but I'd rather use Flash. The vast majority of end users already have it downloaded, and it really is uniform across browsers/OSes, unlike w3c standards. At least I don't need 5 browsers and 2 boxes to test all the significant combinations.

Also, thanks to Adobe (probably the only think worth thanking them for) protecting the Flash name, Microsoft cannot do the embrace/extend/extinguish path on the name. HTML, JS, CSS, Microsoft was able to invent alternates for all these w3c standards. Even Java with J++. Not so with Flash.

So I guess my point is, I'm willing to bet on greater market penetration of Flash, then of w3c compliant browsers.

Re:synergy with html 5 (3, Informative)

mkcmkc (197982) | more than 6 years ago | (#23912965)

It may not by a w3c standard, but I'd rather use Flash. The vast majority of end users already have it downloaded, and it really is uniform across browsers/OSes, unlike w3c standards. At least I don't need 5 browsers and 2 boxes to test all the significant combinations.
Well, you don't have to test to be sure that your Flash app probably won't run correctly under Linux, or for users who care about security (and will thus disable it), or for users who've given up after be pummelled with Flash ads, or on platforms that Flash doesn't support.

Javascript sure has it's problems, but at least their is FLOSS code with which to fix them. With Flash, Adobe can pull the rug out from under you any time they like, as they did with their SVG plugin.

Re:synergy with html 5 (1)

gaspyy (514539) | more than 6 years ago | (#23913273)

Ah, you're so out of time...
Adobe has Open sourced the SWF file format, the Flex framework (for building .net-style flash apps) and donated the Tamarin (look it up) project to Mozilla. I'd say your worries are unfounded.

Also, pull the plug on flash? One of their crown jewel? The plugin present on 98% of all computers? You got to be joking. They pulled the plug on SVG because no one wanted it. At the time, Adobe tried SVG as a possible competition to Macromedia (the owners of Flash); in the end, they figured it'd be easier to buy Macromedia than sell SVG as a viable alternative...

Oh, and I know most slashdotters think flash==evil_ads, but you can build some very cool stuff with it; I am working on a chess game in AS3 [flashchess3.com] (actionscript 3) and it's very rewarding; it makes me feel like when I was 13 and was playing with my ZX Spectrum...

Re:synergy with html 5 (1)

SnT2k (842980) | more than 6 years ago | (#23912887)

With HTML5, I think it would actually be a bigger programming headache if JavaScript didn't get a makeover anytime soon if it intends to "synergize" with HTML5. I don't want a "JavaScript Framework" implemented on top of the language just to implement rudimentary OOP concepts like inheritance and namespaces. Granted, the current implementation lends itself to a different programming paradigm (which is definityle not the traditional OOP we come to love and hate) but, as I see so far, no mere mortal has yet to uncover a proper paradigm exposed by Logos... I mean... the prototype classes of JavaScript.

Moreover, I believe that having a language makeover is a good way to "re-stabilize" the browser implementations: since the script languags is already a different monster the browsers might as well re-implement their front-end and because users/programmers are now more critical on the implementations as opposed to before, there's a good chance that the browsers would "get it right".

Re:synergy with html 5 (1)

MemoryDragon (544441) | more than 6 years ago | (#23913875)

The burning need comes once you move out of the hello workd and 5 liner domain into real systems design... Sorry to say that...

HotRuby (4, Informative)

DragonWriter (970822) | more than 6 years ago | (#23910995)

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.

JS 2 in FF3.1? (3, Informative)

DragonWriter (970822) | more than 6 years ago | (#23911025)

Eich does not expect Firefox support for JavaScript 2 until at least Version 3.1 of the browser.

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 want embedded javascript (3, Interesting)

Chris_Jefferson (581445) | more than 6 years ago | (#23911037)

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?

Re:I want embedded javascript (1)

Shados (741919) | more than 6 years ago | (#23911109)

Dunno... in Windows there's a billion way to do it, from the Windows Script Host for anything able to use COM components, to CodeDom for managed (.NET) environments, and a bunch of third party solutions.

Dunno about the *nix world, however.

Re:I want embedded javascript (1)

MisterBlueSky (1213526) | more than 6 years ago | (#23911465)

You can embed SpiderMonkey (http://www.mozilla.org/js/spidermonkey/ [mozilla.org] ) in your application to allow JavaScripting. But I don't how easy or difficult that would be.

Re:I want embedded javascript (3, Interesting)

larry bagina (561269) | more than 6 years ago | (#23911635)

It's fairly trivial to embed WebScript/kjs. It's not terribly difficult to embed the mozilla/spider monkey interpreter either. It comes with a command-line javascript shell.

Re:I want embedded javascript (3, Interesting)

JebusIsLord (566856) | more than 6 years ago | (#23911663)

I've not had a lot of experience with JavaScript, but the whole concept of writing a large application in a prototype-based language seems daunting to me. Probably because I always start with an object diagram, translate that to a class diagram, and then write the classes. What sort of code diagram would you use to describe the high-level object interactions in a javascript app? How does the source code get broken up? (I tend to use 1 file per class).

Re:I want embedded javascript (3, Informative)

Chris Burkhardt (613953) | more than 6 years ago | (#23912193)

Many of these would probably suit you: List of ECMAScript Engines [wikipedia.org] .

Some helpful documentation:
How to embed SpiderMonkey in your C/C++ program [mozilla.org] (try Rhino [mozilla.org] for Java apps).

Although in my opinion Lua is so similar to JavaScript in all the right ways, and is so easily embedded, that it might be a better choice anyway.

Re:I want embedded javascript (1, Informative)

Anonymous Coward | more than 6 years ago | (#23912331)

Qt let's you do this. It comes with a Ecma-262 [trolltech.com] engine (i.e. javascript) that integrates with the rest of Qt in your code.

Re:I want embedded javascript (2, Interesting)

Hank Scorpio (137966) | more than 6 years ago | (#23912713)

I'd recommend checking out the latest version of Qt. (4.4.0 was recently released, and now even includes a WebKit widget.) As of version 4.1, I think, it includes a module called QtScript which is a full JavaScript interpreter that can integrate very easily with your C++ code. You don't have to have a GUI to use Qt -- it is split into several libraries and you can easily omit the GUI libraries, and just use QtScript, if you'd like. Plus it has an excellent API that is a real pleasure to work with. Not to mention cross platform!

Hmm, this sounds like an advertisement -- they're not paying me, I swear! I am just a very satisfied user (been using Qt for more than 5 years).

Bright future (3, Interesting)

steveha (103154) | more than 6 years ago | (#23911091)

Here's an overview of ECMAScript 4, the new version of JavaScript:

http://www.ecmascript.org/es4/spec/overview.pdf [ecmascript.org]

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 [mozilla.org]

Steve Yegge [blogspot.com] has said that he thinks he knows what the "Next Big Language" [blogspot.com] 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.

Re:Bright future (0)

Anonymous Coward | more than 6 years ago | (#23911679)

Yes, Brendan and the others explictly say they are trying to make it more like Python in their Bugzilla comments. With new features especially they try to follow Python in corner cases, etc.

Re:Bright future (1)

quanticle (843097) | more than 6 years ago | (#23912379)

I think he is talking about JavaScript, and I think he may be right.

Doubt it, and here's why. In the eleventh paragraph, he mentions this:

JavaScript had Netscape, Sun, and Microsoft (among others).

This, of course, means that JavaScript is already a big language in his eyes, therefore, it cannot be the next big language.

Re:Bright future (1)

SnT2k (842980) | more than 6 years ago | (#23912745)

Actually, with templated type parameters (i.e. generics), the 'like' keyword for type constraints (which resembles C++0x concepts), the 'nullable' data types (which resembles the use of pointers in C to an extent) and function bindings, it's starting to look a lot like C++/0x.

If I'm not mistaken, ECMAScript 4 was partially implemented by AS3/Flex (actually, ECMAScript 3 + some features of 4). I've been programming on it for quite a while and I must say that I love it. It provides a near-perfect balance of static types (helpful for auto-completions) and dynamic types (useful for things like webservice invocation).

Now if they would only provide us with operator overloading... (it would make linear algebra oriented calculations simpler). But in any case, I'm already happy enough as it is with better datatyping and traditional classes. The prototype paradigm used in previous Javascript versions doesn't lend itself too well to traditional OOP approaches.

"significant [sic] whitespace" (1)

mkcmkc (197982) | more than 6 years ago | (#23913015)

The result will be a language a lot like Python, but with code blocks wrapped in curly braces and no significant whitespace.
Python's whitespace situation is arguably no different than Javascript's. That is, you need to begin each line with whitespace that shows the indentation of the block in question. If you don't, your code is crap. Python goes a little farther and requires that your code not be crappy in this way.

Also, non-leading whitespace is not significant in Python.

P.S. (1)

mkcmkc (197982) | more than 6 years ago | (#23913239)

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...

Re:"significant [sic] whitespace" (0)

Anonymous Coward | more than 6 years ago | (#23913841)

Python's whitespace situation is arguably no different than Javascript's.

Actually, it is. In Python, you must indent a block the same; in JavaScript, you don't need to.

I take your point: everyone indents code anyway, so the curly braces are more or less wasted effort. That doesn't mean your "[sic]" was called for or even appropriate.

I'm a fan of Python and I actually like the block-by-indenting. The fact remains that there are large numbers of people who really, really don't like it. A language that is very much like Python but uses curly brace indenting may gain significant traction from those large numbers of people, so this was worth remarking upon.

Python goes a little farther and requires that your code not be crappy in this way.

That is true. It is also true that you can have a subtle error in Python, if someone edits a source file with an editor that auto-indents using tabs, and accidentally introduces a tab in the wrong place. I've been bitten by this. (There is a reason why the Python documentation says to never write code that mixes spaces and tabs.)

And please don't say something like "the guy who did that is a moron". He's not, actually.

As I said, overall I like the whitespace blocks. But I'm aware of its drawbacks as well as its advantages.

Also, non-leading whitespace is not significant in Python.

Well, thanks for pointing that out, I guess. Not that anyone had claimed otherwise.

Google Web Toolkit? (4, Interesting)

TheNarrator (200498) | more than 6 years ago | (#23911111)

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/ [gpokr.com]

Re:Google Web Toolkit? (0)

Anonymous Coward | more than 6 years ago | (#23911735)

If you want to see a neat demo of what can be done with GWT check out :

http://www.gpokr.com/ [gpokr.com]

Doesn't work in Opera 9.5

This is GWT without Opera support [shipmentoffail.com] . Epic fail.

Re:Google Web Toolkit? (1)

JakeD409 (740143) | more than 6 years ago | (#23911889)

This looks very cool. Have you used it? Do you know anyone else who has used it? I've found a bunch of descriptions of it on the web, but not a lot of "reviews" per se.

Re:Google Web Toolkit? (0)

Anonymous Coward | more than 6 years ago | (#23912063)

See my post above for a review, hint: it's an epic fail.

Re:Google Web Toolkit? (5, Informative)

AKAImBatman (238306) | more than 6 years ago | (#23912099)

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 [yahoo.com] . Also, trying READING the Javascript Client Guide [sun.com] . 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.) :-)

Standard JS Please (0)

DigitalisAkujin (846133) | more than 6 years ago | (#23911719)

I don't mind Javascript 2, that's all well and good but stock Javascript needs to be standardized across the board. It's good that IE8 is finally going to be standards compliant for rendering but they all really need to sit down and figure out how to standardize JS. The irony on this one is that MS came out with some really good extra JS features back in the day so you have these features that the IE team pioneered but then it was added as a stock feature but differently. Libraries like Prototype.js and Mootools are nice but I still want a standard JS setup.

Re:Standard JS Please (2, Informative)

bunratty (545641) | more than 6 years ago | (#23911831)

You mean like a formal standard for the language? That's ECMAScript [ecma-international.org] . Do you mean a standard way of interfacing with the browser? That would be DOM [w3.org] . Or do you mean some practical tests of scripting to ensure that different browsers behave consistently? Sounds like Acid3 [acidtests.org] .

Re:Standard JS Please (1)

moosesocks (264553) | more than 6 years ago | (#23912045)

WebKit and Firefox have their own share of proprietary functions that are supposedly intended for internal/embedded use only.

Re:Standard JS Please (1)

Achoi77 (669484) | more than 6 years ago | (#23913151)

almost all modern browsers should be compliant to ECMA-262 (3rd ed), well, at least the wikipedia entry tells me that is so [wikipedia.org]

As long as you stick to that, you should be totally fine. this [mozilla.org] 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)

ECMAScript 3.1 (2, Interesting)

MrMunkey (1039894) | more than 6 years ago | (#23912407)

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.

Re:ECMAScript 3.1 (0)

Anonymous Coward | more than 6 years ago | (#23912797)

The rational behind 3.1, as I understand it from the mailing lists, is not to prepare for other future versions by laying out a nice foundation but to push the new features of ecmascript 4 into library code. I appreciate simplicity in my languages and I love Javascript but that doesn't mean we need to limit the language to one specific technique of programming (lambdas, closures, etc) the way crockford does. Eich wants to fix those things but since we're here, why not also add in some gaps the language has been lacking, like something other than prototypal inheritance which every single javascript library abstracts away. It's useful at times and I've come to appreciate its extensibility, but that doesn't mean that sometimes I don't want to just create a class without all the manual fiddling.

For those who don't know (0)

Anonymous Coward | more than 6 years ago | (#23912741)

... I think that Brendan really pays attention. I've submitted a lot of "policy" bugs (i.e. use threads, bittorrent for the win!) to Mozilla, and he's got strong, and well supported, opinions. I've a lot of respect for him, and he tirelessly puts up with a lot of munchkins (like me) submitting technologically misfit opinions.

call for UN (1)

Max_W (812974) | more than 6 years ago | (#23913187)

Since Internet becomes the means of communication for the whole planet we should not leave the standards implementation to the decisions of some obscure marketeers and programmers.

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.

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account

Loading...