client-side Ruby on iPad/iPhone?

J

Jeff Pritchard

I've seen jRuby and IronRuby, and really want to use them since i really
really hate javascript and since so much of a modern web app winds up on
the client side…but none of the client-side ruby solutions I've found
will work on mobile devices.

Are there any? (even something that is much less complete or
performant?)

thanks,
jp
 
J

Joel VanderWerf

Jeff said:
I've seen jRuby and IronRuby, and really want to use them since i really
really hate javascript and since so much of a modern web app winds up on
the client side…but none of the client-side ruby solutions I've found
will work on mobile devices.

Are there any? (even something that is much less complete or
performant?)

have you seen rhomobile / rhodes?

You can't load scripts at run time, IIRC, but otherwise it's a ruby
interpreter.
 
D

David Masover

I've seen jRuby and IronRuby, and really want to use them since i really
really hate javascript

Do you really know JavaScript well enough to hate it? It's possible you're an
exception, but most people who hate JavaScript don't seem to know it
particularly well.
none of the client-side ruby solutions I've found
will work on mobile devices.

I know I've seen a few -- I definitely saw an irb prompt on Android at one
point:

http://blog.headius.com/2009/08/return-of-ruboto.html

Someone correct me if I'm wrong, but doesn't the iPad/iPhone developer
agreement now limit implementation languages to an Apple-sanctioned list?

http://daringfireball.net/2010/04/iphone_agreement_bans_flash_compiler

So there may well be an iPhone implementation of Ruby, but you'll likely be
violating the agreement, and I'd be very surprised if your app made it to the
App Store.

Of course, Rhomobile has a response:

http://rhomobile.com/2010/04/09/iphone-4-0-sdk-rules/

Having read both, I don't see how they can be -- the agreement says that apps
must be _originally_written_ in that list of languages, not that it must be
compiled with an approved compiler, which is what Rhomobile seems to think it
means. Even if Apple turned around and released a clarification, explicitly
allowing Rhodes, I don't think I'd trust them at this point.

So, if iPhone matters to you, do Web apps. If cross-platform matters to you,
do web apps. If you insist on Ruby on the client, do Android or Moblin.
 
T

Tony Arcieri

[Note: parts of this message were removed to make it a legal post.]

Do you really know JavaScript well enough to hate it? It's possible you're
an
exception, but most people who hate JavaScript don't seem to know it
particularly well.


That's a pretty pretentious question to ask. But I'll bite.

Am I a JavaScript expert? But I know it fairly well. I could sit here and
prattle off a couple dozen things I hate about JavaScript, like the
practically broken coersion model, the inconsistent and likewise broken core
types, including inexplicable and useless box objects for those types and
mismatches between the literals and what core types they map to ([]
instanceof Array is true but "" instanceof String is false???), the need for
a JQuery jock strap to even make the language tolerable by masking away all
the bizarre gymnastics you'd otherwise have to do to get basic functionality
out of the language, etc etc.

But like... this is ruby-talk, and the guy wants to use Ruby instead of
JavaScript. I think you'll be extremely hard pressed to find anyone with
moderate level expertise in both languages who would disagree that Ruby is a
significantly better language than JavaScript.
 
J

Jeff Pritchard

Just to clarify…I was hoping there might be a universal replacement, not
a special case for some specific mobile platform.

Today I can make a web 2.0 rails app with gobs of yucky un-testable
javascript/jquery/prototype/ajax that will run anywhere/everywhere. It
will run on any desktop machine; any apple device; android; WP7; etc.

The problem with that approach is that a modern web 2.0 app has very
little rails. The rails part of it is quick and easy but amounts to
little more than a web service or the app's "back end". There are good
ways to do TDD for that part. Good tools, good plugins, lots of creamy
goodness all around.

Most of the development time though, is in getting a polished web 2.0
ajaxy UI stuck on the front of that. For this part (which, as I said,
is the long slow part) there is no universal ruby solution; there is no
good way to do TDD. jQuery and prototype are better than cranking all
your own javascript libraries, but they are not a GUI framework that
leads to a clean and standardized app (like rails does).

Sorry for whining. Just amazes me that so many years have gone by with
GOBS of stuff happening on the server side and NOTHING happening on the
client side to make web app development smooth and easy like server side
is.

thanks,
jp
 
D

David Masover

That's a pretty pretentious question to ask. But I'll bite.

I was never asserting that it was impossible for someone to know JavaScript
well and to hate it for that. But I do want to make sure it's an actual,
legitimate concern -- often, I see people trying to avoid JavaScript because
they like Object-Oriented Programming, for example.
Am I a JavaScript expert? But I know it fairly well. I could sit here and
prattle off a couple dozen things I hate about JavaScript, like the
practically broken coersion model, the inconsistent and likewise broken
core types, including inexplicable and useless box objects for those types
and mismatches between the literals and what core types they map to ([]
instanceof Array is true but "" instanceof String is false???),

Those are all pretty weird, though I could mention similar oddities in Ruby,
like the use of === in case statements, the concept of single inheritance but
multiple mixins (but they behave like inheritance anyway), the ugliness of
trying to pass multiple blocks as arguments, hashes as keyword arguments...

And that's not even getting to my personal pet peeves, like many C methods
calling other C methods directly (so I can't override them -- for example,
Kernel#autoload calls the C implementation of Kernel#require directly, not the
actual Kernel#require that might be there), the fact that I can't bind a
method to an object that isn't related to it (so much for duck typing)...

Every language has its warts.

But I love Ruby, mostly because of how little these things actually matter to
most of what I actually want to do. I can't say I've ever been bitten by
JavaScript's coercion model or by its odd comparisons, though it is especially
perverse that in Javascript, you can have this:

[] != []

Explosion principle for the lose.

Still, it's fair to hate a language for reasons like that. It's not fair to
hate a language because of outright wrong assumptions -- again, most (no all)
people I talk to who hate JavaScript hate it for the wrong reasons.
the need
for a JQuery jock strap to even make the language tolerable by masking
away all the bizarre gymnastics you'd otherwise have to do to get basic
functionality out of the language, etc etc.

In other words, Ruby has a better standard library. So what? I could just as
easily claim that Ruby needs a "Rack jock strap" before it's a useful Web
development language.

It also seems especially bizarre to mention jQuery here, when jQuery does
nothing to make the language itself more or less tolerable -- it wraps itself
around the DOM, though it comes with a few easily-duplicated utility
functions. Are you complaining about JavaScript, or the DOM?
But like... this is ruby-talk,

While that's true, I do try to offer general solutions, whether or not they
involve Ruby. I also try -- and I've been accused more than once of being rude
and pretentious for doing so -- but I try to find out what the actual problem
is that someone's trying to solve and provide a solution to that problem,
rather than to the specific question they asked.
and the guy wants to use Ruby instead of
JavaScript. I think you'll be extremely hard pressed to find anyone with
moderate level expertise in both languages who would disagree that Ruby is
a significantly better language than JavaScript.

It depends what your goals are -- and you have to set some sort of goal before
you can define a language to be "better" than another.

I like Ruby. I'm certainly not going to start using v8 on the server side
anytime soon. I'll run JRuby on Appengine to avoid writing Java or Python --
but I won't run JRuby applets on the client to avoid writing Javascript.
 
S

steve ross

Hello--

Just to clarify=85I was hoping there might be a universal replacement, = not=20
a special case for some specific mobile platform.
=20
Today I can make a web 2.0 rails app with gobs of yucky un-testable=20
javascript/jquery/prototype/ajax that will run anywhere/everywhere. = It=20
will run on any desktop machine; any apple device; android; WP7; etc.
=20
The problem with that approach is that a modern web 2.0 app has very=20=
little rails. The rails part of it is quick and easy but amounts to=20=
little more than a web service or the app's "back end". There are = good=20
ways to do TDD for that part. Good tools, good plugins, lots of = creamy=20
goodness all around.
=20
Most of the development time though, is in getting a polished web 2.0=20=
ajaxy UI stuck on the front of that. For this part (which, as I said,=20=
is the long slow part) there is no universal ruby solution; there is = no=20
good way to do TDD. jQuery and prototype are better than cranking all=20=
your own javascript libraries, but they are not a GUI framework that=20=
leads to a clean and standardized app (like rails does).
=20
Sorry for whining. Just amazes me that so many years have gone by = with=20
GOBS of stuff happening on the server side and NOTHING happening on = the=20
client side to make web app development smooth and easy like server = side=20
is.
=20
thanks,
jp
=20
=20

There are numerous js test frameworks. One that is similar to Test::Unit =
is jsTest. You can read about it here.=20

http://thinkpond.org/articles/2008/jstest-intro.shtml

If you are more of an rSpec kind of person, then look into jsSpec or =
ScrewUnit:

http://jania.pe.kr/aw/moin.cgi/JSSpec

http://github.com/nkallen/screw-unit

Rubyists are likely to use TDD or BDD, but it is more how they think =
about development than about available tools. There are tools available =
for testing other languages.

Hope this helps.

Steve=
 
J

Jeff Pritchard

Thanks Steve. I will check these out.

jp

Steve said:
Hello-- ...

There are numerous js test frameworks. One that is similar to Test::Unit
is jsTest. You can read about it here.

http://thinkpond.org/articles/2008/jstest-intro.shtml

If you are more of an rSpec kind of person, then look into jsSpec or
ScrewUnit:

http://jania.pe.kr/aw/moin.cgi/JSSpec

http://github.com/nkallen/screw-unit

Rubyists are likely to use TDD or BDD, but it is more how they think
about development than about available tools. There are tools available
for testing other languages.

Hope this helps.

Steve
 
T

Tony Arcieri

[Note: parts of this message were removed to make it a legal post.]

Those are all pretty weird, though I could mention similar oddities in
Ruby,
like the use of === in case statements


Of all of the examples of "weirdness" in Ruby, I wanted to single this one
out. The === operator is the closest thing Ruby has to pattern matching,
and for what it's worth I think using === as the basis of case is one of the
more brilliant things Matz did.

True pattern matching is nicer, no doubt, but failing that, I'm a big fan of
the === approach.

masking away all the bizarre gymnastics you'd otherwise have to do to get

basic functionality out of the language, etc etc.

In other words, Ruby has a better standard library.


Not the standard library, but rather core types. Ruby's core types are
simply beyond compare, as are the core functions of Object which due to
Ruby's everything-is-an-object nature are inherited by all the core types.

I am constantly surprised and disillusioned by Rubyists who look a gift
horse in the mouth and go "nah, **** that, let's use prototype-based object
orientation"

So what? I could just as easily claim that Ruby needs a "Rack jock strap"
before it's a useful Web development language.

If that's what you think you completely missed my point. JavaScript is
missing core functionality which libraries like JQuery and Prototype
provide, and the way this core functionality is implemented is a complete
hack, because JavaScript's built-in operators for providing the same
functionality are fundamentally broken. For example, consider basic type
checking, which can certainly incite a bit of a holy war in the dynamic
language community so I'm a bit lax to bring it up. But JavaScript's
instanceof operator is fundamentally fucked and completely broken, some
examples of which I provided earlier. So how does JQuery implement basic
type checks, like isArray?

From http://code.jquery.com/jquery-1.4.2.js


isArray: function( obj ) {
return toString.call(obj) === "[object Array]";
}

JQuery has bounced around on the implementation of this particular function
considerably. Why? Because it's so hard to provide consistent semantics
across multiple JavaScript implementations. And this is what they've
settled on... a string comparison of the "toString" result. Really? That's
the best they can do? Yes, yes it is.

As a language implementer perhaps I'm a bit of a snob about these things. I
don't buy into the school of thought which believes type checking in a
dynamic language is bad. I think it's completely necessary to provide
useful errors, among other things. You get that "for free" in statically
types languages, granted, and in dynamic languages people either type check
function arguments or entirely resent the notion of doing so and leave the
matter of debugging unexpected objects passed as arguments to a function not
designed to receive them as an exercise to the end user.

I make the decision as to whether I should type check the arguments to a
particular function on a case-by-case basis. Without a JavaScript "jock
strap" like JQuery or Prototype, this isn't particularly doable in
JavaScript, since the built-in facilities for doing so are fundamentally
broken to the point no one ever uses them.

Bottom line, JavaScript comes broken by default, and...

It also seems especially bizarre to mention jQuery here, when jQuery
does nothing
to make the language itself more or less tolerable -- it wraps itself around
the DOM, though it comes with a few easily-duplicated utility functions.


...I must strongly disagree here, what you deem "a few easily-duplicated
utility functions" are extremely difficult and controversial to write, to
the point they fluctuate frequently, and provide essential functionality
which is missing from the core language.

JavaScript is ugly and broken by default. Ruby is not.
 
D

David Masover

Not the standard library, but rather core types.

I don't see much of a difference, except where there are artificial
limitations -- "primitive" types - but you weren't talking about that, were
you?

And your mention of jQuery (and _still_ not Prototype) suggests it's not the
primitive types you care about, it's the DOM types. Really? Is it worse than
REXML?

An ugly API can be wrapped. This one is ugly, but not terribly poorly
designed, so it can be dealt with. I much prefer it to an ugly language, or a
poorly-designed API that's more difficult to wrap.
Ruby's core types are
simply beyond compare,
Really?

as are the core functions of Object

I mean, really? BlankSlate had to strip those out, in a not entirely intuitive
way. We needed 1.9 to adopt BasicObject instead for this kind of thing to work
properly.

We also needed 1.9 to fix the encoding issue, and we still have libraries that
assume strings are sequences of bytes. This is something Java got a lot closer
to right the first time around -- UTF-16 may be limited, but it's a hell of a
lot better than ASCII.

And why the distinction between methods, blocks, and lambdas?
I am constantly surprised and disillusioned by Rubyists who look a gift
horse in the mouth and go "nah, **** that, let's use prototype-based object
orientation"

So... now you don't like prototypes?
If that's what you think you completely missed my point.

Apparently. I still am.
JavaScript is
missing core functionality

What functionality?
which libraries like JQuery and Prototype
provide,

Again, what functionality? JQuery and Prototype are huge libraries.
For example, consider basic type
checking, which can certainly incite a bit of a holy war in the dynamic
language community so I'm a bit lax to bring it up.

As well you should be. If I don't check types often in Ruby, it seems even
less likely I'd want to in JavaScript.
But JavaScript's
instanceof operator is fundamentally fucked and completely broken, some
examples of which I provided earlier. So how does JQuery implement basic
type checks, like isArray?

From http://code.jquery.com/jquery-1.4.2.js

isArray: function( obj ) {
return toString.call(obj) === "[object Array]";
}

JQuery has bounced around on the implementation of this particular function
considerably. Why? Because it's so hard to provide consistent semantics
across multiple JavaScript implementations.

So, aside from the semantics which are actually spelled out in ECMA-262, what
about actually checking the prototype tree via __proto__?
As a language implementer perhaps I'm a bit of a snob about these things.
I don't buy into the school of thought which believes type checking in a
dynamic language is bad.

Maybe not "bad", but depending on it is probably not a good idea. It's also
really, really difficult to see when I'd need it, or need it to absolutely
work reliably -- for example, Ruby's kind_of? can be overridden.

By contrast, it's actually quite easy to see cases where duck typing can be
really useful, and where I'm going to resent it if you force me to override
#kind_of? or something similar to convince your method to take my object
seriously.
I think it's completely necessary to provide
useful errors, among other things.

Don't you get that for free anyway, by providing a useful toString() method?
leave the matter of debugging unexpected objects passed as arguments to a
function not designed to receive them as an exercise to the end user.

To be fair, this is a common pattern in Ruby -- again, duck typing.
I make the decision as to whether I should type check the arguments to a
particular function on a case-by-case basis. Without a JavaScript "jock
strap" like JQuery or Prototype, this isn't particularly doable in
JavaScript, since the built-in facilities for doing so are fundamentally
broken to the point no one ever uses them.

Bottom line, JavaScript comes broken by default...

You haven't provided a refutation of any sort to my point about a "Rack jock
strap", or maybe an extlib or activesupport jock strap?

I just don't have a problem with a language which requires libraries to be
useful. In fact, I consider that a plus -- if it's something a library can do
well, I'd rather have it in a library than in the core language.
...I must strongly disagree here, what you deem "a few easily-duplicated
utility functions" are extremely difficult and controversial to write, to
the point they fluctuate frequently, and provide essential functionality
which is missing from the core language.

I'll concede that they may be difficult, and I'm sure I'm underestimating the
instanceof problem above. I just don't agree that verifying the type of
something is essential functionality. It seems like I'm reaching for
Activesupport to give me 5.minutes.ago far more often than I'm reaching for
jQuery to tell me whether something's an array or not.

What else is broken by default? I'll give you a skin-deep ugliness, sure.
 
T

Tony Arcieri

[Note: parts of this message were removed to make it a legal post.]

I'll concede that they may be difficult, and I'm sure I'm underestimating
the
instanceof problem above. I just don't agree that verifying the type of
something is essential functionality. It seems like I'm reaching for
Activesupport to give me 5.minutes.ago far more often than I'm reaching for
jQuery to tell me whether something's an array or not.

What else is broken by default? I'll give you a skin-deep ugliness, sure.

You know, we can beat around the bush all day about this. I think I'll just
end on this note:

http://jmesnil.net/weblog/wp-content/uploads/2009/09/RzRcw.jpg

<http://jmesnil.net/weblog/wp-content/uploads/2009/09/RzRcw.jpg>:)
 
D

David Masover

e.
=20
You know, we can beat around the bush all day about this. I think I'll
just end on this note:
=20
http://jmesnil.net/weblog/wp-content/uploads/2009/09/RzRcw.jpg

You could likely draw a similar comparison with many other languages. From =
the=20
preface of "The Good Parts":

"This is not a book for beginners... This is not a book about Ajax or web=20
programming... This is not a book for dummies. This book is small, but it i=
s=20
dense. There is a lot of material packed into it."

=46rom the preface of "The Definitive Guide":

"Chapter 1 provides an introduction to JavaScript... Chapters 2 through 6=20
cover some bland but necessary reading; these chapters cover the basic=20
information you need to understand when learning a new programming=20
language....

"The next six chapters... document parts of the language that will not be=20
familiar to you even if you already know C or Java....

"Part II explains JavaScript in web browsers.... Part III and IV contain=20
reference material covering core JavaScript and client-side JavaScript,=20
respectively. These parts document relevant objects, methods, and propertie=
s=20
alphabetically."



If nothing else, it's the difference between a best-practices Ruby book for=
=20
experienced developers, and a comprehensive introduction to Ruby and Rails =
for=20
non-programmers. It's the difference between saying "Don't use mass=20
assignment" and a screencast walking you through all the details of what ma=
ss-
assignment is, how it could be exploited, how to fix it, and what happens w=
hen=20
people try to exploit it again.



I can respect wanting to end what could be a very long and offtopic flamewa=
r,=20
so I hope that was a tongue-in-cheek thing, and not an attempt to present=20
actual evidence. I just couldn't let that go unchallenged.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads


Members online

Forum statistics

Threads
473,756
Messages
2,569,533
Members
45,007
Latest member
OrderFitnessKetoCapsules

Latest Threads

Top