[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

FAQ and JavaScript vs. Ruby (was Re: rubynuby - client side Ruby?

Gregory Seidman

2/22/2006 1:04:00 PM

On Wed, Feb 22, 2006 at 12:45:09PM +0900, Jeff Pritchard 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
9 Answers

Jeff Pritchard

2/22/2006 9:07:00 PM

0

Gregory Seidman 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

--
Posted via http://www.ruby-....

David Vallner

2/23/2006 1:52:00 AM

0

Dna Streda 22 Február 2006 22:06 Jeff Pritchard napísal:
> Gregory Seidman 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 Vallner

Bill Kelly

2/23/2006 2:40:00 AM

0

From: "David Vallner" <david@vallner.net>
>
> 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/... 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 Leon

2/23/2006 2:47:00 AM

0

> 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

2/23/2006 4:19:00 AM

0

Ramon Leon 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 Britt

"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

3/3/2006 5:56:00 AM

0

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.

On 2/22/06, Bill Kelly <billk@cts.com> wrote:
> From: "David Vallner" <david@vallner.net>
> >
> > 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/... 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
>
>
>
>


--
Charles Oliver Nutter @ headius.blogspot.com
JRuby Developer @ jruby.sourceforge.net
Application Architect @ www.ventera.com

Bill Kelly

3/3/2006 8:10:00 AM

0

From: "Charles O Nutter" <headius@headius.com>
>
> > 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

3/3/2006 3:32:00 PM

0

On Fri, 03 Mar 2006, Bill Kelly defenestrated me:

> From: "Charles O Nutter" <headius@headius.com>
> >
> >> 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!
>
> 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...

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
jruby-devel@list.sourceforge.net.

-Tom

--
+ http://www.tc.umn.... +---- mailto:enebo@acm.org ----+
| Thomas E Enebo, Protagonist | "Luck favors the prepared |
| | mind." -Louis Pasteur |

Charles O Nutter

3/3/2006 3:40:00 PM

0

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

On 3/3/06, Bill Kelly <billk@cts.com> wrote:
> 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.utilBSFEngineImpl;
> src/org/jruby/javasupport/bsf/JRubyEngine.java:import org.apache.bsf.utilBSFFunctions;
> // . . .
>
> 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

--
Charles Oliver Nutter @ headius.blogspot.com
JRuby Developer @ jruby.sourceforge.net
Application Architect @ www.ventera.com