JavaScript 2: A Perl 6 disaster, that matters so much more, but wait…
I had a post in my queue relating JavaScript 2 to Perl 6. They are both in very rough spots indeed, yet JavaScript 2 has a couple of features that have me a lot more worried than I am about Perl 6:
- No offense to Perl (a language I really love, and I have code in CPAN) but JavaScript is an immensely important tool on the Web
- Unlike Perl, there are no dictator groups who can clean up. The politics are politics. If a certain someone doesn’t implement, you are in big trouble.
I have been hacking more and more on JavaScript (1.0, Brendans toy!) recently, and the more I do so, the more I like it. I worked out some years ago that it was the DOM and cross browser issues that I didn’t like, not the language.
I do wish that there was a standard library for JavaScript (Dojo does a good job). I do find myself reinventing the wheel a lot when it comes to the Object world. This week I will be in a Class.create() kinda mood. Other times I would fancy some new function() magic, and other times a bit of (function() { functions; return { ... } })(). Now I try to use the right tool for the job, but the problem is reading other peoples code.
Take a peek at the Firebug source and you will see the following at the top of each module:
FBL.ns(function() { with (FBL) {
Joe Hewitt likes with() :)
This is where it starts to feel a lot like Perl. Many ways to do one thing, and when that one thing is so core as packaging and modularization, it shows through. This is also a reason why we are in pain with components. If someone writes a great component for Dojo but you are using Prototype, you curse. What is the real difference? The darn packaging! dojo.hitch() versus function.bind(). These changes go so deep though, that it would be quicker to write from scratch.
I would love an import/include statement. Finding myself dynamically creating script elements to do a script src is starting to get a little silly. The language itself should just support that.
JavaScript 2 is helping us with packaging, but in my opinion, it used to have too much in it. Programming units, packages, namespaces, that is just too much to wrap your head around.
I am also not a fan of the optional static typing. That is fine for ActionScript, but I don’t think JavaScript needs it. This is a scripting language, something that can fit in a onclick="..." and I think the world is moving more towards the dynamic world (there is still a place for static). How about just allowing ActionScript to be written in the browser? Why try to boil the ocean with JavaScript, as Java has tried to do in the past. Work on the runtime, and allow multiple languages. This is already being done with IronMonkey and the like…. and Microsoft is doing a great job with that tactic in Silverlight. Work on an object model that can be shared, and then we can all go to town.
var self = this;
I see that too much too, even with the binders and the hitchers. The magic of var foo jumping to the top of the scope is weird too. But, all in all, JavaScript is pretty damn good! In fact, JavaScript 1.8, and what I hear about 1.9 is really nice too. I am all for cleaning up what needs to be cleaned up, and working on other stuff.
At this point in my draft I sat in the corner and cried, as I thought JS2 was in epic trouble, and that the walls were going to fall down. I didn’t know what to do. We had Brendan++ on one side, and Doug/Microsoft on the other (simplified version). I sit in between. Without some Harmony, what would happen to the Web?
Well, the reason that I can post this is because I heard that the ECMAScript meeting in Oslo was very promising indeed, and some Harmony may come out of it. Hopefully the news will get through the official process, and out in public as soon as possible, as there is new hope for us. I am sure there is still a long road, but with great people working together, we’ll get ‘er done.
August 8th, 2008 at 5:13 pm
Not sure there’s a whole lot of difference between giving JavaScript optional typing and letting people write ActionScript for the browser.
If it’s “optional,” then it looks like JavaScript when you don’t and ActionScript when you do.
August 8th, 2008 at 5:48 pm
What’s the Perl 6 disaster, Dion? C’mon, don’t be a tease!
August 12th, 2008 at 7:22 am
Static typing is not just about making JS more Java-ish, it is about performance. You give the VM extremely useful extra information and it in turns runs orders of magnitude faster. That is the case with ActionScript 3 at least. Also, static typing allows for better tools as they can provide code completion, refactoring, etc. Never underestimate the importance of improved tooling to developers.
August 12th, 2008 at 7:48 am
@Nosredna,
The point I am making is that instead of trying to make JavaScript do all things “let’s give it statis typing!”, instead make it a great dynamic language and let other languages also run on the browser platform.
Java went through this too. Instead of adding everything to Java the language, which makes it much more complicated, it is better to focus on Java the platform and having a seemless way to interop between the languages (JRuby etc etc). That is finally happening.
August 12th, 2008 at 7:50 am
@Michael,
Static typing can help with tooling. The performance issue is being disproved with the trace based JIT systems that do a phenomenal job without resorting to static typing.
There are other great statically typing languages…. let them do their thing on the browser and keep JavaScript a great, simple, dynamic language :)
Cheers,
Dion
August 12th, 2008 at 8:15 pm
Great post, until “get ‘er done.” ;)
No really, though. I agree that having many ways to do something can be a headache. I adore Ruby, but I find some methods harder to memorize b/c there’s many ways to execute them.
August 13th, 2008 at 5:44 am
Hi Dion, have you gotten to code in ActionScript 3? Once you’ve gotten a taste of hybrid typing its hard to go back. It’s really nice. You get to have dynamic typing when you want it, but then you can annotate types where it makes sense, especially when doing programing in the large. Its like the best of both worlds — its really elegant and productive. Plus, if you do it in the right places you really can get orders of magnitude performance improvements.
Best,
Brad
August 13th, 2008 at 6:54 am
Brad,
I see how it can be nice. However, I also see how verbose a lot of AS3 code gets. If the core is annotated by a lot of the peripheral code isn’t that is fine. But when I see a ton of var foo:Bar …. it looks ugly to my eyes.
And I don’t buy the performance angle. The tool angle a touch more….
August 13th, 2008 at 8:18 pm
I think harmony is a perfect compromise. It’s attainable and won’t change developers worlds too radically.
For those people who are also annoyed with including javascripts, you might take a look at JavaScriptMVC’s include: http://javascriptmvc.com/learningcenter/include/index.html. It’s been hooked up to shrinksafe so you can automatically compress your whole project without any extra work.
August 13th, 2008 at 11:57 pm
I personally think the “mythbusting” benchmarks showing tracing jits vs Tamarin with types are fundamentally flawed. It’s like comparing the very first Java JIT against later Java interpreters which were quite fast. JITing on static types would come out looking poor, and we could proudly proclaim: “Myth Busted, interpreters are not slow!”
Tamarin’s usage of the static type information for compilation purposes is most likely in its infancy. If we compare Hotspot Server from Java6 with the original Java 1.1 JITs, we’d see a huge gap.
What the benchmarks show is that the tracing JIT can approach the performance of Tamarin with types, not that it can beat any possible JS JIT that leverages static types.
Back when Self put out their paper on profile based type-feedback, there were people claiming that late bound languages could even equal or exceed C++, and then again, when Sun put out Hotspot, but it never materialized. What happened was, HotSpot got good enough for numerical work except in ultra high end cases (HPC), approaching 80% of speed of C++ on linpack, and people forgot about the hyperbolic claims.
I think what will happen is, Javascript will get “fast enough” to silence speed claims for a good swath of applications, because at this point, alot of the subjective user experience is actually dominated by DOM rendering bottlenecks. However, it will still suffer inefficiencies in numerically bound apps, power restricted cases on mobile devices, and probably won’t be John Carmack’s first choice for his next game engine. :)
(That said, lack of modules/packages makes JS painful for me, and of course, tool support is uber important)