Cross platform desktop apps in Ruby, HTML and JS | Hacker News Reader

Cross platform desktop apps in Ruby, HTML and JS

bowlineapp.com

99 pointsduck28 comments

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

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.

http://www.appcelerator.com/

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 ;)

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

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.

Can anyone give any opinions on this vs Appcelerator?

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.

Its just a ruby container for webkit. So Appcelerator, or I think you are talking about their titanium container, is just like this.

The basic idea is that you bundle a browser, and then using your programming language of choice, you can create APIs that are available inside JavaScript.

So, you can also probably create functionality in ruby, that can then be accessed in JavaScript.

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

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

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

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.

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

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.

Will there be some deb/rpm packaging tool included?

There will be. At the moment though, linux support is very basic. There's no automatic packaging. When it comes to packaging and distribution, the mac version is more developed.

Oh, very nice.

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

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.

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.

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.

Agreed. I was going to look into it, but not having windows support means you block 90% of your market. It's deceptive because saying "cross platform" to a developer (especially for a desktop app) means "runs on most devices". Using the term otherwise is a semantic game.

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.

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

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?

Bowline is being developed for Taskforce (http://taskforceapp.com), a commercial application, so Windows support is definitely coming. Estimation... well, I think we'll have support by September.

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.

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.

Reply on news.ycombinator.com