Client-side Ruby on iPad/iPhone?

Ruby
1

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

2

Jeff P. wrote:

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.

3

On Friday, July 16, 2010 10:35:17 pm Jeff P. wrote:

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:

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

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.

4

On Sat, Jul 17, 2010 at 12:46 AM, David M. [email protected]
wrote:

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.

5

On Saturday, July 17, 2010 11:43:52 am Tony A. wrote:

On Sat, Jul 17, 2010 at 12:46 AM, David M. [email protected] wrote:

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.

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.

6

Hello–

On Jul 17, 2010, at 5:21 PM, Jeff P. wrote:

ways to do TDD for that part. Good tools, good plugins, lots of creamy
GOBS of stuff happening on the server side and NOTHING happening on the

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

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

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

7

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

Jeff P. wrote:

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

8

Thanks Steve. I will check these out.

jp

Steve R. wrote:

Hello–
…

thanks,
jp

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

GitHub - nkallen/screw-unit: A Javascript BDD Framework with nested describes, a convenient assertion syntax, and an intuitive test browser.

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

9

On Sat, Jul 17, 2010 at 9:41 PM, David M. [email protected]
wrote:

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.

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.

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

10

On Mon, Jul 19, 2010 at 11:55 PM, David M. [email protected]
wrote:

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:slight_smile:

11

On Sunday, July 18, 2010 09:30:37 pm Tony A. wrote:

On Sat, Jul 17, 2010 at 9:41 PM, David M. [email protected] wrote:

In other words, Ruby has a better standard library.

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, fuck that, let’s use prototype-based object
orientation”

So… now you don’t like prototypes?

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.

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.

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.

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.

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.

12

On Wednesday, July 21, 2010 12:22:58 pm Tony A. wrote:

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

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

“This is not a book for beginners… This is not a book about Ajax or
web
programming… This is not a book for dummies. This book is small, but
it is
dense. There is a lot of material packed into it.”

From the preface of “The Definitive Guide”:

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

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

“Part II explains JavaScript in web browsers… Part III and IV contain
reference material covering core JavaScript and client-side JavaScript,
respectively. These parts document relevant objects, methods, and
properties
alphabetically.”

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

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