Forum: Ruby rubynuby - client side Ruby?

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
Jeff P. (Guest)
on 2006-02-22 05:44
I would like to be able to do client-side scripting things that in the
past have been done with javascript embedded in html pages...with Ruby
instead of javascript.

With so many different projects going on in Ruby these days I'm
wondering if this is already in existence and I just haven't happened
upon an explanation of how to do it, or if there is a project underway,
or if there is expected to be a Ruby interpreter built in to some soon
to be available versions of the mainstream browsers?

Is there anything existing or about to pop along these lines?

thanks,
jp
Tony M. (Guest)
on 2006-02-22 06:31
(Received via mailing list)
Hi,

Unless you are planning on developing for an intranet where you'd
have COMPLETE control over the clients' configuration, I very much
doubt that it would be a good idea to use Ruby instead of Javascript.

I am also not quite sure there are browsers out there which implement
Ruby as a scripting language, or if it's even possible to write an
extension for  Mozilla/Netscape that adds Ruby support to the client
(but I might be wrong).

I googled about it a little while ago, and didn't find it!

Merc.
Hristo D. (Guest)
on 2006-02-22 07:47
(Received via mailing list)
Hi Jeff,

On 2/22/06, Jeff P. <removed_email_address@domain.invalid> wrote:
>
> I would like to be able to do client-side scripting things that in the
> past have been done with javascript embedded in html pages...with Ruby
> instead of javascript.



I agree with James and Tony that you would be better off doing the
client-side scripting in JavaScript.  ActiveScript Ruby will make that
bond
with Internet Explorer unbreakable.  Anyway, I've tried it and it worked
fine for my simple tests (getElementById, set value, etc).

You might want to check out the prototype.js library.  It's Ruby
friendly,
and its Enumerable module that mixes in collection methods like each,
collect, grep, inject into the Array prototype is really cool.

Hristo D.
Hristo D. (Guest)
on 2006-02-22 07:47
(Received via mailing list)
On 2/22/06, Hristo D. <removed_email_address@domain.invalid> wrote:


You might want to check out the prototype.js library.  It's Ruby
friendly,
> and its Enumerable module that mixes in collection methods like each,
> collect, grep, inject into the Array prototype is really cool.
>


Forgot the link:
http://prototype.conio.net/

Hristo D.
Gregory S. (Guest)
on 2006-02-22 15:09
(Received via mailing list)
On Wed, Feb 22, 2006 at 12:45:09PM +0900, Jeff P. wrote:
} I would like to be able to do client-side scripting things that in the
} past have been done with javascript embedded in html pages...with Ruby
} instead of javascript.
[...]

Is there a FAQ list out there somewhere? This is the second time this
has
come up within a week or two. I'd like to be able to respond to
questions
like this with an URL (including an anchor to the specific
question/answer).

Also, I want to mention that JavaScript is a rather nice language. Its
primary failings are:

1) Minor implementation inconsistencies between browsers
2) Major API inconsistencies between browsers
3) Inconveniently missing facility for method callbacks (which can be
   overcome with a really simple function)

JavaScript has many of the same language features Ruby has, including
extension by mixin, duck typing, a YAML equivalent (JSON), arbitrary
class
and object extension (i.e. adding methods/properties to classes or
specific
objects at any time), simple arrays and hashes, etc. It also has
first-class functions, which are equivalent (though not identical) to
blocks.

While it does require one to shift syntax when working on both the
client
side and the server side, I see little problem with JavaScript and
little
reason to even want to replace it with Ruby on the client. At the same
time, I have no great desire to use JavaScript on the server side,
either,
since Ruby/Rails (and other web frameworks in other languages) are at
least
as good for the purpose.

} thanks,
} jp
--Greg
Jeff P. (Guest)
on 2006-02-22 23:06
Gregory S. wrote:
> Also, I want to mention that JavaScript is a rather nice language. Its
> primary failings are:
>
> 1) Minor implementation inconsistencies between browsers
> 2) Major API inconsistencies between browsers

Greg,
These two reasons are why I choose to hate javascript.  The reason for
the question though is that in this new era of "that's so ten minutes
ago", this old dog is starting to feel like a jack of all trades, but
master of none.  I long for a day when the tools settle down a bit and I
can learn just one syntax (Ruby looks like a good candidate) really well
and do lots of  neat stuff with it.

My interest in Ruby started when a colegue of mine started sending me
snippets of Ruby to explain an idea for implementing something at work
(which would, of course, have to be converted into quasi object oriented
C and then tested with a perl test framework).  That was mildly
entertaining, but now he's sending me stuff in Haskel!  That stuff will
eat your brain in a hurry.

The way things are going though, I'll have to deal with "Ruby++" long
before I ever feel that I've mastered Ruby.  Guess it's a sign of
getting old, but I'm getting sick and tired of learning new languages
every time I turn around.  One partial solution would be to be able to
do many different types of things with the same syntax.  Ruby is part of
the way there, with ways to do many server side things in Ruby, and also
ways to do real application programming in Ruby.  I just think it would
be cool if it went one more step to a seamless implementation of client
side embedded Ruby.

thanks,
jp
David V. (Guest)
on 2006-02-23 03:53
(Received via mailing list)
DÅ?a Streda 22 Február 2006 22:06 Jeff P. napísal:
> Gregory S. wrote:
> > Also, I want to mention that JavaScript is a rather nice language. Its
> > primary failings are:
> >
> > 1) Minor implementation inconsistencies between browsers
> > 2) Major API inconsistencies between browsers
>
> (snip)
>

Just plugging Ruby into browsers wouldn't really solve the API problems.
A
bonus of Javascript in this is that it has standards to support it, both
language ones, and the W3C document API ones. If there are
inconsistencies,
at least there's authoritative points of reference to support these.

Also, you can't possibly plain plug in the existing Ruby into browsers
across
the board. Unfortunately there is no standard governing client-side
scripting
in general, so if nothing else, making the required plugins would take a
while. Also, the interpreter would have to go through some trimming to
ensure
sandboxing. Bits of the standard library would have to go away due to
them
being unnecessary or unsuited for browser scripting (Tk, readline?).
Then,
not all browsers were created equal, so there'd be further trimming of
both
the language and libraries to cater for mobile devices and the like. And
sooner or later, Microsoft would decide to "improve" things and bundle
IE
with "Ruby Blunt: Whizbang Edition", and the list of things goes on and
on.

The bottom line is, you'd very probably end up with something that is at
best
similar to Ruby on webbrowsers, and the story of Javascript would at
least
partially repeat itself. Switching languages is not the solution for
problems
with browser scripting, and I'd dare say it's not even -a- solution for
those
problems. And right now, Javascript works, for given values of works
(blessed
be all you who don't deploy to proprietary set-top-box browsers).

That said, it's not an unworthy goal, but there's quite a lot to do
before
it's actually good for anything serious, like letting Ruby loose on the
unsuspecting web, with early-adoption problems aplenty on the road.

David V.
Bill K. (Guest)
on 2006-02-23 04:41
(Received via mailing list)
From: "David V." <removed_email_address@domain.invalid>
>
> That said, it's not an unworthy goal, but there's quite a lot to do before
> it's actually good for anything serious, like letting Ruby loose on the
> unsuspecting web, with early-adoption problems aplenty on the road.

Hmm... JRuby as an applet?  ;)


Ah, apparently it's been tried...
http://datavision.sourceforge.net/DataVision/embed.html says,

    Since JRuby uses a custom class loader, you will have to either sign
the applet
    or edit the client's java.policy file and add the line:
        permission java.lang.RuntimePermission "getClassLoader";


Regards,

Bill
Ramon L. (Guest)
on 2006-02-23 04:50
(Received via mailing list)
> getting old, but I'm getting sick and tired of learning new languages
> every time I turn around.  One partial solution would be to be able to

Then learn Smalltalk and be done with it.
James B. (Guest)
on 2006-02-23 06:21
(Received via mailing list)
Ramon L. wrote:
>> getting old, but I'm getting sick and tired of learning new languages
>> every time I turn around.  One partial solution would be to be able to
>
>
> Then learn Smalltalk and be done with it.

Yeah, but then he'll get antsy again, and someone will tell him to learn
Lisp.



--
James B.

"Programs must be written for people to read, and only incidentally
  for machines to execute."
   - H. Abelson and G. Sussman
   (in "The Structure and Interpretation of Computer Programs)
Charles O Nutter (Guest)
on 2006-03-03 07:56
(Received via mailing list)
FYI, this is more a limitation of the Bean Scripting Framework than of
JRuby itself. JRuby currently has no hard dependencies on
security-risky features like custom classloaders, and a version of
JRuby could be built--sans BSF--that would run just fine as an applet.
Bill K. (Guest)
on 2006-03-03 10:12
(Received via mailing list)
From: "Charles O Nutter" <removed_email_address@domain.invalid>
>
> >     Since JRuby uses a custom class loader, you will have to either sign
> >     the applet or edit the client's java.policy file and add the line:
> >         permission java.lang.RuntimePermission "getClassLoader";
>
> FYI, this is more a limitation of the Bean Scripting Framework than of
> JRuby itself. JRuby currently has no hard dependencies on
> security-risky features like custom classloaders, and a version of
> JRuby could be built--sans BSF--that would run just fine as an applet.

Cool, nice to know!

I'd really like to try this.  My java's a bit rusty... I've
downloaded the latest JDK and verified I can build JRuby from
source.  I grepped for BSF and:

src/org/jruby/javasupport/bsf/JRubyEngine.java:import
org.apache.bsf.BSFDeclaredBean;
src/org/jruby/javasupport/bsf/JRubyEngine.java:import
org.apache.bsf.BSFException;
src/org/jruby/javasupport/bsf/JRubyEngine.java:import
org.apache.bsf.BSFManager;
src/org/jruby/javasupport/bsf/JRubyEngine.java:import
org.apache.bsf.util.BSFEngineImpl;
src/org/jruby/javasupport/bsf/JRubyEngine.java:import
org.apache.bsf.util.BSFFunctions;
// . . .

It looked like it was mostly confined to that JRubyEngine.java
file, although I'm a little lost looking at the source, as I
don't know what the purpose of a BSF is yet.  :)

But before I delve into it, I was wondering, would you say it
should be fairly easy to remove the BSF dependency?  Or am I
looking at a lot of hacking and slashing?

Also, if JRuby is running as an applet, the ruby standard library
files and my own program scripts will reside on the server, not
the client's system.  Is this something that will somehow be
fairly transparent to the applet?  Or will I be looking at hacking
in the ability for JRuby to read .rb files from the server?


Thanks for your thoughts,

Regards,

Bill
Thomas E Enebo (Guest)
on 2006-03-03 17:33
(Received via mailing list)
On Fri, 03 Mar 2006, Bill K. defenestrated me:

>
> Cool, nice to know!
>
> It looked like it was mostly confined to that JRubyEngine.java
> file, although I'm a little lost looking at the source, as I
> don't know what the purpose of a BSF is yet.  :)

  A more detailed explanation of BSF is at jakarta.apache.org/bsf.  We
generally encourage anyone embedding JRuby (Ruby) into a Java
application
to use BSF, since it takes care of setting up and managing the
interpreter
with a fairly simple API.

  For some context of use of BSF with JRuby check out our lithe example
doc:
http://jruby.sourceforge.net/docs/bsf.shtml

  To embed JRuby in an applet without using BSF basically would be
grokking
our JRubyEngine to understand under the covers how we set up, invoke,
and
tear down the interpreter.  We have the desire to make this easy to do
without requiring BSF, but have not found the time to make it happen
yet.

> But before I delve into it, I was wondering, would you say it
> should be fairly easy to remove the BSF dependency?  Or am I
> looking at a lot of hacking and slashing?

  The impl of JRubyEngine we have shows the amount of code you need.
If you understand the url above on BSF usage and understand this manager
impl, you should get a good idea.

> Also, if JRuby is running as an applet, the ruby standard library
> files and my own program scripts will reside on the server, not
> the client's system.  Is this something that will somehow be
> fairly transparent to the applet?  Or will I be looking at hacking
> in the ability for JRuby to read .rb files from the server?

  I have some ideas on this that I have not added yet to the source.  We
want to extend the include path to give the ability to provide url
paths.
We need to do this in a safe way, but I have given it at least some
thought.
Any continued discussion on this may be better served on
removed_email_address@domain.invalid.

-Tom
Charles O Nutter (Guest)
on 2006-03-03 17:39
(Received via mailing list)
Well as long as you're giving this a try, I'll see if I can help.

First off, removing BSF from JRuby should be very easy; we have no
dependency on BSF ourselves, and the JRubyEngine class is probably the
only piece of code you would have to remove or disable. Removing that
and any other references  to BSF should not break JRuby (if they do,
I'll personally fix it).

Second, in order for the standard Ruby libraries to be available, the
simplest way would be including them in the JRuby jar file. This would
allow the JRuby and all the libraries to run locally in the browser,
effectively providing a full Ruby environment within an applet. Of
course, this would increase the size of the jar.

If you were intent on running JRuby as an applet with Ruby's .rb
libraries on the server, this would still be possible...but it would
require some work.

JRuby does support (in some capacity) the ability to use a URL as part
of your load path; in other words, you can do the equivalent of
-Ihttp://somewhere.com/rubyfiles and JRuby should be able to use that
location for loading "require"s. However, this is a fairly new
capability, and I can't guarantee it's working 100%. I think it's
pretty cool, though, and I'd be willing to help make it work if you're
interested in trying it.

I'd recommend you pop over to the jruby-user or jruby-devel lists on
jruby.sf.net. We're pretty responsive these days and a JRuby applet
would be cool to have working for our JavaOne presentation.
James B. (Guest)
on 2006-05-03 21:11
(Received via mailing list)
Tony M. wrote:
>
> I googled about it a little while ago, and didn't find it!

I believe you can use ActiveScript Ruby for this, but it requires that
the client use IE and have ActiveScript Ruby installed.

You are likely better off using modern JavaScript (e.g. DHTML) to
interact with Ruby business logic running on a Web server.


--
James B.

http://www.ruby-doc.org       - Ruby Help & Documentation
http://www.artima.com/rubycs/ - The Journal By & For Rubyists
http://www.rubystuff.com      - The Ruby Store for Ruby Stuff
http://www.jamesbritt.com     - Playing with Better Toys
http://www.30secondrule.com   - Building Better Tools
Tony M. (Guest)
on 2006-08-03 15:44
(Received via mailing list)
Hi,

> I believe you can use ActiveScript Ruby for this, but it requires
> that the client use IE and have ActiveScript Ruby installed.

Out of curiosity... can you give me a link about this one?
I looked and looked...

> You are likely better off using modern JavaScript (e.g. DHTML) to
> interact with Ruby business logic running on a Web server.

I agree!

Merc.
Julian I. Kamil (Guest)
on 2006-08-03 15:45
(Received via mailing list)
When completed, Pandora (http://pandora.rubyveil.com/) will allow Ruby
scripting on the browser without requiring any client-side extensions.

The idea is to mark certain Pandora pages as scriptable, and then use
ERB to execute the embedded code in a sandbox on the server.  The
effect is that the end user (or "programmer") does not have to be on
the server to code dynamic extensions / plugins for the system.  All
they need to do is edit the page using the Wiki editor form to enter
Ruby code into the page.  The safety of this approach will depend
heavily on how the sandbox is implemented and what functions it
provide.

On a longer term, something like Scriptaculous can be integrated on the
server as well so that client side Javascript code can be callable from
Pandora Box code written in Ruby--no Javascript programming required.
No client side extensions are required--just use a plain old browser to
create dynamic Web pages.

Best regards,

Julian I. Kamil <removed_email_address@domain.invalid>
Clayton Smith (Guest)
on 2006-08-03 16:21
(Received via mailing list)
using JavaScript is definitely a good idea.. there is also ruby.js
which was written by flrgr.

"This is a port of some of Ruby's standard library to JavaScript. It
shows that JavaScript is indeed a well-thought out language (even if
it's standard library is quite cumbersome). The fact that pretty much
everything is based on other components clearly without duplicating
logic should make this interesting.
.....
Note that there are some differences between this and Ruby, especially
that Hash#each yields value,key instead of key,value"

related links:
http://www.advogato.org/proj/Ruby.js/
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/...
http://www.openjsan.org/doc/f/fl/flgr/ruby/js/0.4.0/
James B. (Guest)
on 2006-08-03 16:22
(Received via mailing list)
Tony M. wrote:
>
> Out of curiosity... can you give me a link about this one?
> I looked and looked...


ActiveScriptRuby 1.8.4.1

http://arton.hp.infoseek.co.jp/




--
James B.

"A principle or axiom is of no value without the rules for applying it."
   - Len Bullard
This topic is locked and can not be replied to.