Besides: I can't think of language-neutral bytecode projects that ever worked. Remember Parrot?
I suspect that minifier arguments are no-win situations: either someone doesn't like that they can't easily read the JavaScript, or someone complains it takes too long to load the scripts for a given page.
If the writer wants you to see the source, you can download it elsewere (githun, etc) if not, there is no difference between not getting the source to office 98 and not getting the source to google docs.
When the Web was young and there was no GitHub, viewing a page's source made it so that you could see by example how every page worked. It exposed you to a huge number of possibilities. The Web partially owes its success to this feature because without it far fewer people would have made it to the stage where they could produce their own pages. Every web developer/designer has used this to help them -- guaranteed.
Besides, the feature would have sprung up anyway whether the browser vendors wanted it included or not. Third parties would have stepped in. It's plain text transmitted over the wire. Unlike the source of Office 98 which is not retrievable from the Office 98 binary, a page's source is readily available to the machine that has to cobble it all together when viewing that page.
In my book, some kind of byte code or other intermediate language is a lot better idea than distributing the source code of web apps. There are a lot of disadvantages to delivering programs (for immediate execution) as source code. Note: this is orthogonal to open source and licensing.
So what would be needed is an intermediate program representation that:
- Is well defined
- Is a good compilation target from various source languages
- Is easy to validate for correctness and security
- Is fast to interpret and compile
- Distributed in fast to read binary format
- Suits a dynamic language
The web has quite a long legacy of Javascript and a tradition of supporting deprecated browsers so this kind of revolution is unlikely to happen any time soon.
> Besides: I can't think of language-neutral bytecode projects that ever worked. Remember Parrot?
JVM, CLR and LLVM are all popular compilation targets that are used with dozens of different source languages each. Bytecode and program representation was never the hard part, it's the frameworks of the OS/platform underneath.
> Bytecode and program representation was never the hard part
Bytecode is very much a hard part if you're trying to support more than a single language, many bytecode have both language and VM semantics leaking in, which essentially makes them even less useful than cross-language compilation.
Most of LLVM IR is portable, but naturally there are target-specific parts. If LLVM IR was to be used in the web, these target specific parts would be defined for the "web" target. LLVM IR is used in a similar manner in NaCl and OpenCL where it is used as a portable binary format.
> Bytecode is very much a hard part if you're trying to support more than a single language
It's not easy but it's mostly a solved problem. JVM was designed with a single language in mind, yet it's used by dozens of languages today. Similarly LLVM and CLR are widely used.
How is this statement qualitatively different from "JavaScript was designed with human writers in mind, yet it's used by dozens of languages today"?
That the web is by default open presents the social dynamics that are quite different than in systems like java applets, which are by default closed.
Open source can exist regardless of whether the web is open or not, but you are kidding yourself if you think whether or not source is distributed with a web page doesn't effect the open source landscape.
Instead, JavaScript is used as a program representation with small size and immediate execution in mind, and it really sucks in that role.
Even if the code is distributed in source code form with white space, identifier names and comments intact (bandwidth isn't cheap, you know), licensing is still the factor that legally determines if it is free software or just open source by default.
View source is important both for the sake of debugging in the case of 3rd party javascript, and also for the sake of being able to teach others.
Regardless of the minification issue, it's possible to use a code formatter to expand a minified file and at least identify where declarations are being made and what functional behavior is being specified. Minification makes viewing source inconvenient, but that's not equivalent with closed.
If you go to that length you can just as well use a decompiler, no difference.
Minified files, more often than not, have the original identifiers, original code structure (e.g. you know a for from a while ). With a decompiler, you lose all of that.
Google closure is a compiler (and thus loses a lot of this data), but most minifiers are not semantically destructive.
Because javascript has some reflection, and also because of weird scoping rules (with, eval, etc.) you can never be sure where a symbol comes from unless you have access to the exact version of every other script on the page, e.g. jquery, etc)
> If you want your source-code available for download then... put up a download link.
I agree - but there is still a huge difference between deminified and decompiled source readbility - which is all I was saying.
Since we have to have legacy support for javascript approximately forever anyway, I'd say the best way forward is to embed a vm from the statically typed world as a target for static languages and leave js as a cross compilation target for dynamic languages.
To avoid nasty cross vm memory leaks you'd probably want to limit interoperability -- at least at first.
It's also nigh-impossible to design a bytecode which does not significantly restrict (and dictate) the semantics of the VM running it. It mandates a bytecode-based VM, to start with (V8 does not use bytecode).
Really? Remember the CLR and JVM?
But, microbenchmarks, blah blah blah.
Now, besides off context, your comment is wrong in four ways:
1) we are not discussing about a bytecode to implement Javascript, but a bytecode to use in browsers for implementing all sorts of languages.
2) There are other lnguages that have been implemented in CLR/JVM that are faster than Javascript.
3) V8 has been optimized by a special team, for millions of dollars, with speed as the #1 target. When that amount of money and effort, a JS running on JVM/CLR can be fast too.
4) A bytecode does not preclude a JIT. In fact it would be trivial to have V8 run a bytecode instead of raw js, just as Python runs pyc.
It just isn't standardized, or made available to website authors directly (there would likely need to be significant extra security audits before you could contemplate something like that...).
Same with Java. JVM had (and AFAIK still has) a horrible cold startup time which locked the entire browser up, causing the user to curse profanely.
* You have to know what platform you're targeting (ARM vs. x86), which eliminates the browser/JS advantage of architecture abstraction
* You have to recompile specifically for NaCl, which removes any potential benefit on binary reuse
As others have noted, NaCl is closer to ActiveX-reborn than it is to a generic web runtime architecture.