Hacker News new | past | comments | ask | show | jobs | submit login
Bowline - A Ruby GUI Desktop Framework (leadthinking.com)
80 points by maccman on Aug 4, 2009 | hide | past | favorite | 19 comments



This is cool and all, but I'm really wondering to myself if it is really necessary?

Every AIR app I've run across (Flash or HTML based) has always ended up in the trash can. Either it's too slow, too obtuse, inconsistent user experience from the rest of my OS, etc. I find even the much flaunted Balsamiq to be inexcusably slow, so slow in fact I still prefer booting up XP in a VM and using Axure (which is better software anyways, but that's another topic for another day).

And I really wonder if these guys think they can do what Sun, Microsoft and - to a lesser extent - Adobe, have failed to do: build a cross platform UI toolkit without the aforementioned deficits. And then the filesystem abstractions and socket abstractions and the list goes on and on.

And, really, coding native isn't that hard on either platforms (I don't know much about Linux desktop dev, but I know plenty about Windows and just enough to shoot my mouth off with OSX). And it's not likely you're building anything of any serious complexity with AIR, Titanium, etc. anyways. I can almost guarantee you that I could build their example twitter client in Cocoa in roughly the same time and with roughly the same LoC metrics. I'm not saying that because I have a big penis, I'm just wondering what the true value of these cross platform tools are when they only deliver on a small percentage of what my particular OS has to offer.

It almost feels like you are sacrificing usability for a developer's laziness. For example, I built this in ~10 hours: http://videos.massify.com/prototype/shave.demo.mov - including the custom UI widget to visually create a video clip.

Anyways, cool work, nice demo, good luck!


Certainly, I think your point about performance is a very valid one. Adobe Air lacks performance, especially combined with Flex - but I think that's more of an issue with Flash on OSX than anything else.

In my experience, Titanium (which Bowline is built on) has good performance. Certainly they're using all the native APIs on each platform.

Personally, I find coding native trickier than html/js/ruby - but that may just be lack of practice. However, I'm sure you'll agree with me when I say developing and maintaining one codebase, instead of three, is easier.

So, it comes down to developer laziness ;), and here I agree too. However, you could apply the same argument to use of Rails to build a website over C. It's certainly an argument that's been around for a while. I personally prefer to think of it in terms of efficiency, if being lazy (writing less code) will help me build something faster, I'm all for it. I certainly couldn't code up 3 native apps in the same time as it took me to write that Twitter client.


I could build their example twitter client in Cocoa in roughly the same time and with roughly the same LoC metrics. I'm not saying that because I have a big penis, I'm just wondering what the true value of these cross platform tools are...

Well... you just said it. Cross. Platform. Sure, you could write it in Cocoa. But then you'd have to write it again on GTK+. And again on whatever the Windows kit is called (I don't know).

If you're lucky enough to be familiar coding for all three platforms, that's great for you. The last question remains: Do you want to be maintaining three separate codebases for the same product?


If you're lucky enough to be familiar coding for all three platforms, that's great for you. The last question remains: Do you want to be maintaining three separate codebases for the same product?

The question isn't what you want, but what your market wants, and whether you can afford to deliver it.


And I really wonder if these guys think they can do what Sun, Microsoft and - to a lesser extent - Adobe, have failed to do: build a cross platform UI toolkit without the aforementioned deficits. And then the filesystem abstractions and socket abstractions and the list goes on and on.

The Tcl/Tk guys did this. Check out StarKit. Only it turns out that not many people really need to do this - but the tools to do it have been available for years and years.


>It almost feels like you are sacrificing usability for a developer's laziness.

More like sacrificing usability for time/money. You may be able to create a Cocoa app in the same time as a Titanium app, but can you create a Cocoa, Windows, and Linux app in the same time? Probably not. Not all apps need native features.


This is what I come to HN for.

Awesome, well done. Don't listen to all the folks here so quick to rain on everybody's parade. I get a huge kick out of seeing people build things like this, and seeing them start and develop over time.

It's beautiful and I love it and I can immediately thing of a number of scenarios where it will be very useful.


I was just toying with such an idea and wondering why that wasn't thought before. Use webkit as the base GUI widget tied with Python/Ruby/your_favorite_lang and you get:

* Truly cross-platform GUI on major OSes.

* Smoother transition if your app needs to move on web.

* Pretty looking UI's. 5 years ago, I'd prefer VB/Delphi/.NET [1] for building state of the art UI's (backed by some commercial packages) but today the scene has been completely changed. Hard to catch up with JQuery and alike when it comes to good looking UI's with the tools above.

Downsides? Having a fully blown JS interpreter working aside and a few megabytes bigger installations? Well, I'd say, way to go boy!

Glad to see someone actually working on this idea. I hope they don't make the mistake of setting a high price for entry which would unavoidably push it into being another niche framework. Best of the luck!

[1] and good luck on Linux!


Looks like I can view the package contents of your Twitter example app and see all the source. This may not be desirable for people trying to write a cross-platform app which they can also sell. Any way to close-source the final product?


Yes, I've ported it to Ruby 1.9 When this is complete, you'll be able to byte compile all your Ruby code (and obscure all the JavaScript).


This is one reason I prefer to build cross-platform Ruby desktop apps with JRuby (and Jimpanzee + Swing). I get complied code, which happens to be insanely obfuscated.

(And I get to use the bazillion Java libs, too.)


As the web (html, js) is the future any tool porting it into proprietary platforms (desktop, phone, multi-touch) is more than welcome!

It's better to focus on a business domain than learning proprietary technologies.


Drooling...

You build a working HTML4 web app, and then sprinkle progressive enhancements with JS and HTML5 (even offline browsing!), and voilá! You've got a web application with an awesome desktop client!


Quite interesting. Have to see how this compares to using JRuby + Swing, where I have a remarkable choice of UI widgets, and tools (rawr, for example) to turn my program into .app and .exe files, with installers.

Plus, the resulting code is protected by the jrubyc compilation process. And I can use all available Java libs in my app.

Still, being able to do things in HTML is nice (though a bit limited).

Props on a very cool project.


Neat idea but the user experience is terrible. I want a whatever.app that just opens and does its thing when double clicked, not something that shows a dialog box telling me that a dozen things need to be downloaded.

Is there a way around this?


So, how does this equate to _why's Shoes framework?


* Bowline uses HTML/JS - Shoes is pure Ruby. * Bowline respects MVC. * Shoes is more developed at this time.


  Shoes is pure Ruby
Ruby wrapped around Cairo (drawing library) & Pango (text library)


Sorry, I mean Shoes is developed in pure Ruby




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: