Why I don't like JavaScript 2
I don't like JavaScript 2, ECMAScript 4, or whatever it's called. That doesn't mean I'm taking sides in the ongoing controversy. To the contrary -- I think the controversy is boring and lame. I don't like JS2 because I just don't care.
Actually I'll even go beyond that. If, in say, 7 years, we are still using JavaScript or JS2 to write Ajax applications, I'll be very sad. I don't like JavaScript, as a language. I don't hate JavaScript, but I don't like it as a matter of taste. It doesn't excite me, I don't think it's particularly powerful, it doesn't change the way I think about programming, etc. JavaScript is okay, but it's not great.
So in a way I guess I should be interested in JS2. And to whatever extent JS2 is better than JS1, then the web benefits. I guess. I don't really know though, because I haven't even so much as glanced at a spec. People whose opinion I respect think it's an improvement, but like I said, I don't care. Why?
Because I think JS2 has something in common with XSLT: they're both painstakingly-crafted, elegant solutions to completely the wrong problem.
Why, exactly, are we betting the future of the web on just another programming language? If the past 40 years of computer science have taught us anything, it's that the industry never -- never -- agrees on a single programming language. ForTran, COBOL, C, Java... things change. So why does anyone think that this time around it's going to be any different?
Worse, designing a successor to JavaScript implies that you know what's best for all developers everywhere, and have the required skills to design it. That's a hell of a presumption, even granting that it's the work of a team of talented experts and not a solo thing. I really like Python; who are you to tell me that your shiny new language is better for the browser than a language with years of history?
This is the same issue I have with XSLT. The need there is for a standardized way to transform XML from one format to another -- okay, fine, that's definitely a real need. But what is XSLT, if not machine readable instructions for performing a specific task? And hey guess what -- we have lots of different things we can use to encode machine-readable instructions; we call them programming languages, and they have a rich and varied history. In the silly days of my professional youth, I once devised a system where you basically wrote little scripts in an XML syntax, and I got rightly bonked on the head for it. It's not any better an idea for XSLT, either.
That said, for what it is XSLT is pretty well done; it's just that it's a well-done solution to the wrong problem. XSLT is a tightly-coupled solution to the problem; a loose-coupled solution that focused on defining a sort of "CGI for XML transforms" would -- in my opinion -- have been a better idea. Specify the boundaries, and let existing languages do what they're good at.
It's definitely possible to nit-pick my argument there, but I'm bringing it up because I think it's even more true of JavaScript today. I'm sure that JS2 is a great, elegant language. But the problem is, it's just not what's needed.
The web works as a platform because it embodies an effective application model implemented via open standards. But it's getting long in the tooth, which is why we have at least 3 different platforms aiming to replace it: AIR, Silverlight, and JavaFX. Each of these is basically some permutation in the cartesian product of (Vector-renderer, DOM-renderer) * (custom VM, custom language). The thing is, the browser of today is itself one permutation, and JS2 boils down to yet another.
We've already proven the model, folks. We don't need to prove it all over again.
The browser isn't broken, and doesn't need to be "fixed", either by a proprietary platform, or by a shiny new language. Instead it needs to be extended, and functionality gaps need to be plugged. That's why I don't care about JS2: its fundamental message is "the Browser of Tomorrow is the Browser of Today, just with different syntax." This is spinning our wheels, and won't do anything to advance the web.
So what is the right solution? Well, in my opinion what we need is to formalize and standardize the DOM API, agree on a single vector model and API, and specify an intermediate compilation format. That is, specify the boundaries, and let existing languages do what they're good at.
That intermediate format could be bytecode like the JVM or .Net CLR, plain old JavaScript (which GWT has proven can be used for this purpose), or even "JS plus compilation-friendly extensions". Between Tamarin and SquirrelFish and ten years of the JVM, I think it's pretty well established that this is a solvable problem. For that matter, ditch the idea of an integrated VM entirely, and establish a standard API where an external process can attach to your browser DOM, without the browser needing to run code at all.
With one of these approaches, the browser -- through incremental steps -- becomes just as "innovative" as SilvAIRLaslavaFX, while still based on the open standards that have worked so well so far. This is basically the same pragmatic gap-filling philosophy that Gears and HTML5 have, though taken a step farther.
The problem is that this is messy work, and it's far less sexy than designing your own language or busting out with your own runtime out of whole cloth. It feels less innovative, because it's less of a dramatic change. But as DOM, CSS, and XMLHTTPRequest have proven repeatedly, it's the modest, targeted innovations in the web that have caused the biggest revolutions.
Bytecode, in the traditional sense, (one-byte opcodes followed by parameters), is not a win for the web. It decreases readability/debuggability, is no more (probably less) compact than minified/gzipped JS, and JS parsing is a minimal cost.
Kris Zyp said...However, I believe that in some sense, JS effectively _is_ the bytecode of the web. JS is the bytecode of GWT, Mascara, Caja, and many other projects that give programmers the option to program solely in another language. JS is a platform, not just a language. I believe that this use case is only going to continue to grow, and I agree with you that is important for continuing to give developers a choice of language. Evolving JS should be more focused on improving it's capabilities as a platform, instead ES4 has been more focused on language/programming in the large aspects like integrity.
However, there are certainly a number of features in ES4 that make it a much more capable platform as a target for the compilation of other languages (many of them coming in ES3.1), and so I think there is progress.
It's interesting that you don't like JS and don't think it's powerful.
timothy said...I've been programming in all kinds of languages for 30 years and JavaScript is my favorite language--the most exciting one for me in years and years.
Just goes to show you that yeah, people will never agree on languages.
@kris_zip Indeed, JS is a sort of de-facto bytecode, and so from that perspective my goals are met, JS2 is a no-op, and we can move on to enhance the browser in other ways like Gears or HTML.
Dan Morrill said...However from talking to the GWT team, I know there are at least a few tweaks to JS that would be helpful to GWT in its goal of writing faster code. If those could be standardized, then I think that would be a net plus.
@timothy I guess it's not that I don't think JavaScript is powerful in the absolute; it's that I don't think it's particularly powerful in the relative. For instance, I don't think JavaScript can do anything that Python couldn't do.
Dan Morrill said...It's a perfectly serviceable language, it's just not one that lights my fire. I already know which languages do, and I'd rather use those in the browser than have to learn a new one which still may or may not light my fire.
I am of a similar opinion, but I take it to the next level in this case. You are asking for a standard vector/drawing API. There are so many different native APIs just like there are so many different programming languages. And time has shown that we can't all agree on a single one. So why should the web have a single standard vector/drawing API? And why should our apps run inside the browser?!!
dn said...In my opinion, we only need a standard format to exchange data. The apps itself can be native. Why re-invent the OS in a browser? The following are two possible reasons:
If the aim is to have a write-once-run-everywhere environment, why not standardize the OS? Obviously that is not going to happen, just like we can't agree on a single programming language or drawing API. Companies make native apps for multiple platforms (with or without multi-platform toolkits). Also, web apps need to take care of multiple versions of browsers and their differences. There will always be differences.
If the aim is to be able to access your data from any computer, it still does not explain why the app has to run inside the browser. We could instead allow the browser to download native apps and run them inside a sandbox. Also, as smartphones become more popular, people will have their own "computer" (the smartphone) with them all the time and all they will need is connectivity to their data (in case all their data is not on their smartphone).
"I don't think JavaScript can do anything that Python couldn't do"
Yitz said...And, technically speaking, there's nothing Python can do you can't do in asm, or with a Turing machine. It may just take a lot more effort. Python and JavaScript have similar levels of power, though, so it's true there's not much one can do that the other can't. However, that's hardly shabby, and once you add in the fact that it's a ubiquitous platform it's incredibly compelling. I know that's kind of your gripe, but my guess would be you've never really used JavaScript. Think of it as Lisp with C syntax, perhaps.
We already have a pretty good, time tested, cross-platform, vector graphics API. It's called OpenGL. The OpenGL immediate mode renderer to be exact. We can toss in Open Scenegraph if you want a high-level non-procedural API, OpenAL for audio, and OpenCL for computation.
Ray Cromwell said...If Google Gears exposed these APIs to Javascript (like Android does with embedded GL), you could build SVG/VML/Flash/Silverlight/JavaFX in the JavaScript.
I also agree with Dan, a bytecode VM is better than Javascript, and using bytecode does not preclude debuggability nor source-reversal. This totally depends on the byte-code design, for example, an AST-based code would provide almost exact reversal.
Javascript cannot be the universal byte-code intermediate, it lacks many features that other languages would want in the VM. For example, non-double numeric types, real 32-bit integers and 64-bit longs, which are important for many applications you'd want to write in the browser.
These language wars always come down to people posing false dichotomies. Static languages are always verbose, dynamic languages are always slow, you can't debug bytecode, you can't interactively develop with static languages (e.g. no REPL), and so on.
Javascript is a powerful or interesting language, if all you've ever used was C or Java, but if you're been using other dynamic scripting languages, Self, Smalltalk, Ruby, or other statically typed languages like ML-derivatives, Haskell/Clean, Scala, etc then it's not particulary exciting. It's just another syntax for feature's you've already been using.
I think Dan is spot on. What should be standardized is the browser's native APIs: DOM, CSS, Events, I/O, graphics, audio. The actual syntax of the code that leverages these APIs is irrelevent.
Valuable comments all.
Blogtest said...Differentiation between languages is not only a factor of technology moving on, they're also a consequence of the set of problems you're interested in solving. So, you can regard that Fortran, Cobol, C list as a time-line, but I regard it as a family of different solutions to different problem-spaces, today there is still an argument that certain numerical applications are best written in Fortran because, for its age and faults, this is just the kind of engineering problem the language was designed to assist. Certain types of time-critical device driver are still better written in Assembly language. SO often a new kid on the block isn't always absolutely better than the old kids, it's just geared towards a specific trend of development problems that may not have existed before. The old problems, e.g. systems development problems, don't go away and languages for such problems are still useful.
It's too obvious to be worth a mention that the ideal language hasn't been invented, and just probably doesn't exist. The scope of the kind of instruction automated devices may be called to execute, be they web browsers, digital-watches, operating systems or robots tells not only there may never be a one-size fits all human-machine linguistic solution but that it's almost certainly best for us that there isn't, just like there is never likely to be a widely accepted costume that is equally comfortable in bed, outdoors, in rain or at a wedding.
The biggest problem we're faced with since the internet went boom is that so much hope, hype and revenue is dropped on whatever the-next-big-thing-in-IT is that everybody wants to be in on the act as it goes up. Now we're moving away from hardware based development to a more abstract software-platform / browser environment platform everybody wants to make themselves internet friendly and claim they know what the next-big-thing will be, often by trying to make oneself responsible for inventing it or at least be seen to be current-big-thing tool users because it looks flash on your resume.
Python is a truly excellent language. As are Lisp, Smalltalk, Forth and... well that's about the end of the list come to think of it ;)
Most people will tend to recommend whatever it is they themselves are doing is the current big thing, largely because that is where they themselves find comfort and enjoyment for a plethora of possible reasons, none of them being that they have found the solution that works for us all.
Personally I don't like programming. As a task, writing is pretty boring for me in any language.
PS (from blogtest)...
vapour said...I don't do it because I like it, I do it because I know how!