Slashdot Mirror
ECMAScript 4.0 Is Dead
TopSpin writes "Brendan Eich, creator of the JavaScript programming language, has announced that ECMA Technical Committee 39 has abandoned the proposed ECMAScript 4.0 language specification in favor of a more limited specification dubbed 'Harmony,' or ECMAScript 3.1. A split has existed among the members of this committee, including Adobe and Microsoft, regarding the future of what most of us know as JavaScript. Adobe had been promulgating their ActionScript 3 language as the next ECMAScript 4.0 proposal. As some point out, the split that has prevented this may be the result of Microsoft's interests. What does the future hold for Mozilla's Tamarin Project, based on Adobe's open source ActionScript virtual machine?"
ECMA Script 3.11 for workgroups.
The joke works this time !
It's not dead. There will eventually be a Fourth Edition of ECMAScript, it just isn't the focus now. The ES4 proposal wasn't ever enshrined as the actual Fourth Edition either.
I was really skeptical about the concessions made by the ES4 side before I listened to some of their rationale; it wasn't so much concessions to the 3.1 side, it was that the things they were dropping didn't adequately solve the problems they were put in to solve.
There's a great talk about it here: http://openwebpodcast.com/episode-2-brendan-eich-and-arun-ranganathan-on-ecmascript-harmony
.
It is good to see the standards committee taking a breather from major new features, and instead focusing upon the alignment of behavior of functionality across the various browsers.
Hopefully, there will be a robust and rigorous compliance test suite as a deliverable of this standards process.
Why? There's consensus on Harmony.
Brendan Eich may claim it to be dead, but I'd really rather wait for Netcraft to confirm it before actually basing any decisions on this news...
*''I can't believe it's not a hyperlink.''
I invite everyone to read Douglas Crockford's latest post on the YUI blog entitled: The Only Thing We Have To Fear Is Premature Standardization
He gives some insight into how ES4 got to where it is today and its impact on standards in general
The Microsoft stuff in the summary is just trolling. Mozilla and Google are both on board with abandoning the current work called ES4.
Nerd rage is the funniest rage.
Long live ECMAscript 5.0!
Knowledge is power. Knowledge shared is power lost.
[Can I just point out] That Javascript as a development platform, as it seems to have become, is evil. It's just horrible from an efficiency, performance, security and architectural point of view. It seems to be the future.
You can point that out, but you'd be wrong. JavaScript hasn't recently "become" anything. The last major revision that all browsers supported was in November 2000.
It is a beautiful, expressive and quite powerful language that is just now starting to shine after years of being misunderstood by people like you.
Such a damn shame to let ECMAScript edition 4 go in this way.
The small shame is for Adobe's efforts, who entered the ECMA standards body to contribute, donated the entire engine to Mozilla and plenty of other efforts to get this going. But AS3/Flash will not be affected in a big way from this.
The web community as a whole will be. That's where the big shame is: for all of us, web developers. I see that packages, namespaces, classes and early binding are out, likely forever.
Classes are not "sugar", we do need those paradigms when creating bigger applications, because they are more rigid, more readable, more maintainable, understandable. I love lambdas, prototypes and all that, but that's the lower level, the implementation inside a class, inside a package. Those are not interchangable paradigms.
ES4 and AS3 have managed to add those higher constructs to the language, while maintaining full compatibility with all flexible features of ES3 (the JavaScript currently used in browsers).
The reasoning behind dropping all constructs appears to be the preconceived notion that JavaScript must exist in the form of disparate text files loosely connected to each other, something that doesn't scale to bigger efforts at all (and which makes Flash much more viable for such deployment), hence packages and early binding are out. What a mistake.
Who's to say we won't see JAR-like environment where bigger libraries can be compressed together, and some preprocessing can be done to ease the load on the client CPU/bandwidth? I've been praying we get such deployment option soon as a modern web application typically has to download a ton of CSS/JS/image files to build an average GUI nowadays. Why isn't this the focus of ECMA's efforts, but instead the focus is to maintain the status quo and reject us basics that have proven themselves in time to work well in all environments out there.
If you doubt this would work, look no further than Java/Flash applets distributed over the web in this fashion (and Flash is very widely used nowadays).
What ECMA has achieved with their decision, is to basically stagnate the browser environment, and empower third-party cross-browser plugins to eat more from the advanced web application market share, because Adobe's Flash, Microsoft's Silverlight are not even thinking of dropping their mature OOP features, just because ECMA said we don't need them.
My opinion: I need a modern virtual machine with capabilities comparable with Flash/Silverlight applets and level of integration comparable with javascript engines shipped with browsers. Compatible across browsers. Language independent (I would like to program this in Python) - maybe with some kind of intermediate representation (bytecode?). Capable to run bigger, non-trivial apps. Well designed. Open sourced and not patent encumbered.
Currently there is nothing satisfying my wishes. Pure javascript has somewhat limited capabilities (especially in multimedia area) and isn't fully compatible across browsers. Flash is proprietary and doesn't work well on some platforms and is just an applet (not well integrated with the browser itself). Silverlight is proprietary and does not work well outside windows. Java applets - along with their bad integration with browser itself and huge startup overhead - are IMO examples of bad design. Any ideas ?
Mozilla and Google are both on board with abandoning the current work called ES4.
In particular a very curious choice on Google's part, whose GWT implements Java on browsers.
The current decision is that we don't need ES4 as we don't need packages, namespaces, classes, early binding and types on a web language.
Makes you wonder how GWT happened then.
No, no ideas, but ES4 was only going to give you about 1/10 of what you want anyway, so you don't lose all that much here.
Nerd rage is the funniest rage.
It's a nice language overall, but OOP in Javascript is a real pain in the neck. I wouldn't mind a more traditional class structure.
Oh well; Microsoft scores one here, considering that Silverlight 2.0 will be scriptable using Python and Ruby out of the box.
By the way, the whole fuss about MS being behind this is pretty stupid and unfounded. MS was actually one to jump on the ES4 bandwagon early, along with Adobe - their early implementation of it was called JScript.NET, first released in 2002 with .NET Framework 1.0, and it does in fact still ship with all versions of .NET, and is an officially supported .NET language. They certainly wouldn't have any trouble extending it to the more recent spec, should it become standard. Now, I guess it will just be quietly dropped in the next version of the framework.
My impression is that packages, namespaces and classes wouldn't have worked particularly better than the current mess at the same time that they made the language that much bigger.
Nerd rage is the funniest rage.
Any ideas ?
The problem with Java and the CLR in browsers are mostly with the libraries, not the virtual machines. So, I think the thing to do would be to start with, say, the CLR and develop an open applet environment and browser integration based on it. This environment could even be emulated in Silverlight, allowing things to run without any install on Windows.
http://www.sproutcore.com/
Although JavaScript is not very good as an application language, it can do some really neat things which makes it very interesting to language nerds which is why it is so popular.
One thing is that functions are also objects which means they can be returned and taken as parameters by other functions. This is called lambda coding. Function pointers do not allow you do to quite the same thing since they can't be dynamically generated and modified. It makes certain kinds of mathematical programming very easy. For instance functions can be dynamically defined to return the derivative function of another function.
Not many languages allow you to do this. Ruby, Python and Perl, JavaScript and ActionScript all allow lambda coding, but Java, C and C++ don't probably for performance reasons since the runtime environment of the compiled program itself requires a compiler. The latest edition of C Sharp I think does though.
In any case, since JavaScript allows this it would nice just have a compiled version of JavaScript with lambda coding and classes. I think that's what they are shooting for with Harmony so I'm not really that disappointed with this decision.
>The Microsoft stuff in the summary is just trolling
That is true because MS actually voted for more security of an individual's IP rights than what ECMAScript 4.0 offered. One problem for example, under ES4, is that containers of code may also contain code that is owned by someone that never gave permission to distribute code. ES3.1 is not a solution, but it achieves that some desired advancements without a greater lack of security in a trade-off.
OOP !== Class based OOP
JS isn't a class based OOP language, it's prototype based OOP language - the two are _very_ different. I can understand why it's a pain in the neck. It's also a pain in the neck to force a square peg into a round hole, but is the blame on the person who made the square peg or on the person whom thinks that the square peg should indeed be able to be put in the round hole?
isn't that how .dlls have worked for years. Pretty much any dll can call any other one. Isn't that the basis of how things like scrip-o-licous and prototype work, allowing your pages to bind into the common javascript. Javascript is a DOCUMENT scripting language, not designed to keep the user or user agent from knowing or reusing the code.
Microsoft and Adobe are not being genuine here... the only way to implement what they want is in complied languages... like .net or Flash... gee imagine that.
I agree that JavaScript/ECMAScript is horrible, but it's what we have.
At least it's not as horrible as VBScript.
But I sure would like to have had a language with strong static typing, which in effect would have made it very similar to Java. By doing this we would have had at least some bugs straightened out before deploying to a large number of users.
The inconsistency between browsers is also a catch, but it could have been a lot worse.
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
JavaScript is popular only because it exists in almost every browser since a long time ago. This means that if you code something for a browser in JavaScript you know that it has a reasonable chance to work for the most commonly used browsers.
The use of JavaScript outside the environment of browsers is very limited, and exists only in specialized applications where it may be useful to have a script language. But then it competes with other script languages like TCL/Tk.
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
Microsoft does realize that only pure compilations are safer, but their take on the situation apropos to this topic was to invent a new language entirely and not either 3.1 or 4.0. What happened is that 4.0 become a buzzword under Web2.0 technology, and so 4.0 was design based on Web2.0 and semantics that are getting quickly outdated. In that regard, it is not like dlls.
exactly what Microsoft is doing its best work to cause. Javascript and all the tech in AJAX which allows application-like browser-neutral pages is a massive threat to Microsoft's income.
I don't know what Microsoft had to do with this but their position on any industry committee is purely to find ways to either stall the project or make sure they have ways to dilute it on Windows. They have no other reason or purpose. IMO.
LoB
"Anyone who stands out in the middle of a road looks like roadkill to me." --Linus
I haven't looked into SproutCore much, but isn't it just a framework built around JavaScript? If that's the case, how does that solve the multimedia part of the GP's request?
and this should not surprise anyone. Cross platform technologies are a threat to Windows and since over 80% of Microsofts profits come from Windows, cross platform technologies are a threat to them. So don't wonder why Microsoft keeps pushing stuff which only works on Windows or pushes for things which slow down adaption for open standards.
LoB
"Anyone who stands out in the middle of a road looks like roadkill to me." --Linus
What does the zillionth javascript framework have to do with his (legitimate) request?
Besides sproutcore looks less than impressive, even by javascript metrics. It took ages to load, yet the few available widgets feel sluggish under linux. Oh and ofcourse the layout blows up when changing font-size...
Perhaps you'd like to read my post again.
Deleted
Yes, sproutcore, because mobileMe is such a success.
Sproutcore is yet another javaScript framework.
... of how Microsoft seems to prefer to win through destruction of others rather than production of their own.
Not that we need another example. How many have we had already? Does anybody doubt?
Yes, what suckage. Who on earth wants a simple, dynamic, low-cruft language with first-class functions, closures, lambdas and a prototype object system that still manages to look like the C language family? Evil, evil, evil...
Note: I don't consider myself enough of a language expert to judge your first assertion, but your second assertion makes me strongly suspect the first. That you would claim Brendan Eich has no business being associated with language design doesn't exactly help your case.
In my case, I really didn't START to like Javascript until I began to read up on it's functional capabilities.
I think there is more to Javascript's popularity than what you say. It is actually a fairly nice little language, and hopefully when a few annoyances are cleaned up in version 2.0 it will be used outside the browser more and more. In fact, anyone who has done some serious Mozilla application programming with XUL realizes that there is no reason Javascript must be restrained to a web browser context to be useful.
i absolutely second the sentiment that what is needed is a sort of CLR (common langugae runtime) / parrot / bytecode machine implementation, on top of which languages can be implemented. that clr could be expressed in some sort of "high level assembler", on top of which language implementors can pour their syntactic icing that essentially makes bytecode accessible and readable. one could even envision some sort of "universally accepted plugins"---code that is identified by a URL, verified by secure digests, and written either in the clr or some platform-specific code according to use. popular plugins could provide services such as displaying certain image formats, playing sounds, or represent widgets, and the user wouldn't have to download them anew for each website (as is already posssible when site A references http://x/foo.png, then when site B references the same image, it may be retrieved from cache). levels of trust could be community-derived and user-configurable, so that some things that have attained a high score in terms of tested use would just load without acknowledgement, while code without that trust level would need explicit consent.
I think their primary roles would have been for basic libraries, for generated code such as SOAP bindings, and other code that ordinary web-developers would not write. They would work quite well for that and allow better robustness and possibly better performance (less dynamism -> more JIT compiler optimizations) for core functionality like parsing XML and drawing graphics.
The only way I can imagine that those features are "unsound for the Web" is that ordinary web developers would not bother to understand and use them.
Unfortunately, many of the people who write Javascript these days stubbornly identify themselves as non-programmers. They resist learning anything that smacks of a "real" programming language. There could have been an ugly struggle between people trying to force these features on web developers and web developers clinging to Javascript's current free-form dynamism. On the face of it, it might seem that web developers are just lazy to avoid learning a few new language features. It also sounds quite silly for them to say, "I'm a programming idiot; I can't write code," despite slinging around complicated DHTML, CSS, and Javascript. They're obviously intellectually capable of learning and using a "real" programming language for "real" programming.
I think their basic point is sound, though. The job of writing the Javascript for web pages often falls to the web designers, and they should be allowed to program in a simple and dynamic language that suits their artistic temperaments and lets them focus their minds on their creative specialties. They do have artistic design responsibilities that programmers do not, after all, so it doesn't make sense for them to invest as much time in learning about programming as programmers do.
less dynamism -> more JIT compiler optimizations
Not entirely true. Less dynamism means more static compiler optimisations. It can lead to more JIT optimisations, although those optimisations are often a lot more complicated. (And, yes, I do do research in dynamic language optimisation).
I am TheRaven on Soylent News
I'm waiting for Javafx. It looks pretty interesting to be honest.
Yes, sproutcore, because mobileMe is such a success.
While there were issues accessing the web interface I think those were the result of back-end problems or server overload. I don't believe the problems they experienced initially were actually inherent to the sproutcore-based webapps.
Who on earth wants a simple, dynamic, low-cruft language with first-class functions, closures, lambdas and a prototype object system
Hardly anyone, it seems. Otherwise, how do you account for the popularity of C++?
I am TheRaven on Soylent News
I understand your desires, for mine are the same. I think 90% of it would be solved if their was greater native browser support for SVG & SMIL.
Well.. maybe. Or Maybe not. But Definitely not sort of.
I think you are confusing a few things. Lambda calculus is a simple universal model of computing invented by Church. A lambda expression can reference variables explicitly inside its scope ('bound') or outside ('unbound'). By performing a beta reduction, you explicitly bind a variable in a lambda expression. This is what the lambda operation in Lisp does.
It sounds like you are confusing the fact that functions are objects, and the fact that functions are closures. The fact that they are objects lets you pass them as parameters and introspect them. The fact that they are closures allows them to reference variables in their enclosing scope even after the enclosing scope has exited.
JavaScript is a Self derivative, and Self is a Smalltalk derivative (with Lieberman prototypes instead of classes). All languages in this family have closures as first-class objects, including newer ones like Io. For Ãtoilé, I have written a Smalltalk compiler which generates code ABI-compatible with the GNU Objective-C runtime, which allows us to mix Smalltalk and Objective-C in the same project (actually, in the same object), so we get exactly this advantage from a compiled language (for various other reasons, Smalltalk is still slower than Objective-C).
I am TheRaven on Soylent News
OpenLaszlo would be much better example since you can 'export' to dhtml or flash if you want. That's theory but... sounds nice.
I have an idea. I'm working on it.
My initial idea I laid out here
Since writing that I became aware of quite a few things also exploring this area. I'm currently putting together a proof-of-concept plugin using vx32.
It should be possible to make something speedily executable on non-x86 with just a few restrictions and a bit of instruction-metadata.
Importantly. The spec is much simpler than any existing VM model so an open spec with multiple implementation methods should be quite feasible.
-- That which does not kill us has made its last mistake.
I think I get what you're saying but the difference between function having closures and functions being objects, but I just intended to point out that unlike JavaScript, Java, C, and C++ don't allow first class functions (which I refer to as lambda functions) though they do allow first class objects and function pointers though
First class functions and Lambda functions in Lamda calculus are the same thing. I also used the calculation of a derivative using a lambda function as an example which is something from mathematical calculus which may have added to the confusion.
I have to disagree; the summary isn't trolling. Looking behind the scenes it appears that Microsoft wanted to kill it so it wouldn't compete with Silverlight. (Notice how one of the things they said wouldn't be included 3.1 that was included in 4 was namespaces and packages. It was claimed that they weren't good for the web, but oddly they appear in Silverlight.)
Also, as far as Mozilla and Google being on board-this seems mostly due to the fact that Microsoft almost unilaterally killed 4 claiming they would never support it.
I'm disappointed. If you've played with AS3(based on an earlier draft of the ES4 spec) it allowed you to code in a more classical OOP fashion, but you still had access to dynamic language features that people love about JavaScript.
At this point, many, many people have attempted to graft a more traditional OOP framework on to JS(going so far as to abstract the prototype inheritance that exists with JS)-none of them have been completely satisfactory (which is why more keep coming out). The latest one of note was John Resig's which was somewhat decent.
I am tired of people saying "You can do anything with JS". While JS's dynamic nature makes the simulation of a wide variety of language features possible, it would be far better if some of these were standardized into the language itself instead of having everyone invent hacks for things that would be available in almost any other language. This does not lead to increased productivity or efficiency.
Classes are syntatic sugar. That's what the working group found, when it discovered that most class-centric features can be boiled down to simpler APIs such as .freeze(), .defineProperty(), &c., all of which are being implemented in ES3.1. Classes, then, would only be user interface to what can already be implemented using these features.
ES-Harmony is about standardizing new features that already work in (three out of four) major browsers, without changing the syntax of the language. Brendan Eich of Mozilla in the Open Web Podcast already discussed how script versioning will allows coders to use different language versions in the future. So syntax changes are not out of the question, they're simply being postponed until after ES3.1.
Until then, users will still have all the power of classes in their code, just without the ease-of-use of a "class" keyword (which will be a lot easier to implement after ES3.1 is proven and tested).
I'm tempted to disagree with you, but given your qualifications (and my lack thereof) perhaps I'd better phrase it as a question. If we're just talking about a browser language for the next five to ten years, won't static code be much faster than dynamic code for most if not all of that time? It took Sun years to make Java fast, and it seems like optimizing Javascript would require much more sophisticated techniques that would take even longer to reach users. I'd be very happy to hear I'm wrong, though, because it would make this news much less depressing.
You do realize that the HTTPRequest object which makes AJAX possible was introduced by Microsoft in the first place?
ok, so you are saying that they produced "HTTPRequest object" with the W3C? I doubt that and would figure it was probably originally tied to some Windows-only technology. Even if in the far off chance they did submit this to the W3C, I'd bet that they would take it off the market in a heartbeat if they could.
And I don't doubt they have some good developers. They, as a business, don't put solutions or customers first so that their shareholders are rewarded. They know their shareholders are rewarded only because they've got Windows in a monopoly position and keeping it there with anti-competitive tricks and methods is what they do and have done.
If the cure for cancer came out on a Mac or Linux, Microsoft would crush that and the result would be more like a Kleenex for the common cold. IMO.
LoB
"Anyone who stands out in the middle of a road looks like roadkill to me." --Linus
> What is needed in the JavaScript world is not more
> features, but more consistency of implementation
> across the various browsers.
While I agree with you about the need for greater consistency of implementation, I don't expect that will ever happen. Microsoft does not want that to happen; and will do all it can to prevent cross-platform and cross-browser adherence to agreed standards where those standards will reduce its monopoly position - even to the extent of hijacking standardisation processes.
http://www.consortiuminfo.org/standardsblog/index.php?topic=20071125145019553
http://www.consortiuminfo.org/standardsblog/index.php?topic=20051116124417686
my god, and nobody asks why slashdot, thereg and others tell us that standards are dead ? The bottom line of this story is about "kill standards, let money be innovative" with crap software. Who the hell cares about standards compliance ? Me ! I'm fed up with writing compatiblity layers ! Human being should be ashamed of its lack of ability to comply with standards ! Please, people, do believe in standards, this is the only way to go next stage. Don't listen to all these pseudo journalists trying to make you feel sad about practical and beautiful solutions. And also don't forget to look at epiphany-webkit, the only browser with 100% acid3 test !
What parts of Javascript don't work?
I don't see anything about multimedia? I don't know what needs he/she had but I guess animated SVG and video directly in the browser solves some issues.
Personally I hate flash and kind of all flash apps so..
As long as no one listen to Adobe I'm quite happy, very obvious that they want it as standard since I guess it's what flash uses, but then people would probably make more flash apps which require their plugin bullshit and well, no thanks.
Build on top of something open and make it work everywhere without being to heavy on the computer and I'll accept it.
The only aspect of a language that has anything to do with browser security is its security model. Are you trying to criticize Javascript's security model or are you just against browser scripting in general? If the former, please make a more specific case for how the security model could be improved, and if the latter, please make yourself clear, because it sounds like you have something against Javascript in particular.
Once you have first-class functions and closures you have a prototype-based object system.
Inventions have long since reached their limit, and I see no hope for further development.-- Frontinus, 1st cent. AD
Why classes? Are they inherently superior to other approaches?
http://www.dieblinkenlights.com
ECMA sounds like a bad skin disease... ... I knew this girl once, she wasn't that bad looking, you know, but man did she have ECMA all over... gave me the creeps!
You can point that out, but you'd be wrong. JavaScript hasn't recently "become" anything. The last major revision that all browsers supported was in November 2000.
Try reading the OP's post with some thought. He isn't saying that Javascript has changed, rather it has become the development platform for Web 2.0.
As for beauty, well, there's lot less ways to do method dispatching using immutable arrays than mutable hashmaps. Simplicity and transparency are closely linked with beauty as well.
he pointed out that it is a development platform for Web 2.0. There are many web development frameworks that do quite well, with only just enough javascript to support ajax and nothing more.
Having stated that, it is also true that if you want smooth cross-browser compliance, Flash with actionscript has been the only way to go for quite a while. And given that, then Microsoft might just have shot itself in the foot again, because Flash and actionscript are more consistent cross-browser than JavaScript has EVER been... and Microsoft's competitor Silverlight is -- as usual -- too little too late.
No, just as the Perl 5 model of OOP isn't inherently superior to the class-based approach (or, for that matter, just as OOP isn't inherently superior to other paradigms). They do employ different modes of thought, however, some of which could be easier to use in certain domains. The class-based method also tends to be the more familiar one, for what that's worth.
I agree but its not just its functional capabilities. It has a really nice (if limited) syntax. True, it is in many ways just a knockoff of C or C++ but that, to me, is part of its appeal. It is far less cumbersome than either and that makes it fun.
Time flies like an arrow. Fruit flies like a banana.
> My opinion: I need a modern virtual machine ==> Java ... check
> with capabilities comparable with Flash/Silverlight applets ==> Java ... check
> and level of integration comparable with javascript engines shipped with browsers. ==> Java ... check
> Compatible across browsers. ==> Java ... check
> maybe with some kind of intermediate representation (bytecode?). ==> Java ... check
> Capable to run bigger, non-trivial apps. ==> Java ... check
> Open sourced and not patent encumbered. ==> Java ... check
> Currently there is nothing satisfying my wishes.
Errrr uhmmm, ever heard of Java?
I'm not repeating myself
I'm an X window user; I'm an ex-Windows user
Yes, what suckage. Who on earth wants a simple, dynamic, low-cruft language with first-class functions, closures, lambdas and a prototype object system that still manages to look like the C language family? Evil, evil, evil...
There have been dozens of such languages around. The hard part is also making it (1) fast, and (2) correct. And JavaScript is neither.
> and level of integration comparable with javascript engines shipped with browsers. ==> Java ... check
how so?
> The web browser needs to transform into a sand-boxed window manager.
> How is that again? A window manger, huh?
Every time you add power to a scripting language, you invite abuse. Considering how well MS has *NOT* sandboxed stuff inside IE, absolutely the *LAST* thing the web wants/needs is "more powerful" web apps.
The article at http://www.theregister.co.uk/2008/08/15/webbased_clipboard_hijacking/ describes the latest Flash exploit. It appears to come in via Flash in 3rd-party banner ads. It causes Flash to rewrite the user's clipboard once a second, with a URL to a malware-laced website. The logic is that if you're doing a bunch of cut-n-paste, you may not notice that you've pasted something other than what you've intended. These malware URLs will end up being pasted into people's email messages and web postings.
This is an "equal opportunity attack". Because Schlockwave-Trash is so ubiquitous, the clipboard-hijacking is affecting all major OS's (Windows and Mac and Linux) and browsers (IE and Firefox and Safari).
The problem is that Flash is not a mere player. It's a programming environment complete with scripting language (Actionscript). This includes stuff like System.copyToClipboard() It's not a bug, it's a feature. Yet another reason to block Flash. I use the Flashblock extension for Firefox.
We should send a message loud and clear to web developers...
You may send *DATA* (including text/pictures/sound/movies etc) to my browser, but *YOU MAY NOT EXECUTE YOUR CODE ON MY MACHINE*!!! If I wanted the Russian Business Network to be able to execute their code on my machine, I'd run Windows and IE with ActiveX enabled.
I'm not repeating myself
I'm an X window user; I'm an ex-Windows user
People who complain about Javascript usually don't really understand anything about it - Activation & Variable, [[scope]], closures etc etc. They try to write a program in traditional OOP fashion and maybe they accidentally form lexical closures and see unexpected behaviour that they interpret as variable visibility issues. Or, they touch one of the many places where JS is incompatible across browsers and become confused. Then they go on some forum to explain in how many ways JS sucks. I wish they just studied the language and took the time to understand it.
I'd love to see Haxe ( http://www.haxe.org/ ) supersede Ecmascript.
{{.sig}}
Errrr uhmmm, ever heard of Java?
Have you ever heard about Haxe ?
{{.sig}}
The current approach in the Sun JVM actually discards a lot of the static information and uses techniques like type inference to get it back. One thing the Strongtalk team discovered was that run-time type inference gives more accurate results than user-specified type tagging.
There are a few things that make JavaScript slow. One is the fact that all arithmetic is double precision floating point (a VM can use integer operations, but it has to promote the results to doubles on overflow or on division which results in a remainder. Doing this causes a lot of branches (slow). The other thing is that numbers are objects, so every slot lookup needs a special case to check for this (or you need to waste some memory boxing every number.
I've recently been working on a Smalltalk compiler which uses an Objective-C runtime library to provide the object model (with the nice side-effect that you can subclass or extend Objective-C objects in Smalltalk and have no overhead from switching between the two languages). Smalltalk has a similar situation with numbers - you have unboxed SmallInts (where the number is stored in the pointer) and everything else is boxed.
The thing that makes something like Java slower than something like C++ is that C++ resolves the destination of method calls at load time (which is why C++ applications take so very long to start), while Java does it at the time of the call. For short-lived scripts, it might actually be better (in terms of user-perceived speed) not to have the initial delay. There are techniques for improving performance of this, such as polymorphic inline caching (another thing from the Self team). I implemented this in a new Objective-C runtime library designed to be able to support JavaScript and Io as well as ObjC and Smalltalk, and in some little benchmarks got Objective-C messages sends a fraction faster than C++ method calls (still about half the speed of C function calls, but you can combine it with speculative inlining safely now, which means you can inline what C++ calls virtual methods, which you can't in C++ without a fairly radical redesign of the ABI).
I am TheRaven on Soylent News
Maybe Parrot would fit your wishes? Once it is finished.
Original post says
That is wrong, ES3.1 is the smaller increment and repair of the current third standard, and "Harmony" is new features beyond that. Doug Crockford, who seemed opposed to much of ES4, wrote:
Some of the features that were in ES4 were reasonable, so a new project, called Harmony, is starting which will look at adapting the best of ES4 on top of ES3.1.
TopSpin's summary is pretty crappy!
=S
ecmascript schmecmascript already! There's be no fun in web development if you didn't have to try and hack around subtly different incompatible implementations of more-or-less thae same goddam thing.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
There are a great deal of bugs remaining in mobileMe's web interface.
For instance:
Open mail in a Safari window, then open mail in another Safari window. When you switch back to the first window, you'll get an error message: The requested action cannot be completed because this folder has been moved or deleted
Now open iWeb, upload a website to mobileMe, then try to delete it with the web interface. You can't. But notice how, even though the delete button is ghosted out, you can use the keyboard shortcut to access the delete dialog - which doesn't work.
I have a lot more of these, should I keep going?
These may not be the fault of the framework, but it doesn't do it any favors.
Anyway, offering a JavaScript framework as a suggestion for a replacement for JavaScript kinda misses the point.
Interesting, thanks for the info. I have a MobileMe account though I rarely use the web interface. I was unaware of these issues.