Here is just a small excerpt of the languages that target ECMAScript:
* CIL bytecode (meaning any CLI language, and that includes Ruby,
Python, PHP, Perl, Scheme, Prolog(!), ... can run on ECMAScript),
This can actually work reasonably well -- as I understand it, the IronRuby =
and=20
IronPython compilers/interpreters live entirely inside the VM.
* JVM bytecode (meaning any JVM language, and that includes Ruby,
Python, PHP, Scheme, ... can run on ECMAScript),
Same here.
* YARV bytecode (meaning any YARV language, and that *obviously*
includes Ruby can run on ECMAScript),
This is problematic. MRI, at least, has tons of stuff written in C -- much =
of=20
which really doesn't need to be. This includes the Ruby parser itself --=20
meaning anything involving 'eval' will be broken on YARV-on-ECMAScript.
And then, it still raises the question of, is this the best we can do? I=20
suppose it is nice, compatibility-wise, and if we adopt a standard, maybe=20
browsers can accelerate it later...
I know I always dream of the day when Browsers start shipping large parts o=
f=20
jQuery, re-implemented as native code, with the change transparent to autho=
rs.
This not a problem if you explicitly target Mono.
It is a problem if all the docs, tools, etc, are for .NET.
It's also not entirely true: in several areas, .NET is several steps
behind Mono: modularity (developing the CoreCLR for Silverlight was a
major effort, while Mono was modular from day one),
That's not really visible to me as a developer.
iPhone support (Mono runs on
the iPhone just fine, .NET probably never will),
That's pretty much like Mono on Linux. Mono definitely has them beaten in=20
portability.
static native
compilation (Mono can compile a .NET application together with the
Mono runtime into a single static native executable, .NET always needs
the .NET runtime installed, even if you use NGen),
I'm really not sure why this helps. If I'm targeting Windows, most recent=20
Windows installations have .NET. If I'm targeting Linux, I can build a pack=
age=20
that depends on Mono.
I mean, it's cool to know it exists, but I'd be more interested in actual=20
ahead-of-time compilation as a performance boost.
64 Bit array
indices (explicitly allowed by the specification, but only implemented
by Mono with no plans by Microsoft),
I honestly can't remember ever having a flat array with more than four bill=
ion=20
elements. Cool, but it seems kind of like this:
http://xkcd.com/619/
SIMD support (some vague comments
by Microsoft, but nothing even remotely concrete), Continuation
support (no interest from Microsoft)-
These look interesting.
Of course, the major problem is that we've again got the market pretty much=
=20
dominated by Microsoft. If I want to write a portable app, I have to target=
=20
Mono, and then I have to remove these features and make it work on .NET.
Oh, and Silverlight has already failed. The next version of Office
will be web-based, but it uses only HTML, CSS and ECMAScript. If you
can build MS Office, Google Wave and Sun Research's Lively Kernel
without any plugins, then what the heck *would* you need Silverlight
for?
Developing said applications in a language other than ECMAScript (or=20
JavaScript, for the non-pedantic), and having it perform better (not worse)=
=20
than ECMAScript? Oh, and not having to deal with the DOM would be a plus.
Those are the reasons it looks attractive to me, anyway.
Of course, I entirely agree with you. The one web app I built that needed=20
plugins, the choice was forced by management (and Facebook, and MySpace). I=
=20
made a case for the audio tag, and lost.
The ECMA specifications are covered by the Microsoft Specification
Promise. Of course, that doesn't cover the parts not part of the ECMA
specifications, which includes Silverlight.
Right...
I'm also going to want to go back and have a lawyer read that Promise. Mayb=
e=20
I'm being paranoid...
This was the original goal for replacing SpiderMonkey. However, as it
turned out, Tamarin is heavily biased towards statically typed
languages like ActionScript, which is why Mozilla and Adobe decided to
drop Tamarin, only extract the tracing JIT and duct-tape that onto
SpiderMonkey, producing the current Mozilla ECMAScript engine,
TraceMonkey.
Interesting. I never knew that.
It does make me wonder whether the two would merge at some point, though. A=
nd=20
I still very much like the idea of piggybacking on Flash, rather than=20
Silverlight, to support browsers that don't natively have some feature I wa=
nt=20
=2D- at least, to the extent that I can't hack it with JavaScript alone.
Actually, Flash is also only supported on a tiny fraction of
platforms. Indeed, I believe Mono is actually better in this regard.
Citation needed, and it also misses the point. Flash IS INSTALLED on the=20
platforms it supports. The exception might be Linux, at least until said Li=
nux=20
user wants to watch The Daily Show.
For example, Flash 9 was released in 2006, but in 2007, the most
recent version of Flash for Linux was still Flash 7 (released 2003!),
which did not support ActionScript 3 nor Flex.
That's flipped completely, in that:
Also, to this day, Flash for Linux is only available for 32-Bit x86
processors
Wrong. Flash in general has only been 32-bit. It's just that Linux is the o=
nly=20
64-bit capable OS on which the majority of the system is 64-bit out of the=
=20
box, including the browser.
And, there is currently an alpha Flash 10 64-bit for Linux -- before Flash =
has=20
supported 64-bit on any other platform.
Also wrong in that it has nothing to do with the processor itself, and=20
everything to do with the OS. Nothing's stopping you from running a 32-bit=
=20
Linux on 64-bit hardware. Most people run 32-bit Windows on that hardware,=
=20
anyway.
only for a small
number of distributions
I downloaded a file that looked pretty distribution-agnostic -- I think it =
was=20
either a tarball or a binary. Indeed, once unpacked, the only critical file=
was=20
one little .so to be put wherever your browser looks for plugins.
and browsers (excluding, for example, Opera).
It uses the Netscape plugin API, which has been around forever, and which e=
ven=20
Konqueror wraps. If Opera doesn't support it, I kind of feel like that's=20
Opera's fault, or the fault of the community at large for not coming up wit=
h a=20
better standard for plugins.
Here is just a small excerpt of the languages that target Flash:
* YARV bytecode (meaning any YARV language, and that *obviously*
includes Ruby),
* C and
* haXe.
And, if we include Adobe Air, ECMAScript.
That was the other thing that got me excited -- since Air wraps a Webkit=20
browser, and since Adobe has made Air installation so easy, wouldn't it be=
=20
cool if I could deliver a shim for IE that simply loaded my shiny HTML5 app=
in=20
Webkit in Flash?
Unfortunately, Air seems to be mostly about downloadable apps (widgets?), n=
ot=20
so much embedding in webpages.
