David Masover wrote:
>>> At the end of the day, I suppose it's a matter of taste, and we'd
>>> probably all be much better off with a common VM in the browser
>>> (something like Java or Flash, but more closely tied to the DOM,
>>> and standard), so that no one is forced into one language or
>>> another.
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
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
which really doesn't need to be. This includes the Ruby parser itself --
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
suppose it is nice, compatibility-wise, and if we adopt a standard, maybe
browsers can accelerate it later...
I know I always dream of the day when Browsers start shipping large parts of
jQuery, re-implemented as native code, with the change transparent to authors.
> - Mono always seems to be several steps behind .NET.
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
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
Windows installations have .NET. If I'm targeting Linux, I can build a package
that depends on Mono.
I mean, it's cool to know it exists, but I'd be more interested in actual
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 billion
elements. Cool, but it seems kind of like this:
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
dominated by Microsoft. If I want to write a portable app, I have to target
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
JavaScript, for the non-pedantic), and having it perform better (not worse)
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
plugins, the choice was forced by management (and Facebook, and MySpace). I
made a case for the audio tag, and lost.
> - Software patents?
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. Maybe
I'm being paranoid...
> What I've heard suggested instead is to take Adobe's Tamarin engine,
> merge it into open browsers like Firefox,
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. And
I still very much like the idea of piggybacking on Flash, rather than
Silverlight, to support browsers that don't natively have some feature I want
-- 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
platforms it supports. The exception might be Linux, at least until said Linux
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 only
64-bit capable OS on which the majority of the system is 64-bit out of the
box, including the browser.
And, there is currently an alpha Flash 10 64-bit for Linux -- before Flash has
supported 64-bit on any other platform.
Also wrong in that it has nothing to do with the processor itself, and
everything to do with the OS. Nothing's stopping you from running a 32-bit
Linux on 64-bit hardware. Most people run 32-bit Windows on that hardware,
anyway.
only for a small
number of distributions
I downloaded a file that looked pretty distribution-agnostic -- I think it was
either a tarball or a binary. Indeed, once unpacked, the only critical file was
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 even
Konqueror wraps. If Opera doesn't support it, I kind of feel like that's
Opera's fault, or the fault of the community at large for not coming up with a
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
browser, and since Adobe has made Air installation so easy, wouldn't it be
cool if I could deliver a shim for IE that simply loaded my shiny HTML5 app in
Webkit in Flash?
Unfortunately, Air seems to be mostly about downloadable apps (widgets?), not
so much embedding in webpages.
···
On Tuesday 08 September 2009 04:40:15 am Jörg W Mittag wrote:
> On Monday 07 September 2009 05:53:13 am Eleanor McHugh wrote:
>> On 7 Sep 2009, at 02:49, David Masover wrote:
