
Cross platform desktop apps in Ruby, HTML and JS - duck
http://bowlineapp.com
======
voidfiles
I love that the idea of cross-breed HTML/JS/? is coming to the forefront, and
this might be a great solution one day. But, right now there are many such
projects.

They all fall on a spectrum from super specialized, like this project, and
full blown browser. If you found this interesting you should also check out.

<http://fluidapp.com/> <http://fluidium.org/> <http://prism.mozillalabs.com/>
<http://www.adobe.com/products/air/> NativeHost described here:
[http://cappuccino.org/discuss/2010/05/13/nativehost-run-
your...](http://cappuccino.org/discuss/2010/05/13/nativehost-run-your-
cappuccino-applications-on-the-desktop/)

I really would love to know if there are any other apps like this out their, I
am trying to catalog them all. I think containers like these have a big
future.

~~~
nkh
Do any of these have anything close to the table Grid support you can get with
a .net control. It seems like there isn't a good way to load a ton of data in
a table (100 K +) and work with within an app built with HTML and JS yet. Am I
wrong? I hope I am ;)

~~~
jonah
Not exactly, but have you seen the Spry stuff? I've used it for (admittedly
smaller) datasets and been impressed.

<http://labs.adobe.com/technologies/spry/home.html>

------
vault_
Well, I can't get the initial installation to work right, because access is
denied to a zip file it tries to download off of AWS (I don't know why it's
necessary or denied).

I do think, however, that this is a step in the right direction. In my
opinion, GUI apps on Linux are for the most part extremely uninspired, and in
spite of popular opinions to the contrary, I still prefer to use a native
application in lieu of a web-based one. I think that webkit could be an
awesome platform for desktop apps, both in ease of development and quality of
finished product.

I don't think that this is quite a big enough step towards that though. For
one, it makes the developer write html, css, and javascript. This means that
ultimately the applications produced aren't going to really feel native on any
platform. Rather, they'll feel like quick web app running in its own window.
That's not necessarily a bad thing, but I think it could be better.

In my ideal world, this would be somewhat closer to a traditional widget
toolkit, but built on top of webkit. It would still be html and js at its
core, but from a developers perspective it would be closer to using something
like SproutCore.

As I said though, I can't get it to run properly, so I may be way off base
from just looking at the code for the sample applications. I think it may also
be possible to get what I'm describing on top of Bowline. There's definitely
some potential in this area though, and I'm going to mess with it some more
and keep and eye on it.

------
vena
Can anyone give any opinions on this vs Appcelerator?

~~~
maccman
Appcelerator Titanium is more of a platform than a framework. I guess it's
like comparing CGI.rb to Rails. The other major issue with Ruby support on
Titanium is that Ruby 1.9 isn't supported, c exts aren't supported, and
Threads aren't supported. In other words the UI locks up whenever you call out
to Ruby. Bowline used to sit on top of Titanium, but I made it standalone for
those reasons.

------
jamesbritt
Nice. Wonder what's needed for packaging and distribution. Does the end user
have to have Ruby 1.9 installed already?

~~~
maccman
No, the end user doesn't need anything extra installed. Ruby 1.9 (and WebKit
if needed) is bundled.

~~~
dasboot
How, if at all, are you going to protect the ruby source code?

~~~
maccman
I'e written something called rbyte which byte compiles Ruby 1.9.2 code:
<http://github.com/maccman/rbyte>

Eventually I'll integrate it into Bowline so your source code will get
compiled automatically.

~~~
dasboot
Thanks for your answer. I'm very excited about the project, esp. with a future
server sync api (as mentioned in the roadmap). Perhaps I then could finally
write a decent evernote client for linux. :)

~~~
maccman
The sync API has already been released: <http://github.com/maccman/syncro> \-
I'm also just about to release the JavaScript version of the client (so you
can have realtime sync between web and desktop apps.

------
jister
If it doesn't support Windows then it shouldn't be called "Cross Platform",
no?

~~~
chc
No, the definition of "cross-platform" is not "supports Windows." It works on
two different platforms, so it's cross-platform. Much like how Photoshop is a
cross-platform application even though it doesn't support Linux.

~~~
bruceboughton
But given that Windows is still the dominant platform in the desktop space it
would be disingenuous to claim this it's "cross-platform" if it's not coming
to Windows soon.

~~~
chc
It isn't disingenuous for them to use a word exactly as it is defined. If this
were a framework that allowed normal Linux apps to run natively (i.e. not in
X11) under OS X and they said it allowed "cross-platform compatibility between
Linux and OS X," would you say that's disingenuous too? Calling it
disingenuous seems disingenuous to me — just because it would be nice if it
did Windows doesn't mean Windows support is a requirement to be cross-
platform.

At any rate, the Bowline site says Windows support is coming soon, so I don't
see the problem at all.

------
BudVVeezer
No offense, but web tech on the desktop has been tried before (a la Java) and
the user experience sucked everywhere. I'm not convinced this will be any
different from the user's perspective.

------
thibaut_barrere
I'm wondering if I can use HAML with this. If Windows support really comes, it
would be very handy as well.

------
ddemchuk
I got really excited until I saw that it didn't support Windows yet and
required Ruby 1.9. Nice looking setup at least though.

Anyone know how soon Windows support is expected to arrive?

~~~
alttab
Good luck having that one perform. Ruby on Windows is slower than the dog-dust
in my mother's urn above the fireplace.

Tongue in cheek aside - this would be really cool if it actually ran in a
browser. Linking to external content, having resource based URLs, etc - all
the good things about web development - are taken away once you leave the
browser.

~~~
costan
I wouldn't expect performance to be a problem. For computational tasks, Ruby
works just as fine on Windows as on a UNIX platform.

Windows perf suffers because (1) in some rare cases, the needed primitives
aren't provided by the kernel, and (2) Windows does some things differently,
and Ruby library authors don't have the incentives to design and maintain a
separate codepath for Windows.

The issues above don't usually arise in desktop applications. They're seen
most often in server code -- fork is missing and that sucks, asynchronous I/O
works differently, file monitoring and pipes also work differently, etc.

