Rubyscript instead of javascript

Ruby
21

David M. wrote:

On Monday 07 September 2009 05:53:13 am Eleanor McHugh wrote:

On 7 Sep 2009, at 02:49, David M. 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.

We already have. It’s called ECMAScript. The only thing missing to
make it a great truly great VM is GOTO, but it actually does have
GOTO, it’s just spelled funny: E-X-C-E-P-T-I-O-N.

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),
  • JVM bytecode (meaning any JVM language, and that includes Ruby,
    Python, PHP, Scheme, … can run on ECMAScript),
  • YARV bytecode (meaning any YARV language, and that obviously
    includes Ruby can run on ECMAScript),
  • any language implementation that uses PyPy (including Python,
    Smalltalk, Prolog),
  • Clojure,
  • C,
  • Flapjax,
  • Caja,
  • Objective-J,
  • Clamato,
  • haXe and
  • links.

It seems that’s part of Microsoft’s thinking with Silverlight and the
Mono project’s Moonlight Linux/X11 implementation could make it a
credible platform.
It looks interesting, but I have several concerns:

  • Mono always seems to be several steps behind .NET.

This not a problem if you explicitly target Mono. Also, while Mono
does not implement the entirety of .NET, it does implement the
entirety of ECMA-334 aka ISO/IEC 23270 (C#) and ECMA-335 aka ISO/IEC
23271 (CLI).

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),
Compiler-as-a-Service (available in Mono for over a year, planned but
not even announced yet for .NET 5 or 6), iPhone support (Mono runs on
the iPhone just fine, .NET probably never will), 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), 64 Bit array
indices (explicitly allowed by the specification, but only implemented
by Mono with no plans by Microsoft), SIMD support (some vague comments
by Microsoft, but nothing even remotely concrete), Continuation
support (no interest from Microsoft)-

  • Microsoft has helped Mono and Moonlight, because they’re fighting Flash. If
    Flash dies, that support may simply be dropped.

Microsoft already helped Mono before they did Silverlight. And even
before Microsoft started helping them, Mono did just fine.

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?

  • 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.

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.

Tamarin sounded like a good idea, when ECMAScript 4 was still the
future, but that died, thank the heavens.

and let Adobe quietly push it into IE via
Flash. This has the advantage that everyone already has Flash, and Flash
generally stays up to date somehow or other, so it would be instant,
widespread adoption – yet the Flash would be a hack for where the standard
itself isn’t supported.

Actually, Flash is also only supported on a tiny fraction of
platforms. Indeed, I believe Mono is actually better in this regard.
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.

Also, to this day, Flash for Linux is only available for 32-Bit x86
processors (which is pretty much exactly 0% of computers sold in the
last 2 years, with the exception of netbooks), and only for a small
number of distributions and browsers (excluding, for example, Opera).

That’s a powerful platform – if that’s the direction Adobe is going. I have
no idea – a quick Google doesn’t show whether any other languages target
Flash, or could reasonably target Flash.

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.

jwm

22

On Tuesday 08 September 2009 07:04:18 am Eleanor McHugh wrote:

On 8 Sep 2009, at 10:40, Jörg W Mittag wrote:

Also, to this day, Flash for Linux is only available for 32-Bit x86
processors (which is pretty much exactly 0% of computers sold in the
last 2 years, with the exception of netbooks), and only for a small
number of distributions and browsers (excluding, for example, Opera).

I’d also like to point out that the stability of the OS X port of
Flash leaves a lot to be desired. It regularly crashes Safari on my
machines.

That’s the theory behind something like Chrome.

Of course, the stability of either Chromium or Flash isn’t great on
Linux –
but the architecture of Chrome means it’s not often I can crash more
than one
tab, and if it’s just one, just refresh.

23

This is only somewhat related, but Appcelerator Titanium
(http://www.appcelerator.com/) combines Webkit with Ruby/Python. It
doesn’t quite answer the original question, because Appcelerator apps
aren’t websites. Still, you can make apps just like a webpage with HTML5
and CSS3. Then, top it all off with Ruby, Python, and Javascript.

24

On Tuesday 08 September 2009 04:40:15 am Jörg W Mittag wrote:

  • 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.

25

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.

Not exactly true (anymore). OS X 10.6 runs majority of the system in
64 bits (including Safari) out of the box even if kernel runs in 32
bit mode by default. What’s nice that now it runs plugins
sandboxed, so plugin crashing does not bring the browser down.
On the other hand, Flash still eats a lot of CPU on OS X :frowning:

Regards,
Rimantas

26

On 9/8/09, Jörg W Mittag
<[email protected][email protected]>
wrote:

Python, PHP, Perl, Scheme, Prolog(!), … can run on ECMAScript),

  • Objective-J,
  • Clamato,
  • haXe and
  • links.

So are you saying that if someone writes a VM that has the proper
ECMAScript
hooks then you could run one of these languages without needing to
convert
into javascript or even run a VM in javascript?

Interesting.

Jeff

27

2009/9/11 Rimantas L. [email protected]:

sandboxed, so plugin crashing does not bring the browser down.
On the other hand, Flash still eats a lot of CPU Â on OS X :frowning:

Flash eats a lot of CPU time.

It might be that the runtime is inefficient or that every kiddy with
no programming skills can churn out ActionScripts by using DreamWeaver
or somesuch without any regard for the load their toys put on the
machine of anybody who happens to end up on their page.

Either way it is not platform specific problem unless you consider
flash itself as the platform.

And yes, flash supports only a tiny fraction of platforms. Macromedia
wanted tight control over the flash platform so they disallowed
writing alternate flash viewers. The result is that if you put some
chips together, compile a web browser for that platform and put it
into a case to make a set-top box you won’t have flash unless you are
Windows based, i386 LInux based or can emulate one of those. With the
additional catch that windows for non-i386 can have older player.

On the other hand, you should be able to run Java and Mono on any
platform for which you manage to build a graphical browser.
The portability of Java used to suck too but with openjdk it has much
improved lately.

Thanks

Michal.

28

2009/9/11 David M. [email protected]:

On Friday 11 September 2009 03:38:34 am Michal S. wrote:

And yes, flash supports only a tiny fraction of platforms. Macromedia
wanted tight control over the flash platform so they disallowed
writing alternate flash viewers.

I believe they’ve since changed this – so technically, Gnash is allowed to
simply read the specs.

Yes, perhaps flash support will improve too, eventually.

On the other hand, you should be able to run Java and Mono on any
platform for which you manage to build a graphical browser.

With the caveat that it has to be installed. For the platforms Flash supports
(which admittedly isn’t all of them), it’s already installed. With Java, if
it’s there, it’s probably an older version.

How did you get the impression that flash is already installed?

On Windows I do not get flash unless I install it, and I need
administrator rights for installing ActiveX components like Flash.

In Firefox on Linux I normally do not have any flash. If I do want it
I have to download some tarball and find out where to put flash plugin
(or perhaps run an installation script in terminal that might get the
place right). Automatic download of the plugin does not work on Linux.

I don’t know about flash on OS X but it’s the only platform I know of
that has the Java plugins pre-installed.

Thanks

Michal

29

On Friday 11 September 2009 12:11:51 pm Michal S. wrote:

How did you get the impression that flash is already installed?

On Windows I do not get flash unless I install it,

Last I checked, Windows came out of the box with Flash installed and
enabled,
in IE. Or, at the very least, it was included with the last IE upgrade I
did.

In Firefox on Linux I normally do not have any flash.

I’ll grant you that. However, I’m talking about Windows and OS X
supporting
this out of the box, and on Linux, well:

If I do want it
I have to download some tarball and find out where to put flash plugin
(or perhaps run an installation script in terminal that might get the
place right). Automatic download of the plugin does not work on Linux.

Depends on your distro. On Ubuntu:

sudo apt-get install flashplugin-nonfree

But I’m less concerned by that, because with the scheme I described,
Flash is
being used to support browsers which won’t support what I want natively

which is likely to be IE, mostly.

I don’t know about flash on OS X but it’s the only platform I know of
that has the Java plugins pre-installed.

Yes, it was pre-installed on OS X also, if I recall.

Keep in mind, I’m not just talking about preinstallations – I’m talking
about
actual usage statistics. For instance:

http://www.adobe.com/products/player_census/flashplayer/version_penetration.html

Granted, that’s not exactly an unbiased source, but there isn’t a market
surveyed that had less than 97% penetration by Flash 9, and I have no
reason
to doubt those numbers.

30

On Friday 11 September 2009 03:38:34 am Michal S. wrote:

And yes, flash supports only a tiny fraction of platforms. Macromedia
wanted tight control over the flash platform so they disallowed
writing alternate flash viewers.

I believe they’ve since changed this – so technically, Gnash is allowed
to
simply read the specs.

As for “fraction of platforms”:

The result is that if you put some
chips together, compile a web browser for that platform and put it
into a case to make a set-top box you won’t have flash unless you are
Windows based, i386 LInux based or can emulate one of those.

Or you talk to Adobe.

Consider the Wii, for instance. That’s a PowerPC CPU, and it’s not any
OS I
know of, yet the Wii Browser (Opera) does have Flash.

Besides which, I’m not trying to convince anyone that Flash is a good
target
– only that it is a good way to get 99% of desktop browsers to support
something that you’d otherwise do in a standard way. If I “put some
chips
together”, for instance, I’d think I could get a browser that supports
, and fallback to Flash on IE.

On the other hand, you should be able to run Java and Mono on any
platform for which you manage to build a graphical browser.

With the caveat that it has to be installed. For the platforms Flash
supports
(which admittedly isn’t all of them), it’s already installed. With Java,
if
it’s there, it’s probably an older version.