Slingshot Apologia: We Didn’t Design Slingshot for Planes
David Heinemeier Hansson recently opined that offline web applications ”[are] getting an undue amount of attention. Which is bizarre when you look at how availability of connectivity is ever increasing.” I’ll leave David to his opinions, and others, who believe that connectivity is not so pervasive, or ever will be, to theirs.
I believe an “offline” framework for web applications is interesting, especially when considering a much broader design horizon. We designed Slingshot to do so much more than just provide access to data on a plane.
First, we wanted to enable rich internet applications to be full peers of desktop software. When a developer spends the few hours to extend his application to work with Slingshot, the application can now receive drag events, and data can be dragged out of an application running in Slingshot. The web application is no longer a silo, but a full participant in a very rich, and mature, stack of software running on the client computer. Imagine how Slingshot could be extended in the future to include SIP clients and other desktoppy components allowing an application in Slingshot to do more.
Second, Slingshot removes the latency of the internet. Even when connected to the network, Slingshot manages data locally and then pushes the changes up to the server. Slingshot is aware of native OS connectivity and transitions between online and offline modes automatically.
Third, Slingshot allows developers to distribute processing to the edge of the network. Since the code runs locally, and Slingshot proxies the interactions with the “home” server, theoretically a developer can offload processing to the local device. Let’s use the dual-core laptops that are increasingly consuming our web applications.
Fourth, Slingshot is a server. It can be used to provide offline/intermittent access for a group of people. This is an extension of moving data and processing to the edge of the network. Declare synchronization is to happen for more than one person, maybe a whole office, and those people point their browsers to the copy of the application running on Slingshot on the local LAN.
Finally, if developers can use Rails to effectively develop applications that look and act like native desktop applications, we can begin to think about human interface guidelines that bring application design backing to the boring, and useful, world of common controls, buttons, sliders, windows, panes, etc. Today we live in a DOS world where every web application is different from the next.
We’ve been overwhelmed with the positive response to the Slingshot announcement. A number of great Rails applications are taking advantage of the early adopter program, and we’re porting Radiant to Slingshot as the example application that will ship with the Slingshot developer kit.
Update: here’s another reason why both running your application at the edge of the network and avoiding browsers (a slingshot’ed application is inherently single origin) makes sense.
26 Responses
Sorry. I happen to agree with DHH on this.
On a mac there’s another big issue to contend with. It’s that mac users want their applications to look and feel like mac applications. You’re merely providing a very inconsistent interface in respect to their current applications they’re running “natively” on their own machine.
Mac users aren’t happy with just “ports” of software. No, they want applications that look and behave like mac applications. Connector does not do that.
Still my opinion is moot, but I think Slingshot as an app will fail. You have some hype behind you right now, but it’s not going to last.
Fact of the matter is that each individual web app isn’t always going to “port” right over to a desktop application the same way another does. The best you can do with Slingshot is bring that web application into it’s own window that syncs back and forth. Sorry, but that’s kinda lame. The idea that I could turn my information in “Lists” into something like OmniOutliner is much more appealing to me. A desktop application that makes a webapp EASIER to use and more accessible.
Slingshot is merely a “hack” that fails to really do anything useful for the user in terms of usability.
The reason an API is needed is because it ALLOWS people like me to create applications that look and feel and act like real applications. That both work online and offline. Ultimately that will still provide the best experience for users. You can argue all day long that it is “bridging” the desktop and the web. But there’s a lot more to it than that.
I agree with the notion that “offline web frameworks” are interesting. It’s great to see things like Slingshot, Apollo, Flex, etc. trying to address these problems in different ways. There are a slew of issues with moving a web app to the desktop (offline or not) and I’m curious to see what you guys have got up your sleeves.
I do have a question, though, about using Rails to “develop applications that look and act like native desktop applications.” Will Slingshot have some magic way of providing developers with access to native GUI controls like sliders, tab controls, etc? That’s the part that would be the most interesting (and dare I say it, revolutionary).
Everything else I’ve read, though, seems to indicate that Slingshot is basically a self contained Rails environment with a native browser control on top. Handy for sure, but if all we’re talking about is using HTML to develop desktop applications – I fail to see how that will change the way we think about HCI for web applications. If anything, it just means the same reimplementation of native controls in HTML/CSS that is already done in a regular web app.
@Matt: you’re right. I didn’t mean to indicate that Slingshot allowed access to native GUI controls. But if people use Rails+Slingshot to create desktop applications, that may be some incentive to standardizing the controls.
I’m also not so hot on the ‘offline’ aspects of Slingshot, but very hot on the ‘desktop integration’ aspects. Don’t mind that the offline comes with it; but desktop integration is the killer feature here.
The ‘offline’ aspects I feel are what is most attractive about Slingshot and other frameworks. If you read the comments on the 37signals post – you’ll read the same sentiment. A great number of people need ‘data’ when they are no where near internet connectivity. OS agnostic solution is also a great aspect. I think the desktop integration certainly adds flare and is a separator – but ‘data all the time’ is king.
Does anyone else think DHH has yet AGAIN over reacted to someone else creating interesting and innovative technology.
Of all things, 37signals would greatly benefits if Slingshot was used with their newly released Highrise CRM application.
My opinion, DHH is an idiot. I say that with all due respect of course.
By the way, why entitle the post “Slingshot Apologia”?
What is there to apologize about? You guys developed a kick-ass technology that can benefit many.
I assume the title is to appease the gods at 37signals, which is unfornuate. You shouldn’t have to apologize for great technology to anyone.
David, Thanks for posting these thoughts. I tend to agree with you. The real power is the ability to interact with other applications on the desktop and get over the bandwidth issues.
Also, you mention an ‘early adopter program’. How does one go about getting access to that?
@Nick: “apologia” simply means a defense of. see http://en.wikipedia.org/wiki/Apologia
I have a couple questions….
From what you’re saying in this post Slingshot will not only be a Server side application, but will also be a local client application. So will users be required to download a “virtual player” like the Flash player or will Slingshot just be bundled with the developer’s application? If it’s not going to be bundled with the application how will handle user adoption to facillitate high number downloads? I mean, you’re marketing Slingshot as a way to sync data natively in the OS, not as a media application like Flash so really the only people that will know or want to use Sligshot will be developers that are interested in utilizing Rails and Ruby as a development platform. So again how will you spark general public interest in Slingshot (if it isn’t bundled with the developers application) or will you leave to the devs to detail its use in their application?
@Steve: send email detailing the application you’d like to get running to slingshot [at] joyent [dot] com.
@Frank: it’s bundled. A developer “pours” their Rails application into Slingshot.
One issue which I haven’t seen discussed yet is how people will handle licensing once client-side distribution of code becomes a potential part of their webapp stack. While Ruby and Rails are more or less compatible with traditional, closed-source distribution, many libraries and plug-ins are licensed under the GPL or LGPL.
Traditionally, web developers have had a sort of “free pass” w.r.t. GPL-compliance issues, since they technically didn’t distribute their code to end users, and therefore didn’t have to make sources available to them. Once you start pushing code out to client sites, though, you’re obligated to clear all those licenses, and make sure you’re not tying closed-source and GPL code into the same application or runtime.
David, I assume you guys have dealt with this already in your own apps? Have you been forced to rewrite or port pieces that depended on GPL or LGPL code?
Regardless, I offer you guys kudos on what appears to be a pretty sweet hack. Since I mostly hack on Ruby projects in my free time, I can’t imagine I’ll have much occasion to use it, but that doesn’t stop me from recognizing a nice piece of kit.
@Lennon: we side step the issue since the GPL’d and LGPL’d code isn’t necessarily incorporated into the Ruby code from the developer using Slingshot. A developer would need to include the licenses for the GPL’d or LGPL’d code (and other open source licenses, as required) in the distribution of the version of the application running on Slingshot.
I think it’s great that people are experimenting with new ways to put Rails to use. What I was commenting on at the 37s blog was the euphoria that this would be a “game changer”, as quite a few journos have put it. I don’t believe that it will.
Doesn’t mean there’s no use of it. Doesn’t mean that what Joyent or Adobe or Mozilla or Microsoft or any of the other teams working to make offline apps easier are completely wasting their time.
I just don’t think most of the people will care for most of the work they do. That’s always been the target I’ve been aiming for. Doesn’t make it wrong to aim for something else. And it doesn’t mean that I couldn’t be totally wrong on this either and people will flock to offline capable apps. I’m just putting my public bet on the fact that it won’t play out like that. In other words, I think this is a “push technology”, not an “ajax” one.
What I do find interesting is the intense heat around this discussion. I’m no stranger to being called an idiot. Lots of people did (and do) call me that for the work on Rails. As well as the 37signals applications.
But I probably wouldn’t have guessed that this subject could rack up there. That’s okay, though. If you feel better calling me an idiot rather than just saying “I have a different opinion on that”, I can live with that.
@DHH
“What I do find interesting is the intense heat around this discussion.”
The reason why it’s getting such heated discussion is because you dropped the F*** bomb in the title of your 37signals post.
When you have an abrasive title like the title you have on your post, it’s bound to cause discussion.
Serious, just read the headline: “You’re not on a f***ing plane (and if you are, it doesn’t matter)! ”
Exclamation mark, strong profanity and the likes will nearly always get heated discussion.
@DHH:
1 Samuel 17:49-50
The giant was felled by a slingshot.
> But I probably wouldn’t have guessed that this subject could rack up there.
You’re kidding, right? You told people that they were wrong for having offline requirements, that their requirements didn’t matter, and that anybody who couldn’t get connected was in a “dark hole”. And to top it all off, you swore at them while doing it.
If you seriously didn’t guess that would offend people, then you truly do deserve to be called an idiot. But truth be told, I think you did expect this reaction because you couldn’t have been more inflammatory if you’d tried. So idiot or troll; either causes any respect I had for you to plummet.
Thanks so much for posting a solid intelligent response! I’m really surprised at the cluelessness of DHH. I think their success is going to their heads. It’s a shame since they’ve created some great stuff in the past. But oh well, when you are young and prideful and haven’t seen much failure in life that can happen. Keep up the good work! Fortunately, this whole episode can only help you guys
Just for the sake of using web applications like desktop applications it is all worth developing such frameworks. I see a few advantages in online applications with an offline component. One of the most promising is more control over the interaction between the application and the user, the other is offloading the network. There is probably a lot of javascript code that does not need to be on the server, but can work a lot better on my machine.
But about interaction. I would love to use a ‘markdown’-like way of typing in a textarea that instantly transfers things to styled text, essentially like Word does.
I don’t know if this is a “game changer”, but I can see very practical situations (other than in planes) where this could be implemented for businesses that use their externally hosted web app for day-to-day operations.
Personally I have a few app ideas that need exactly this to be successful. So I’m anxiously awaiting a release.
To everybody getting all riled up about DHH, have you been around the Rails community for long? DHH’s “style” is a little abrasive, but it’s also a significant reason why everybody in the world has heard of Ruby on Rails now. Take it as a marketing tactic and not an attack.
Yes, as much as i like David and the rest of 37s (which i know personally), i am tempted to declare him as “Jackass of the week” because of his post about offline Apps.
That post showed a level of narrow mindedness (is that even an english word?) which one doesn’t usualy expect from 37s.
In fact his post realy makes sense in parts with an additional tidbit which David only revealed in the comments which was, that their target Market is American Office Workers only. That in mind explains why he is simply ignoring the majority of underconnected countries on this planet. It does not explain however, why he would not want to see all the other benefits of an offline WebApp.
Simple Example: try to upload a 250MB File via HTTP. It will block your whole web-app to the everage user (which didn’t open an additional browser session prior to the upload) for quite some time. Now with an offline app, you drag and drop the file and forget about it while the upload will happen behind the curtains. Then, as you said there’s all kinds of integration possibilities…
Here are a couple othere areas where offline access not only makes sense, but is essential. Field Sales Force applications. I worked on a couple projects where it was absolutely necessary for the sales staff (one project) and consulting staff (another project) to be able to have the most recent sync’d information while they were at client sites.
When the sales staff are on the road, they don’t have access to wifi most of the time and network access may or may not be there given the client size etc. If they had to login to get the most latest inventory figures or orders data, the delays could be costly and affect the business..
Similarly, most consultants need to enter time data locally and then upload it later on. The level of detail and itemization that some consulting companies use is quite intricate. Think for example a law firm or an accounting firm. The consultant can charge up to multiples of hundreds of dollars an hour and the clients expect a detailed breakdown of their activities. Meanwhile, the head-office wants latest figures compiled every night so they can do their revenue forecasts on almost a daily basis. This requires data being uploaded to the central servers.
The potential number of consultants offsite for large organizations can easily reach into tens of thousands. So it is not a couple of web developers entering their daily time (if we were to continue the simplistic line of thought of only needing to have online access when you’re on a plane for example)
Your application will give the best of both worlds to people with needs such as these, i.e., access through the web whenever possible and offline access to critical data when needed.
Access on the planes is really a red herring, there is real need out there for hybrid access. So kudos to you, keep on trukin’ , and you have a bright future ahead of you.
Its amusing to me to see so much time, effort, and energy being spent on things that Lotus Notes did, what, a good decade or more ago?
Not to take sides, but DHH was probably playing off the Snakes on a Plane meme.
Me? I’d love to have access to my web stuff while on a plane. (And on a train! And in a tree! And in a car! Sam! Let me be!)
I’m late to the party here, but here goes:
I think DHH has accomplished enough to definitively fall into the ‘not-idiot’ category. Or, if he is an idiot, I could use some more idiocy in my life.
That said, I think his thinking on this matter is so bad it’s not even wrong (I love that quote).
Anyway, maybe I’m a niche guy, but hybrid web/desktop applications are my holy grail.
I am not a salesman (worse- mgmt consultant!), but I do fly a lot (more than I’d like, that’s for sure) and do a lot or work on planes! Applications that are online-only are a real problem. For example, for my personal email I use Gmail, but I use Thunderbird and POP as my offline backup- works fine, but it’s not exactly an elegant solution.
Web applications are great because it makes things like collaboration a lot easier, and it makes deployment and upgrades a lot quicker. But web applications have usability issues; latency is just the start (and it’s still a big one for most users!). Desktop applications have largely orthogonal strengths and weaknesses, and thus are largely complementary.
Here’s an example- I have a sweet web application (let’s pretend) that my corporate clients with their locked-down desktops can access. Totally sweet. But their use of the site is fairly low-bandwidth and not latency-constrained; they are mainly viewing and commenting on the results of all sorts of backend data analyses.
But us working behind the scenes need a lot more responsive interface to get those analyses fed and running. Simply put, our requirements exceed what is currently available via a web application, and what will be available for the foreseeable future. Bottom line: We need a local application.
And it sure would be nice to have a common platform for all of this…
Sure, synching has been solved before (I shudder to say this, but Outlook is even pretty good in this department), but not with the flexibility and low entry cost of RoR. If I’m GM, maybe I stick with Notes, but us small shops sure like open standards & open source.
Speaking of which, it’d be great if you could figure out a way to profit from making Slingshot open source…
Подарочные флешки от 1 до 8Гб оригинальные. Таких нет в магазинах! Хороший подарочек на новый
год или любое мероприятие.
Флешки с Вашим логотипом, флешки подарочные, сувенирные, ювелирные. Самый большой
выбор флешек в России и наверно в мире. Сайт о флешках. Прямые поставки из китая.
http://www.cool-usb.ru
Наши телефоны : +7-495-642-97-46, 604-41-67, 952-68-43, 504-60-26
ICQ: 146-718-140