Kyle Cordes: OK, so we're going to talk about Ruby GUI toolkits. No slides to distract you from the dazzling demos that we'll have. Actually, many of them are not very dazzling.

So, I had a long conversation with someone else at Oasis Digital about whether to even ever use any of these. His point was, and I about 90% agree with this, that for most of what you're doing most of the time, the web has won. The battle of whether to write a web app or not is a battle we should talk about historically, for most scenarios. If you're still thinking about that now, you're wasting your thought processes, because the web won when you weren't looking.

I think I would echo that. Only write a local app if you have a reason it really needs to be a local app. If it's kind of borderline, write it as a web app.

Man 1: Also, I feel guilty mentioning this, because I can't remember the name of it now. Maybe somebody else will. I was writing about this a couple of days ago. There's somebody marketing this commercial product, Slingshot.

Kyle: Yes.

Man 1: You know about it? OK. You can write it as a web app and run it as a desktop app.

Kyle: Yes, I should have mentioned a product in here. People have already done the work for you. If you want to occasionally deploy your web app as a local app, just click a couple of buttons and that happens.

Anyway, putting that aside, I'm going to talk about a whole bunch of these things. I'm going to demo a few of them, and then depending on how the time goes, we'll dig into some code in varying levels of depth.

I'm pretty picky, some of you might have noticed. I'm maybe a little more eager to attack or discard a tool than some people are. Some of you might have noticed in some of these things I maybe attacked tools that are being presented more viciously than might have been warranted. But I think there's value in being like that. I have something to offer to my customers. I say, "No, I'm not going to use that. It's not good enough."

So, the things that I was looking for in trying to pick out one or more usable Ruby GUI toolkits were basically things that, you can write something really good. You can write a really good app with the toolkit. I don't want to use a toolkit where I'm going to be forever stuck writing apps that sort of somewhat work really kludgy, and everyone can tell that I used some funky unusual toolkit. That kind of thing.

I want to write really crisp apps. More specifically, if you can read on here my bullet points, I want apps that look like they're written this year, not a decade ago. And I want apps that people would pay for.

OK, so we're trying this again. I'm not going to start over because I think it actually recorded the whole time. It just beeped at me.

I want a toolkit that lets me build apps where I have a wide variety of widgets, and those widgets are really nice widgets. If there's a tree view that's got to work nicely, it better do all the expected things. When I click on expand, if I double-click it should still expand. It shouldn't crash or something.

[laughter]

The API should be consistent and comprehensible. It doesn't have to mean guessable, that's too high, but it should be a reasonably good API. I don't want to use something where the API is just some torturous thing.

Again, I want to use something that I can use to build a piece of software that customers will pay their actual money for. Either big companies or individuals, whatever. That means it's going to need to be robust and production-grade. If you go searching for tools that do the things -- and this is often the case in Java, and it's painfully often the case in Ruby -- you can find 15 different toolkits that are the kind of thing you want. And 14 of the 15 are in beta, or pre-beta, or alpha, or 0.3 or 0.42 or something. Finish something, you know!

I want to use things that aren't finished in the sense that no one's working on them anymore, but are finished in the sense that somebody actually got this thing far enough along to call it 1.0, to call it ready to use for real.

Man 1: Just as a little bit of an aside, I think there's an opposite problem too. This is especially prevalent in the Ruby world where there's lots of stuff out there that should be called 1.0.

Kyle: Yes, and it's still called 0.7.

Man 1: 0.3 or whatever, and it gives them a really bad perception. I think it's a mistake. I think an open-source project doesn't have to be everything that you envisioned it to be to become 1.0. It just needs to be solid, a workable core.

Kyle: It needs to be working, and ship it and call it 1.0. Rails started out and got popular before 1.0, and a few releases got to 1.0 and called it 1.0. I remember that was a momentous thing when it happened. They have been steadily advancing ever since. That's a good example of how to do it right.

Man 1: Except even they waited a long time. There were production Rails apps out there on the Internet serving up e-commerce through Rails way before 1.0.

Kyle: There can be early adopters, but as your own project you should try to hit 1.0 at some reasonable time. There's an argument of how soon or how late, but "never" is not a good answer.

So, other things that I really look for. If I'm going to build a local desktop app that runs right here on my computer or something, users are not going to be as accepting of just arbitrary variability in how it looks and how it works as they will on web apps. Users will tolerate lots of variability in web apps. The buttons glow on this site and the buttons flash on this site, but they'll use them.

But when they use an application on their computer, they're going to expect it to look and feel a lot like all the other programs on their computer. And so if I'm picking a toolkit, I need to pick a toolkit that does that, because I'm trying to write apps that people will pay for. I have to meet their expectations at least approximately on how those apps look and feel.

Cross-platform is nice. It's not super-important to me. I really like Linux and I just adore Macs, but most customers today, at least that I have access to, are on Windows, so it's most important to me that whatever I pick runs great on Windows. And it's really good if it also runs on other platforms. That's kind of a bias I have which reflects the shape of my customer base. It's not necessarily the shape of the whole industry. There are companies that write Mac apps only, and they build a good business on that. If I were one of those, I would say, "I don't care about Windows. Get this junk away from me."

The other thing is, I want to pick toolkits that are popular. Not because I want to be like the cool kids, but because I don't want to be the first person to have each problem that there is to be had. I don't want to search for a problem that happens after six minutes using the toolkit and find that no one has mentioned that on any searchable place online. So, I want to use something where there's a community.

Rails is another good example there. It would be very hard to find some error that happens in Rails that you can't find by Googling for it, because there's a lot of people using it and talking about using it. Some of the one's I'm talking about here, it's not clear if anyone is using these at all.

[laughter]

Those are the things that I think about in trying to pick a platform, pick some core toolkit that I'm going to build my whole system on. If I'm just picking up some little utility, I'm not going to be as picky. But something like a GUI toolkit, you're going to invest a lot of the code that you write, it's going to be built on a working with your GUI toolkit. So, that's why I think it's right to be more demanding there than in other places.

I stumbled across these in a rather random order, Googling and finding other people's lists and so on, but I'm presenting them here in alphabetical order. I couldn't think of any better order to talk about them.

The first one is Cocoa. Sadly, I don't have a Mac. I wish I had a Mac. If I didn't have these pesky Windows customers, I would have a Mac. If I was writing on the Mac, there's a Ruby-Cocoa bridge. You use the Ruby compiler and Ruby runtime and it bridges over to call to instantiate, call methods on, and get callbacks from Objective C classes in a fairly generic way.

It's obvious from looking at this Ruby-Cocoa bridge for a few minutes that someone has really spent the time to make that work quite well. This thing looks like a fantastic solution if you're on Mac and you want to write a GUI and use Ruby. You will rarely hit any issue where you can't just do it right there in Ruby with Ruby-Cocoa bridge.

But I don't have a Mac, so I didn't try that one. I'm not going to demo it. This will be on my website and these links will all be clickable on my website, so you don't need to type them in or anything. I put them on here so in case you forgot about everything and you only had this piece of paper, you'd have it.

The next one is, there's this Fox GUI Toolkit. I carry a bias against the Fox GUI Toolkit, because when I looked at it something like five years ago, it was amazingly primitive. I tried to use it for some small project and it was very painful. It looks like it is much better now.

It doesn't make the cut for me because it doesn't really look all that modern. Let me show you an example; I believe I have one. These are three screenshots just from the Fox website. This is an application written in Ruby using the Fox GUI toolkit. This is unfortunately not one you get the source for; this is just some commercial app that somebody that picked this up and used it sent over.

I was actually really pleased with the screenshot, This is what made me think this one might be worthy of consideration. This is a pretty decent looking screenshot. It's not very 2007, it's more like something that was common around year 2000 or so. It doesn't have the Windows XP theming to it, even. It has a couple nice touches, but you can tell by the choice of the fonts and layout and such. It's not bad, but. This is an Outlook-style control; not a real well-executed Outlook-style control, but it's tolerable.

Man 2: FreeRIDE uses Fox, doesn't it?

Kyle: Yes, I saw that; there's another popular...

Man 2: Yes, that commercial IDE done by Lothar Scholz? I forget what it's called.

Man 2: ArachnoRuby uses Fox.

Kyle: ArachnoRuby. Yes, it's really rough. I used that for a while.

Man 2: The IDE? Yes, it's cluttered, and hard to find how to do things.

Kyle: I think that's partly Fox's fault. If you look at all the Fox example programs, they all look like that. That's not to say you couldn't twist it to make it look not look like that, but that seems to be where you end up.

Man 2: I mean, it's got buttons and things...

Kyle: FreeRIDE's OK.

Man 2: You can design badly or not on any of that.

Man 3: Kyle, is Fox based on a cross-platform thing?

Kyle: It is.

Man 1: So FreeRIDE could run on Windows?

Kyle: It uses non-native widgets.

Man 2: Non-native widgets and it doesn't have internationalization.

Kyle: There's a whole issue on a bunch of these I did not dive into because I spent enough hours preparing here, I spent five or six hours getting all this information, and I didn't want to spend another three days, but the level of support for internationalization and for Unicode varies widely across these things, and most of them are really bad.

Ruby is way behind Java, for example. I think that's one of the big benefits of something like Java or the Microsoft tools; where there's a big company who has customers around the world, who's pouring countless thousands of developer hours into it, is that they'll go and chase down things like making internationalization work.

Man 1: It's really surprising for Ruby. Since it came out of Japan, you would have thought they would have included that from the start.

Kyle: Mind-boggling, isn't it. [laughter]

Man 1: Since that's where it started.

Kyle: I would have thought that, but it's not really the case. Apparently it works OK in English and Japanese.

Man 1: So only two languages.

Kyle: So this is what an example in Fox looks like. Pretty decent, but you can kind of tell that it's not native; when you pick this app up, even though they didn't say it, you'd be able to feel that it's not really a Windows app. The buttons don't look quite right and the tabs don't look quite right and so on.

I might have had a Cocoa screenshot. Here's one. This is a very boring screenshot. I guess they showed that transparency works and had to simulate transparency, because this is just loaded from a Nib file. Is that what they're called, or something different?

Man 3: From the Mac? Nibs.

Kyle: Yes, Nibs. You use the user interface design tool like you would anything else, but you get to write the code behind button clicks in Ruby.

What's next? Oh, OK. Fox -- I think this is true -- Kurt's going to tell me whether I'm right or wrong every time I mention this, but I'm under the impression that this is in the box and working in the one-click installer.

Man 3: Yes it is.

Kyle: That's a big plus. The ones that are in the box and working you're far more likely to find someone else out there using to help you if you need help. The ones that are only usable if you dig deep to get them to work, a lot less people are going to be using them.

The next one is Gtk. I have Gtk running on this thing so, depending how the time goes, we're going to go over some code. Gtk definitely passes the test of: "Can it build really smooth, slick apps?" I have a few machines running Ubuntu Linux, which comes with Gnome by default. The Ubuntu people have gone to great effort to pick out applications and get them working to come up and look good. It's all built on Gnome, Gtk, and yeah, they have succeeded. It has an almost Macintosh-like look in how polished it is and how it all fits together.

Gnome uses a tool called Glade which is like the Mac user interface builder and emits these XML files which are like Mac Nib files. You can use a standard interface builder for any of the languages, and I think that's a really good thing; you don't have to pick up a Ruby-specific interface builder, and you can use the same user interface tool that everyone uses, the same one they use for all the C++ apps they ship with their Linux distros so you can get a very native look on Linux.

I also found that the Gtk+ today also looks pretty good on Windows. I tried it a few years ago and it looked pretty bad on Windows. I'll run the sample apps and you'll see it looks pretty good.

Man 2: The last time I looked at Gtk, I didn't get past the license on Windows. That's changed, hasn't it?

Kyle: I believe all this stuff is LGPL, which means as long as you're OK with not static linking it, you're ok. If for some reason you want to static link it, then sorry, you're not going to be able to. Some people are really upset about that. I don't know why they would be, because I can't imagine wanting to static link Gtk into my program.

Man 3: Was your question about Gtk or Qt?

Man 2: Years ago, it was open source or free on all platforms other than Windows.

Kyle: That was Qt. Let's not talk about that.

Man 1: Ah, I'm getting them mixed up. Thanks for the correction. That's on page two here. By the way, is that still true for Qt. or have they fixed that licensing problem?

Kyle: They fixed that, but we'll get there. I mean, it's still expensive.

How do you run this thing? Double-click, yeah. This is their demo app; a good way to demonstrate it. Each of these things you double-click, it brings up a window that demonstrates something. You can see they have things like a built-in way to do autocomplete drop-downs; that's nice that they have that working in the box. Something else they had working that seemed impressive, they also have this kind of stuff working out of the box. You can load up an animated gif and it works, that kind of thing.

There's one of these -- I forget which one it is -- that showed particularly well they'd really thought things through. This is their list widget, and they made it an editable list. You can double-click on it and then type things into it. A lot of these toolkits have real primitive lists, where you can make a list, but there's no way to make an editable list. So if the user says, "Hey, we wanted this list; we want to be able to type right in it like you can in Excel". Well you can start from nothing and build your own grid widget from scratch, and that's a pretty big project.

This one clearly meets the idea of having a great number of decent built in components.

If you want to make a -- in the Java world, they're calling it filthy-rich GUI -- everything's got to be gradient shaded and animated and everything. [laughter] This has all the support for the things you would want if you wanted to be able to do that.

Man 2: OpenGL and stuff like that?

Kyle: OpenGL's in here too, and I'll actually talk about OpenGL later. There's a way -- I don't think it's in this demo -- but there's a way of putting an OpenGL frame inside your app.

Gtk, which didn't work for me when I tried it because I was using a just-upgraded Linux box I suppose, it's a one-liner to get it in there and working. Your Linux distro is going to have really good support for Gtk in there most likely. You do this one-liner to get the Ruby bindings in and then your apps just run. In Windows you have to download several huge installers and install them, and they throw crap all over your hard drive, but in Linux you just run a couple installs and it's there.

Man 2: What kind of problems did you run into? You said you ran into problems getting it to run in Linux?

Kyle: Yes, at least one website, you could do this one-liner and it would come up and run. I found that it just didn't work for some reason. Typing it as a one-liner simply didn't work. I made a file and tweaked it a couple of times and installed a missing dependency and it didn't work.

Man 2: Your point about not being able to static link it would be that if you did static link it that it would become GPL as well?

Kyle: I guess if you were writing maybe some kind of embedded application or something, that would become important. It's not clear to me why that would ever become important. I saw some online discussion with some people who were very worried, "Don't let this near your system! This LGPL thing is evil."

Man 1: Well, I guess you wouldn't have installed it, right? If you static linked it then you could distribute your app as an.exe without having to require anything else.

Kyle: Well, I don't think the LGPL stops you from distributing the dynamic library. You just can't static link it. Your program directory you're installing to, at least on Windows, that I'm familiar with, you're going to have a file. I mean, if you're installing a local Ruby app, you're going to spray thousands of files on the guy's hard drive, anyway, to make the thing work. Why do you care if you're going to put one more in for a dynamic library for GTK, or five more in, however many they have it shattered into? This is one that I have up and running because it's more code. So, you can kind of get through these.

Next approach, which Mark mentioned, was write a Swing app and use JRuby. I have kind of a gripe in here. I ruled this out because JRuby is not ready for primetime. They're clearly on a path to eventually be good, but it does not in any way meet that 1.0 shipping-ready, robust, to ship to customers who are paying money.

Man 3: I think the version right now is 0.9.8, indicating that they feel they're almost there. I think they're trying to put pressure on themselves to be able to say that they're there by the time Java one gets here, which is in May, I think.

Kyle: Do they stand a chance?

Man 3: The flow of new bugs is pretty strong right now, on the early one. I don't know.

Kyle: There's kind of an arc that systems go through. Maybe we could draw a little chart, but if the flow of new bugs isn't even slowing down yet, you are not close to done. You need to get to where the flow of new bugs is really just a trickle and that you're fixing bugs faster than new bugs. Again, a list of bugs, you don't have to wait until the list is all the way down to zero before you ship. You should at least be to a point where you're marking them off at a higher rate per week than you're adding them on. And if you still have a big flow of new bugs, it's a bad sign.

Man 3: It might be that it's a chicken and egg thing. They might be trying to get more people to use it to find the bugs, and they weren't if it's too low a version. I don't know. I mean, it could be that kind of thing too.

Kyle: Users who first adopt something, when they find bugs in their first few weeks or first few hours of use, tend to be really disillusioned. So, I think your top priority should be fix bugs in the order people will hit them, so at least you stand a chance of them staying in your space long enough to get addicted to it before they hit so many bugs that they leave.

It was my impression from reading the JRuby stuff for about 30 minutes that they are not close. I know you're more into JRuby.

Man 3: Yes, well, I feel the same way. I think it is going to be something cool, but maybe another six months. It's fun to play with now.

Kyle: Yes, it's fun to play with. I even put a tiny bit of code here to show. It's pretty compact, it's not bad.

Man 1: The Rails test suites, but is it other areas that they're hitting on?

Man 3: That's been their primary focus.

Man 1: Focus.

Kyle: That's a pretty big hill to climb, because Rails uses a zillion features of Ruby, and if you don't get all of the ones it cares about right, it will not work.

Man 1: Charles did mention that there's a lot of edge cases in Ruby that they just haven't even had, that maybe one person on the planet's using, and so they haven't focused on a lot of these. If that one person complains about it, then they got to. There a lot of things Ruby allows you to do that they haven't looked at because it's not a very popular use of code or whatever.

Kyle: I think Ruby is going to be an extremely challenging language to write another implementation of, because it is very, very dense with those edge cases. It is not a crisply specified language.

Man 2: Specified? There is no spec.

Kyle: It's unspecified. It's almost a randomness in the specification, however it worked in the primordial version someone wrote down in what little specs there are. It's not a tightly orthogonal thing where everything is very straightforward and predictable and so on. It's kind of a mess.

Man 3: There is somewhat of a spec now, because the JRuby people thought that was such an issue that they spent a lot of time writing a spec. With Max's help and endorsement. A couple of interesting things about your code example there is that JRuby adds Ruby-like methods to the Java classes. So, for example, on the very last line when you do the "frame.setVisible true"...

Kyle: You could have said "visible = true".

Man 3: Right.

Kyle: I just grabbed one of their examples.

Man 3: That's very Ruby-like.

Kyle: I think there's a temptation if you're using something like this, where your primary toolkit, you're actually adopting somebody else's language, there's a strong tendency to write code in your language using the idioms of that language. I have been guilty of that. Not with these particular examples, I've never used JRuby for anything other than a five-line example program. But yeah, I've done that on pretty big-scale projects where you realize late in the game that you are in fact using the wrong language's idioms. You're using idioms as an accident of what toolkit you're using because that was how the examples worked for that toolkit, not the idioms of the core thing you're using.

If someone who wrote a lot of Java code, a lot of Java Swing code, started writing JRuby Swing code, you're probably going to have a tendency to write Ruby code that reads a lot like Java code. I know I certainly would. I would tend to forget Rubyisms as I was typing, and start typing Javaisms into my Ruby. I probably even put parentheses where they shouldn't be, and semicolons where they shouldn't be, all kinds of awful things.

I put those down as one of the examples, but I'm not convinced that it's really a good idea. There's this meme going around the blogosphere, and I have not yet blogged about it. People saying, "Oh, you know what, what would really fix Swing is to use one of these other languages to write your Swing app."

What they're really talking about is this sort of five lines of mess you get to write an event handler in Java. I think people who are making that argument just haven't been very far down the road of writing a Swing app, because those four or five lines you need to wire up an event handler are an insignificant part of the struggle of writing a good Swing app. They're noise compared to the big issues you're hitting.

Among other things, there's a thing called Event Handler, which I would talk about if this was a Java user group, I'll put an example up. But there's already a one-liner in Java to get to make these little one-method single-use classes go away. That's already a well-solved problem, and it's been in the Swing box since 1.4, it's called Event Handler. You write this one-liner. The one-liner is messy, so you can write your own wrapper around it, which makes it a short one-liner. That is not a big problem.

Most of what you do in Swing is talk to this huge Java API. I have a hard time believing that you're better off using another language to talk to a huge Java API, because every example you ever see is going to be in Java. The thing you're talking to is in Java. When you debug out of the source code, it's going to all be Java. It seems you need a pretty good reason other than that you just don't like typing semicolons to not use Java if 90% of your code is talking to a Java API. That's real different than a big application where 90% of the code is about some deep application-level stuff that just kind of touches the outside world at the edges. I should make a kind of diagram.

Man 1: If you're using JRuby as a glue language to be able to quickly glue things together and be able to experiment quickly, and part of that happens to be Swing, I would say it would make sense just to continue in that vein.

Kyle: Many non-GUI applications look like this: a big body of code, the small amount of API surface area touching a big body of code. Even many database applications look like this. Even if you're not using any good toolkits or anything, you're just using JDBC over in java. You're still, once you program for a few days, you're going to figure out you shouldn't type the names of actual JDBC classes all over your new java program. You're going to do this in one place instead of putting wrappers in.

And you're going to end up with a fairly small amount of API content between your code and the toolkit code. This doesn't happen when you're writing big complex GUI applications because there is so much API surface area in a GUI toolkit that you're app ends up having -- for a given amount of area for your app here -- a much larger part of your app is touching. There are many, many, many more calls back and forth between different API's for different reasons, different parameter list, different interfaces and so on in a typical rich client GUI app than there are in a typical web app or that sort of thing.

That's just a reality of how the API look, that if you look at the number of exposed methods in Swing, it is just enormous compared to the number of exposed methods in JDBC or in the servelet interface or so on.

Man 1: Wouldn't that be an argument for using a glue language, because now you've just got all these APIs and you want to be able to pull them all together in a nice readable, easy to manipulate fashion, without all the noise.

Kyle: It could be an argument for that, but if you're struggling to make it work and to work with... And you find example codes and you're running your debugger back and forth, having this big... Like if this is a small surface area and there's this translation layer in between, that's not such a big deal. If every single line in your program where you touch the other side goes through translation or whatever and you're not quite sure if it works and how it works, it's going to make your debugging very painful.

If JRuby were really, really excellent, super-polished, it might make sense, but it wouldn't make sense until you were using a glue language that would just make a fantastically good job of talking to the baseline individual toolkit you're calling.

Man 2: That's why I'm not using it yet.

[laughter]

Kyle: I'm inclined to say today,if you're trying to make a really good Swing app, I'd advise you to start by writing that Swing app in Java, then maybe later, once you're really good at writing those apps, consider using something like JRuby to make your code prettier, because it'll be prettier but it will also be in a sense another mental translation layer to go through to get it to work.

I also mention SWT here. Some people are partisans of SWT over Swing. All the same issues apply.

Man 3: There is a Ruby binding process?

Kyle: Well, there doesn't need to be, just like there doesn't need to be a Ruby binding for Swing. So you can talk to Java classes. It just works. There is, and it's JRuby. If the non-Java language you're using can just use Java API, that's good. If the non-Java language you're running on the JPM doesn't really work well until you add another layer of wrappers around every single one of those APIs, that's bad. It's not bad with JDBC, where there's five classes and not that many methods, but that's awful for something like Swing, because just wrapping all of them is going to take forever because there's a huge number of classes. If you added your own potentially broken wrapper layer around every one of those.

The next approach is, just write a local web app, and what was that tool called? I'm going to write that down.

Man 1: Slingshot.

Kyle: Slingshot.

Man 1: By Joyent.

Kyle: Oh yeah. I thought I saw it, because my site is hosted on Joyent. They suck. They are really awful.

Man 2: Well maybe Slingshot will suck too.

Kyle: I mean they're popular because they're an official sponsor of Ruby on Rails or something, but they just do a really bad job of keeping their hosting services running well.

Man 2: You know the same thing is true of TextDrive.

Kyle: Yes, Joyent is TextDrive. That's who I'm on, is TextDrive. They're totally incompetent.

Man 2: Well I don't know about the people who bought the rights to TextDrive.

Kyle: It's astonishing. There's a post on my website that I added to remind me every time I had downtimes.

Man 2: It was supposed to be a good thing, and David Hannemeyer Hansen is one of the partners in that. Collins works for Joyent.

Kyle: Who?

Man 2: [inaudible]

Kyle: Yes, OK. Joyent might have some good people. The people who run TextDrive are...

Man 2: My partner, Deb Lewis, who is in California, she skis in the Masters ski tournament or something and she does the software for them, puts all the scores up on the website and everything, and their biggest time of the year was like last weekend or two weekends ago or whatever and she said the stupid TextDrive was down...

Kyle: Oh, they'll be down for an hour at a time and they won't even say they're sorry.

Man 2: And she was saying this is the only time of the year when this thing gets hit and it's having all kind of issues.

Kyle: Tell me if you've ever heard of this: every shared host I've ever been on, which is like five of them, there's been some minor issues of being shared, you know there can be some load and so on, but you really hardly ever notice it. You know your website pretty much stays up all the time. They put it on a big, robust machine and they don't let anybody run anything that makes it crash, that's the thing. Well, over at TextDrive, when anybody on your server -- of which there's like 500 -- click on certain things in the web admin tool, it cycles Apache, serving all of your sites.

[laughter]

Kyle: Your site is down for about five minutes each time this happens because it load spike up to here, because restarting Apache with 500 sites on it is a hugely load-intensive thing. And they dismiss this whole thing "Yes, of course, you're in our shared hosting, you're going to have Apache restarts." What are you talking about?

Man 2: So when are you moving your site?

Kyle: I'm probably going to move my site pretty soon to...I've had a site on pair.com for awhile. It's had zero down-time ever in the time we've been on it, something like a year.

Man 2: P-A-I-R?

Kyle: Yes. They've been around forever. They're not very cheap, but my impression is they're quite good.

Man 3: Does it support Rails?

Kyle: I don't know, but the sites I'm going to put on it don't use Rails.

Man 2: Steve Vite uses BlueHost for that. So far I haven't heard any bad news about it.

Man 1: Yes, I'm kind of iffy on BlueHost. I'm about 50/50. I think their performance sucks. That's my big issue. They keep claiming that they've added stuff to their servers and every time I go to our website it's [explosion sound effect]. And we were like the simplest Rails website ever. I mean all it is is like two forms of, like, three database tables. How could it possibly be that bad?

Kyle: So local web apps, I think local web apps are a great way to go. That's the only one here I think I actually endorse. If I needed to build a local app today, the first approach I would dig into and try and hopefully run with is making it a local web app. I probably wouldn't use Slingshot because I'm irritated with Joyent and because I don't want somebody to have to pay Joyent for it forever.

Man 4: That's what happened to me. What I discovered is I said, "This is great," when I got on there and then I realized it was a commercial product and I'm open source and closed it. "Sorry."

Kyle: I actually don't even mind it being commercial, if I could just buy it once and be done paying them, like a developer license or something. But it's like it only works for sites they host and that's the impression I got. If you develop on their platform, then you host it in their container thing...

Man 2: You get it free, you can use it free if you host with it. If not, then I believe right now the model is that they get a small piece of every download.

Kyle: Yes, if it's really good and it's better than any of the open source stuff and it has a decent price tag on it, I'd be happy to buy it, but I'm not going to hobble my whole business to meet their business.

Man 2: In my case, I want to use it on an open source project so I don't want to pay this commercial thing that I have to buy for an open source project.

Man one There used to be something -- and I haven't watched it in a while -- called Ruby... Was it Web Dialogs or something like that? And it was the idea of running local little bitty mini web apps and it would just fire up and present the HTML browser for your dialog and click and go to the next thing or whatever. I don't know where that project's at.

Kyle: It's not hard to build, is the thing. You figure out what sort of thing... Do you want Instant Rails?

Man 2: Yes. That was what Instant Rails two was...

Kyle: If you just want Instant Rails, you get the install process which doesn't ask any questions. It installs all in its own directory and promises not to touch anything else. You have it run your app with Mongrel and you could run your Rails app and use the whole stack.

Man 2: Basically what you need do for each platform you want to run on, you need to write a startup script. So there is an.exe or system script, or whatever. Something that will fire up Mongrel or WebRed and fire up the browser, point it to the app server and that's all you need.

Kyle: It is not a big deal. It's almost the kind of thing where you write that once. You don't know how to write that, you don't have the tools to write that, you can spec and pay somebody else a few hundred bucks, online somewhere; and they would write it once for you, and you could have a whole app then. So what you would need to do then, when your app needs to do things that your browser can't do, like talk to hardware or something like that,then you write that in the server part.

Man 2: Uh-huh, because you know if you are local or something...

Kyle: Yes. That is something that is a great approach, is that you can start today thinking, this needs to be a local app. It's an opportunity to sell to an enterprise. Enterprises hate to install local apps on thousands of computers. It is not nearly as hard as they often act like it is. It is often their own rules and policies that make it so hard. But nonetheless it is hard for reasons being what they are in many companies.

If they have some app, that you can sell somebody, you say that, "We offer a local version. We also offer the server-centric version. And you pay us for the enterprise edition and we install on one server, and it serves your whole company from there inside your firewall."

If you have written it as a rich client app with any of these other tools, you are kind of starting from scratch. If you take the local web approach, you are there.

Man 2: You are almost there. You might have to change some storage code, but that might be it.

Kyle: Yes, that's right. It won't be a big deal.

Man 4: One question, Kyle. Local web apps are great, but what if you need to access the COM ports?

Kyle: That's what I was just saying. You are going to do that from the server side of your local web app. The server is running on your local machine. So you ran the installer and you put Ruby and Rails and MySQL, all kinds of other stuff, all on your local machine... Why is someone calling me when I am trying to talk...

Man 3: Your Ruby, or your controller of your web app is running Rails, right?

Kyle: They are all local.

Man 4: Put that code in there and it will have access to the hardware in the machine.

Man 2: Oh, really? Because it is already running. I'm used to doing it on a server, I didn't think about hardware access.

Kyle: Right. Since it is on the client that is the server.

Man 4: You may have to run it on a Linux or Unix box or whatever.

Man 2: The other nice thing is, you know, if you are doing that for your web apps and for your local apps, you have only one GUI language to learn and become an expert in. Not hard...

Kyle: Another big thing is if you need to integrate your local app to your websites, and it is a web app,- it's trivial. If you want to buld a plug-in architecture, it is trivial. If you want to go hire people who know how to... You want to hire some guys who know HTML, CSS, Javascript 4.5, Ruby on Rails apps and make MySQL work, that's really easy, there is a zillion.

If you want go hire somebody that knows how to use the Ruby-Cocoa bridge, my goodness, it is not hard to teach somebody the Ruby-Cocoa bridge, that is, if you are not going to find anybody who already knows it. Same with Fox. I haven't seen enough Gtk. The number of people out there available for hire who know Rails and the number of people who would be interested in a job to write Gtk apps in Ruby, I would say there is at least a factor of 100 between those. I was just taking a wild guess.

So, I think this is a very compelling approach. The reason I didn't talk about that one, was I promised to talk about how to write a real local apps.

[laughter]

Man 2: The look and feel considerations, you sort of giving it a vibe. The vibe is saying, no, it's a web app, you can't...

Kyle: That's why it is not always the way to go, because it is going to look like a web app. If you are writing an app where users are going to be tolerant of it -- you make some kind of funky app in some way -- then, yeah, you'll be good. But if you make a web app that sort of admits that it is a local web app, then it is going to work well. If you try to emulate the local client look-and-feel in your web app, it is going to work really bad.

So this is why this is not always the answer. It is the answer I would go after first, but it is not necessarily the only answer. But if I was writing an enterprise information app, like a contact management system, a CMS system of something, these things don't need to be really compelling.

But if I wanted a utility, and I wanted the utility to be represented down here, and in a control panel applet, and it runs in the background with a shaded window or something, and to integrate with 16 different parts of windows, that is going to be a real bad decision to write that as a local web app.

OK, the next one,.Net. There is a really cool looking Ruby-.Net bridge. There is even an online tutorial walking you through how to use it. Which has not been touched since December, 2004. [laughter] But maybe it attained perfection in December 2004, and there has been no reason to even update one sentence on the website. A myth, but that is remotely possible. But I think it is highly unlikely.

So one of my criteria around here, if you are looking for a good choice for an app, I mean, you're really going to be betting your project on the toolkit you use.

Man 2: On the same subject, I don't know what state it is in, but there is also a Ruby-CLR.

Kyle: Yes, there is. There is at least one Ruby compiler too, that compiles to CLR code, called Garden Point Ruby or something, which is not yet ready. Is Ruby-CLR the other one? Yes, which is not yet ready.

Man 2: That's why I said I don't know what state it's in. John Lamb, who was one of the people that picked up Ruby-CLR, he got hired by Microsoft, and so he was at the Mountain West Ruby campus. But anyway, he said that he couldn't talk a lot about what was going on, we was on non-disclosure at this point. He said they will have a big announcement for April of something they are working on. They are actively working on dynamic languages for CLR.

Man 4: I should point out that Microsoft had a recent news thing on dynamic languages and their support for dynamic languages. The first thing out of the track is going to be the Ruby support in.Net Right now, Java has a thing called Beanshell framework or something.

Kyle: Bean Scripting Framework?

Man 4: Yes, Bean Scripting Framework. They are doing the same kind of thing for.Net. You go to the Microsoft MSDN web page or whatever, and you can read the whole announcement there. The first thing, apparently, that they have working is the Ruby cross-compiler.

Kyle: So I think there is strong potential there. The underlying frameworks are nice, the Winforms is pretty nice. The WPF, Windows Presentation Framework, the Avalon, Longhorn, Vista thing, That's really nice. You can build beautiful apps, not a lot of code, just a huge explosion of HTML. My job for the last five years. That will all be readily accessible if any of these things, either a bridge or a CLR implementation of Ruby ever reaches maturity.

Man 1: So Kyle, you have said earlier, that in your current environment, it wouldn't interest you to write apps that say, only run on a Mac, or only run under Linux.

Kyle: I don't have any customers or potential customers.

Man 1: But you are feeling OK with writing apps that are locked into Windows and can't run anywhere else.

Kyle: If you are locked into Windows, you are locked into, by far, the largest market that people are buying.

Man 1: I understand that.

Kyle: If you are wandering around looking for business and products to make, you would stumble across a great many of them, where that would be, in fact, completely OK. You would stumble across only a few of them that are OK to be locked into Mac. You would stumble across probably none -- well none that you're going to go out and sell the software -- where it only runs as a client app on Linux, because the total number of people in the world that are out there buying Linux desktop software seems to be close to zero.

Now if you were writing something like a kiosk application, where you are selling a sealed machine, then there is a pretty good chance you are going to choose to seal Linux in that machine, not Windows. Then having it locked into Linux would be just totally fine.

Man 2: Well, if you are writing a kiosk or a local web app, then that...

Kyle: Or a local web app. Depends on what you want to do. If you want to do something which is hard to do in a web app. So yes, there are cases, but not as many. There are many, many apps, and of all the apps that are for sale, a great many of them only run on Windows. Enterprise apps tend to run across several, although for most enterprise apps, I think you can get away with a web app.

But consumer apps? You go to the store and see what's for sale, the vast majority of them only run on Windows. Only the most popular ones have the Mac one you can buy, and none of them have a Linux one you can buy.

Man 2: Because we're gravitating toward the business that we're in, at OCI, the amount of GUI work we do that is specific to Windows is....

Kyle: Very low, right?

Man 2: Really, really low.

Kyle: : Right.

Man 2: Less than 5%.

Kyle: Right. Unix or Mac? Unix? Linux?

Man 2: Everything.

Kyle: Most of the people, that if they have the need, that want it deployed across...

Man 2: Most of the applications do end up running under Windows, but the clients don't want it to only to be able to do Windows. So for someone interested in a career at OCI, like myself, it's not a good investment in my time to learn about Windows-specific.

Kyle: That's right. OCI sells mostly to big companies that can afford to hire OCI. In St. Louis. that means they sell mostly to people who are strongly committed to Java, mostly. Not all, but mostly.

But I think your answer's right in front of you: write your Java app and use Swing. It's in the box, hire people that know it, and a good Swing programmer -- if you write a good Swing code -- you can write really fantastic GUI's in Swing. Swing gets a lot of bad press, but if you spend the time to learn it and get good at it, it can be used to create wonderful applications.

Man 2: Down the road it could be possible that Mono would let you do some things, too, because it's usually way behind the current version of CLR.

Kyle: I should have mentioned that in here. One of these does mention it. Mono's not still on the Winforms. If you had a good Ruby-to-IL compiler, then you could run well on both Mono and.NET, that's a good thing.

Man 2: You said in your opening statement, though, that's a moot point, because you were saying for most apps, you really shouldn't even be considering whether it should be a web app or not.

Kyle: I can imagine that a great number of applications that OCI has to come in and work on that have been around for years, are going to continue to not be a web app, because the code's been written, and it works, and it's running an organization.

But if a new project was starting today, I'd say only a certain narrow sliver of those, for whatever reason, are poorly suited to web apps, would not be candidates for web apps. It's been a few years since I did much work inside huge companies, on an internal basis, but the last time I did that, the company I was at, in fact, had already made that transition. As they started new projects, they were mostly web.

What's it look like nowadays? Is it still true?

Man 3: Most of the projects we're working on at big companies are brand new.

Kyle: Four brand new ones. Is there still a strong bias toward web?

Man 3: I guess that's true, although we're doing a lot of Swing work at Boeing, heavy engineering kind of applications -- the kind that Randall used to work on -- that they feel that they need a really rich user interface.

Kyle: I think that if I was going to make a list of kinds of applications, you'd say, "Hey, maybe web is a bad idea?" I'd say engineering applications would be right up there. You want to make a really rich, powerful user interface to fully use the capability of the computer in front of the probably very valuable person sitting in front of it can use. Yes, pull out Swing, it's great. It's very performant.

If you actually do a side-by-side comparison, there are many kinds of things you can build in Swing that will be just visibly more performant that if you built the same thing in WinForms or Win32, because they do a really good job of using the graphic hardware to accelerate. Opening a window, opening a normal window in Swing will use the graphical accelerator on your computer to make that happen faster.

OK, OpenGL, the demo of this one. I mentioned this one because I think going forward, that's going to seem like a reasonable thing to pick up, to write things that are not gains or graphic demos with. I think there's a lot to be said for picking up a 3D toolkit and using that to write an application. Can you imagine what kind of applications you'd write if you got really good at using 3D toolkits, even if you were only mostly putting 2D things up? There's even things like CompBiz, and it recently merged with... What did it merge with?

Man 2: Barrel.

Kyle: Barrel. CompBiz and Barrel have merged, or are merging, or hopefully maybe merging. 3D stuff - it's everywhere. It's going to be everywhere. It's no longer some esoteric thing that only a few people use.

I get stubborn, without me having to do anything. Now I may have done something a long time ago to make this little demo work, but without having to go and remember to do anything, I could just go in here and run this little example OpenGL program, and it just worked. I didn't have to do anything. You can drag this around, OK? That's pretty slick. If you're running engineering apps, and you haven't started using OpenGL for a lot of the stuff you're doing, you ought to learn about OpenGL, because it's really cool!

How fast is this going, this Ruby app going? Well, it's spitting out frames at about 200 per second, so it's about four times as fast as it need to be for this particular very simple scene, to do arbitrarily good stuff here. If you're writing a real rich app, you might consider writing the whole thing in OpenGL.

Oh, look - now that I'm using a smaller window, it's now doing almost 2,000 frames a second, it's rendering that app. This is a fairly cheap laptop. A medium-end, high-end desktop computer, there's probably a lot more computing horsepower on the video card than there is on the core system, because main chips are starting to multi-core. I have a dual-core notebook. That's pretty high-end. You can buy quad-core CPU's now.

High-end video boards now are already doing things like 64 parallel graphic pipelines. The state of the art in graphics cards has massively more parallelism than the state of the art in core systems. There's this continuum of command line apps, and it's somewhere farther up. There's web apps. Then somewhere farther up, there's rich-client local GUI's. This is Swing, this is Flash and Ajax. I'm going to put HTML here, and Javascript, and somewhere halfway in between here there'd be something like Flash. Somewhere just north of command line there would be... What do you call that thing you can use to write the little text interfaces?

Man 2: Curses.

Kyle: Curses is way down here. Put DOS below command line. Typing passive to console is moved down below command line.

I was disagreeing with Mark that for the work they're doing for engineering stuff, you really shouldn't probably be here, you should be here. But I'd say that today's answer, if you're doing it internally at Boeing and you're only trying to beat Airbus, which is a European consortium, this is plenty good enough.

But if you were trying to make a commercial can app for building airplanes and you want to beat the market, then you'd better go up here, to use OpenGL and that kind of thing.

Man 4: Like [indecipherable].

Kyle: Off the shelf. The people that are trying to really push what's possible need to go farther up this than they otherwise would. You could make radically cooler things with this kind of technology, easily, than you can with this technology.

Another example of the gap between here and here... Has anybody been at one of the Java things where I show the little drag-and-drop Java thing, where they go, "Oooh" when they see it? I might be able to run it here, if anyone wants to see it, to show what you can do with a few hundred lines of Java code, that would be thousands of lines of pain to it working with Javascript. Maybe not that bad if you were a Javascript expert. I'm going to let that load and go on to the next one and come back to that one.

The next one is Qt. Qt is really good. It's stable and mature. KDE is built on it. You go to their website, and they have this enormous list of commercial apps that are built on Qt. It's expensive. I figured out for the addition that I would need for the work that I was going to do, I was going to need the $5,000 per developer version, which I thought seemed a little high, considering the budget of the little startup project I was looking at it for was zero.

Qt is in its own category, in terms of the level of polish. You can buy books about how to use it. It comes with really great tools for designing GUI's, and it comes with massive amounts of documentation.

The only piece that seemed to me it might be a weak link is QtRuby, but the people talking about QtRuby seem to be just amazingly happy. Apparently even the QtRuby, which is the bridge between Qt and Ruby, even though that's a little open source thing, they've used some sort of tool to help generate that binding that makes it really easy to make really good C bindings or C++ bindings, and apparently that piece is also just totally robust.

Man 1: SWIG?

Kyle: Squid? It's not SWIG, I've heard of SWIG. It's something other than SWIG. It's something that's supposedly better than SWIG.

Man 1: Apparently.

Kyle: Apparently that whole stack...

Man 2: If anyone knows what that is, post it to the mailing list so we can all know about it.

Kyle: Just go to this thing about QtRuby, and it's on the first page of their website: "we used fu to build this".

Man 2: Ok.

Kyle: That one looked really good. I think this fails the test if you want to use something that a lot of people are using, because I think the fact that it's so expensive is going to stop a lot of people from using it. Maybe not, because it's free for open source projects, even those that are on Windows.

Man 3: There's a ton of KDE projects out there. One thing...

Kyle: Because of that it may not be so hard to find a Linux/KDE guy who really wants to use Ruby, and here you go, you're going to write a Qt app in Ruby.

Man 3: One thing I found -- you know, I'm a Linux guy -- between KDE versus Gnome, and I prefer Gnome, I prefer the look and feel; but the KDE guys write apps so much faster than the Gnome guys, it's not funny. There's our word processor, and one guy wrote it in about six months or something. Something must be really nice about the API to let you do that, so I suspect that the Qt API is pretty efficient.

Kyle: For those of you who haven't seen this thing, up here, it's draggable. This is my scriptable version. I have a scriptable version of my program in which I've made it impossible to drag most of the kinds of things I can put on the screen. [clicks] How come I can't get this to open?

Man 4: Maybe it's trying to run it?

Kyle: Is it "or"? How do you say "or" in JavaScript? Is it like this?

Man 4: Yes, in JavaScript?

Kyle: JavaScript. Don't be distracted, I just happen to have this on my computer from a demo I gave or a talk I gave.

This thing right here often gives oohs and ahs and this was actually really easy to write in Swing. I didn't have to do anything at all to make it run without any kind of flicker. It was really easy to make this work.

Man 2: In a previous talk I went through how the code works, and the amazing thing is how little code there is to go over of how it works.

Kyle: If you wanted to make that today with JavaScript, and have it run in a browser across multiple browsers and that kind of thing, across all the major versions of IE, and so on, it would be a nightmare.

Man 3: Well, if you were writing from scratch.

Kyle: Yes.

Man 3: You'd use a toolkit now.

Kyle: I think it's possible that prototyping tools have come far enough with their drag and drop support it might not be nearly as bad as it used to be.

Man 3: Those are fabulous.

Kyle: You could do it in Flash.

Man 3: The only hard part would be to have the other things moving dynamically.

Kyle: Well, that's kind of the trick to the whole thing, isn't it? The fact that that they all do the right thing dynamically, and you can keep dragging them. It doesn't make you wait for them to stop before you can pick up another one.

You can do that in Flash, if you learned ActionScript, which is really Javacript, you learn their object model, and it wouldn't be bad to do it in Flash.

If I wanted to do this today, though, if I was starting from scratch, I wouldn't have picked up Swing, I would have turned my knob up higher and picked up OpenGL and I would have done this in a 3D thing. I would have made it so that while this is still moving you can drag the surface and twist the whole thing sideways. And that sounds pretty cool to me, because I've been using flat tools; but for people who play games all the time, they say "Yes, every game has done stuff way cooler than that for five years or ten years or something."

There's a few more to get through, going to abbreviate these, we're at an hour or so.

Man 2: I think the trend -- Vista's not a good example, the Mac is a good example -- that the UIs of the future are going to take advantage of 3D landscape more than they do now. If you're using OpenGL you're going to be able to get to that.

Kyle: Furthermore, with the massive move toward multicore, and the massive increase, just this exponential increase in the power of the graphics boards. Vista is driving. All new machines sold now are going to have very powerful graphics boards, because they have to work halfway decently with Vista. Ironically, copying a file is apparently far slower in Vista than it is on XP, which is slower than it is in Windows 2000. But the graphics are really cool!

I would say if you can find a project to make room for it, go ahead and move up this tradeoff, push your tradeoff that way. Don't be the last person, be the first person.

Man 2: Starting writing ordinary apps with powerful 3d toolkits.

Kyle: In fact, I think my next talk will have to be about something having to do with 3D toolkits. I don't know what language it'll be in, I don't know what group it'll be in.

Man 4: Tk?

Kyle: Tk is old and ugly. There might be a Tk partisan somewhere around. I'm hesitant to say that too loudly. I might have to edit a couple out of here when I put it on my website I don't want to get flamed by someone who loves Tk. I've never seen a Tk app that wasn't ugly. [laughter] So I have some internal thing, just going to slap a GUI on a utility program, yeah, it's great. It's in the box? Is that true?

Man 4: Yes.

Kyle: It's in the box.

Man 4: The bindings are in the box.

Kyle: Tk is not.

Man 2: You still have to install something like ActiveTcl or ActiveTk or whatever it's called.

Kyle: So, on the other one I mentioned, it's all the way in the box, right?

Man 2: Yes.

Kyle: Use that one instead. Don't use this one.

[laughter]

For the kind of things where I would use Tk, it'd be for simple things where it just doesn't matter very much, and I would happily switch to something different but similar to have the whole thing be in the box. I would probably even put Tk down here, because you're probably going to get an uglier, more simplistic looking GUI out of Tk than you are out of a decent web GUI.

Win32. I might consider this one if I was really trying to push the Win32 direction. There's a thing in the box, SWin and vRuby. They're this really slick, nicely OO wrapper around the Win32 API. They look like they were designed by someone who was looking at Visual Basic, trying to do something like VB but better. Maybe looking at Delphi, Delphi had something like this. Even some of the component naming is very reminiscent of Delphi, so it's like somebody said "I'm going to copy this Delphi design, make it better, make it Rubyesque'.

It looks really great. The problem is that the docs are almost entirely in Japanese, and learning Japanese is just way too high up the mountain to climb for me to pick up another GUI toolkit. I understand it is a very hard language to learn. I could probably learn 10 more computer languages, or I could learn Japanese.

Man 2: One thing really quick, back to Tk, is that once something gets a bad name, people don't want to go back to it.

Kyle: Yes.

Man 2: Now there is this TkTiles thing, which actually does look pretty slick, but I think because it starts with Tk, people aren't...

Kyle: People aren't even going to look at it.

Man 2: But if you go and search for TkTiles, the screenshots out there, it looks pretty polished.

Kyle: Tk is very cross-platform. It's going to work very smoothly across all your major platforms; it's a good thing.

Man 4: Qt is also, right.

Kyle: Yes, Qt is also. Qt, Gtk, Tk, Java,.NET almost...

Man 4: WXWidgets?

Kyle: Yes, we didn't talk about that much. WxWidgets with WxRuby with WxSugar on top of that. The WxWidgets is great; it's being used from C++ and from Python to make great commercial apps. Let's see if I grabbed the screenshots of this or not. I didn't grab any screenshots. It's really good. It's very robust; it does not crash, at least not very often. It's very proven, it has a large community of people using it. Unfortunately, WxRuby can't run a demo app without it crashing, so it fails to meet the minimum criteria.

Man 4: You can't do the what?

Kyle: You can't run the demo app for two minutes and just click around the demo app without it crashing. It's kind of an irritation for me. Someone's out there spending their time writing WxSugar to get a nicer API on top of WxRuby. The problem is not that it needs a nicer API; it's that you can't run the demo app without it crashing. I don't see the purpose in trying to making the shiny upper layer, if you can't make your underlying layers at least run, if you can't make it through the demo.

Man 2: I think that's called polishing the turf.

Kyle: Yes.

Man 2: So, do we know if it's a problem in the library, or if it's just that they didn't do much to work with the demo?

Man 1: No, it just needs more work on the demo...

Kyle: Yes, WxRuby barely runs...

Man 2: There's not enough people working on the project.

Man 1: I wonder if they should use that SWiK-type thing that Qt uses, and maybe that would solve those problems...

Man 2: They do use SWiK...

Kyle: Then they need to switch to the other one... [laughs]

Man 2: They use Swing, though. They don't use the other one. I started the WxRuby project...

Kyle: Did you?

Man 2: ...but I never did any work on it. [laughs]

Kyle: Well, probably nothing happened since then, because it looks like no one ever did.

[laughter]

Man 2: No, a lot's been going on, but the problem is that they just don't have enough people to get through it. It got started because of the same reason that FreeRIDE uses FXRuby...

Kyle: They can use it in their own...

Man 2: See, at the time we started FreeRIDE, we looked at everything that was available, and nothing met all of our requirements.

Kyle: Yes. You probably did something like this [makes snapping sound], and you found that none of them on the page went along with it. [laughs]

[xx]

Man 2: Yes, we did. We could have been big features-makers.

Kyle: Yes.

Man 2: And FXRuby came the closest; it was just missing native widgets and internationalization. We really wanted to use WxWindows, or WxWidgets now...

Kyle: Because it's really robust, right?

Man 2: Yes, but there were no Ruby bindings. So, we started the WxRuby project, found some people to work on it, and then bowed out. [laughs] And the idea was to replace FXRuby with WxRuby and FreeRIDE eventually, but it's never happened.

Kyle: There are too many toolkits for how big the Ruby community is. If you take the Ruby community, subtract the Rails community, subtract all the non-Rails web community, you subtract the people that are writing only backend server-side stuff, and you end up with the total size of the Ruby community that's writing client-side GUI apps. There are way too many different projects that their efforts are spread out among.

Man 2: Which explains the reason why there aren't enough developers on WxRuby...

Kyle: Yes. There are probably hardly any users on it, either. I can't imagine any significant users in its current state.

Man 2: Well, there can't be, because it doesn't work well enough to use.

Kyle: Yes. There are too many for the community. I think the best thing that could happen for some of these projects is for some of them to fail and stop and go away, and then maybe the users that band as refugees will build a critical mass... [laughs]

Man 2: I think they're all going to be rendered moot, because -- I agree with what you said earlier -- I think local web apps, for the most part, is the way to go.

Kyle: That's going to suck the wind out of the sails of some of the other ones...

Man 2: Yes.

Kyle: OK. The next one: We're going to talk about this, too, but with Lua instead. If you just want to plug in some Ruby, that doesn't mean you need to write your whole app in Ruby; you can have an app written in something else that you do Ruby scripting inside of. Ruby's a pretty nice little language for writing little bits of script in. You might have a Java app that uses JRuby when it's a little farther along, in Ruby scripts. You could easily write a Windows app that did that. You could write a web app, even if it wasn't written in Ruby, it could have plug points so you could plug in Ruby scripting. And there's a bunch of different approaches to that that are down in scope of what I can say in here, but it's worth considering.

I showed this last year at that Code Camp thing, which by the way, is coming up in May...

Man 3: Oh, really?

Kyle: Yes. If you've never given a talk or you don't give talks very often, it's great. It's a great place to get started, because it intentionally has a threshold that's set very low. There's a whole bunch of slots with a whole bunch of people in them, so the pressure on each person is not as high.

Man 3: Is there a site for that or something?

Kyle: STLCodeCamp.org.

Man 3: The same one from before?

Kyle: Yes. Brian's announced it in a couple different places, but I guess the word hasn't gotten out, since everybody here said, "Huh?"

Man 3: Interestingly enough, he hasn't said anything on the XP group.

Kyle: Yes, I think there was something...

Man 2: I checked in December or January, and they still had the old stuff.

Man 4: May 5th...

Kyle: He has the new stuff. It's ready. Go sign up. Go sign up and go give a talk.

Man 2: It's wonderful.

Kyle: Well, I gave a talk last year, and I used Lua, and I showed how to plug some Lua into a non-Lua client-side app. You can do the same thing with Ruby. It's a great approach.

I have a bunch of references on here. I'll probably... Under the file of my computer, I've probably added six more; these will all be links and this will all be on my website. I've already talked about the answer to the question: "So what do we do?" So, that kind of ends this material that I wanted to make sure I got through. If anybody is really interested in any of these in particular, I have some sample code for several of them that I could pull up and step through, but I don't know what time they normally end here. I don't want to go over...

So, five minutes: what's everybody want to talk about about this? What do you want to see?

Man 5: So I'll throw out, again, something I said at the last meeting: I talked a little bit about Google Web Toolkit. Since that meeting I've done a lot more work with it, and I continue to be impressed by it. And I'll say again, the worst thing about it is that you have to code in Java in order to use it, but I like it enough that I'm willing to put up with that. There's no reason why you couldn't do something similar in another, like Ruby.

Kyle: Well, there is: it's much harder to write your own compiler for Ruby than it is for Java, because it's so underspecified and such a mess in its specs.

Man 5: Right. Yes. But somebody is working on a library for Ruby that converts Ruby into Javascript, which is what you'd need to do something like Google Web Toolkit. I just think that we're going to get to a point, at least within the next 10 years, where you can write your code one way and not even think about whether this is going to the web, and then it runs either way.

Kyle: Yes.

Man 5: So, I think Google Web Toolkit is a step in that direction.

Man 2: I'd like to see WxWidgets have a web front-end. That seems to be...

Kyle: What would that mean?

Man 2: Well basically, you use something like Glade or some layout tool--they go down as far as Curses...

Kyle: There are a bunch of layout tools that work with Wx.

Man 2: Right. There might be too many; there's a bunch of them...

Kyle: I'm not sure what it would mean, though, because Google Web Toolkit is a very unusual beast. A Java to Javascript compiler is one of the core pieces of it. That's a really strange thing to do. The reason you couldn't have a Wx version of that is that the only sense in which it could be Wx is that you could write code in some language that writes to the Wx API, then you could have a compiler that converts all that to Javascript and makes it call the DOM instead...

Man 2: Right.

Kyle: There would be no actual Wx. With Google Web Toolkit, you're writing code in a kind of Swing-like API, but there's no Swing there.

Man 2: I'm probably thinking more like Glade, something that just describes the interface.

Man 5: Is that like XAML..?

Kyle: Glade, XAML, Nibs...

Man 2: To me it seems silly to...

Kyle: Well, what toolkit are you using?

Man 2: I usually use Rails for most things, and mostly hand-coded JavaScript to...

Kyle: For every one of these, there is a tool that you can use to lay out your GUIs by clicking and pointing. For some of them it's in the box, for others it's a third party thing, for others it's 30.

Man 2: It seems that Jazz needs to be aware of where the consolidation needs to happen more, because trying to describe how to lay things out instead of describing how they're laid out seems to be an issue.

Kyle: I would argue that that battle has been won by HTML and CSS.

Man 2: That's true, I guess.

Kyle: That might not be the best possible approach -- in fact, I think it's kind of ugly in many ways -- but there's so much more momentum around HTML and CSS than there is around any of these others. Among other things, it's a spec; it's a spec that a zillion people code to, and a zillion tools understand, and multiple major browsers from companies that hate each other all work with.

[laughter]

And you're not going to get that behind any new file spec for describing a user interface today.

Man 4: We don't all work together...

Kyle: I was exaggerating. [laughs]

Man 4: Right.

Man 5: Actually, it's different in IE 5.5, it's different in 6, it'll be different in 6, and Firefox...

Man 3: You have to restrict yourself.

Man 4: It's not perfect yet...

Kyle: It's way closer than anything -- let's grab one off the list -- Fox. When I was looking at Fox, I stumbled across several different tools for a little GUI layout thing to describe your Fox GUIS. And I think one of them just generated code, and another one generated a five-letter runtime. They're all different, and there's no way that any of those is going to get any traction outside their own little space in the way that HTML has. That's the way I ran with it.

Man 2: So, we need to push on richer HTML: HTML5, or WHATWG.

Kyle: I don't know what the path forward is.

Man 1: Well, the W3C kind of stopped with XML. XHTML2 is terrible, really...

Kyle: Prove that.

Man 1: Something called HTML 5.0. If you go to WHATWG.org, I guess, they've got this whole spec they've been working on for about two, three years. It's got a whole new form. It's backwards compatible, too, which XHTML2 was not.

Kyle: I saw somebody comparing HTML five and XHTML 2, and they said they're both disasters, and it could be forever before any of them gets any momentum on HTML one and after HTML four and HTML one.

Man 1: I think HTML 5, I think everyone but Microsoft is on board.

Man 1: Yes, good luck with that one. 75% percent of the browsers.

Man 2: One of the things Mark mentioned, which I think you sort of doubted, like GWT basically they compile Java to Javascript.

Kyle: Genius, I don't doubt it; I think it's wonderful.

Man 2: Yes, but you said getting a Ruby compiler would be difficult.

Kyle: Oh, yes.

Man 2: And I wonder in Ruby, because it's so much easier to create right specific languages, whether you couldn't create a specific language that is more akin to the...

Kyle: You could define a subset of Ruby that you could compile into Javascript.

Man 3: Which is what VW2 did.

Kyle: It's a subset of Java, yeah.

Man 2: They have their own widgets and, you know, different components. You have to use their AP op.

Kyle: Yes, that's right, you can't. You can try to extension a Java sling button, but there is no Java sling button.

Man 3: Right.

Kyle: I don't how much trouble Google is having getting buy-in for VWT. I having a feeling they're doing pretty good with it. I have a feeling it would be much harder to get buy-in if they had said, not "We're going to subset Java," but "We're going to subset Ruby." I think Ruby is already a small enough community, that saying, "Now we're going to take a subset, we're going to subset that language with our own language," people would be upset.

With what they're doing, people are saying, "Wow! I can write Java code or I can hire hire people that know Java, and this works." They'd be saying, "You mean I have to learn a subset of a language I don't even really..."

Man 2: I'm not saying that Google should have used Ruby. I'm saying that if you want to do something like that, with Ruby, it's probably easier than it would have been to do it with Java because of the richness of Ruby compared to the richness of Java.

Man 4: And also, it might not be-

Kyle: No, I think that is wrong because the richness and complexity of the language is really cool if you're a programmer, but it's not very cool if you're a language implementer, which is what you need to be to write...

Man 2: I don't think it would be done as a general purpose Ruby. I think it would be done as a DSL of sorts. And I think the way that it would happen, and I actually think it might happen, because I think to their-

Man 4: Start the process.

Man 2: I think somebody will do a Rails plug-in, so that you don't have to write HTML, or HTML templates, anymore and write custom Javascript. You'd have this little language that's based on a Ruby DSL, and that you do it all in Ruby, all on the server-side. It gets compiled for you, and the display is generated, the bindings are generated, everything just works.

Man 3: Isn't that kind of what Hamel's trying to do?

Man 2: Yes, Hamel's already trying to do that.

Kyle: Well, I'm done with my allotted time. We can keep talking, but it's not my fault if we go late on this.

[applause]