Ask YC: Best solution for offline access to a webapp? | Hacker News Reader

Ask YC: Best solution for offline access to a webapp?

3 pointsinklesspen6 comments

Our company is developing a rewrite of our flagship app, which has historically been a Windows product, as a web app written in Ruby on Rails. So far it's gone moderately well; our complaints lie mostly with ActiveRecord (so bloody limited) and the lack of documentation of how to write good tests for complex models.

However, it turns out that our webapp also needs to be usable when the customer has no internet access. (Perhaps this should have been taken into account when the CEO decided to do the webapp idea, but we're pretty well invested into this approach now.) About 25% of our potential customer base would require this; another 25% would like to use it but do not require it. We sell access to our app as software-as-a-service to health-care agencies, so if they need to have offline functionality, they need to have it; it's not just a preference.

These are the alternatives I and a few others have come up with, but I'm hoping some YCers might have some advice.

* Google Gears: Seems to require substantial rewrites to our app.

* iPhone version of our webapp: our customers don't have much money to buy iPhones and service plans. also, some of our customers need to do work with the app in places where there is no cell phone service, let alone wi-fi.

* Joyent Slingshot: The basic architecture (local install of Rails, with some extra code to transfer data between the local install and the webapp) seems sound, but Joyent seems to have abandoned Slingshot halfway through rewriting it. If we go with this approach, we'd probably implement our own version rather than struggle with Joyent's unsupported code.

* Slingshot-esque with eee: Provide a custom install for the ASUS eeePC that launches the user directly into our app, with Slingshot-like methods for transferring data between the eee and the webapp.

* Slingshot-esque with VMWare: Same as above, only we provide a vmware image instead of an eee install.

Sorry, I don't have an answer; but I do have a question :) Why rewrite the thing in the first place? It's not too late to trash the Ruby on Rails project and focus your effort on improving your current asset (the Windows app).

By my understanding, the Windows app is written in an obsolete language and is requiring more and more heroic efforts to just keep it working -- sort of a Red Queen effect. We could certainly scrap it and rewrite in .NET, but our past experiences with .NET have been less than positive. In addition, we're pretty far from a startup hub; even though we're not a startup, this is a problem, because we want to find expert hackers, not just average .NET programmers. So in that respect, Ruby on Rails is good for us because the few Rails programmers we do find are better than nearly all the .NET programmers we would find, and there's fewer resumes and interviews to go through.

If it requires more and more heroic efforts to just keep it working, it probably means that your organization can't manage a software project; either because your developers are not experienced or, more likely, because management doesn't understand software development (you're not alone; few companies truly master software development). Hence, it's probably not a language problem and switching to Ruby on Rails won't solve it in the long run.

This is probably the case, yeah, but I don't have the leverage to get this changed. I'm leaving the company myself in in about five months.

I hate to mod this up, but, darn it, I have to mod this up.

Web apps have pros and cons. Desktop apps have pros and cons. Desktop apps written with web-app technologies have... cons. The interface is limited to what the browser can support. There are more moving parts. You have to worry about synchronizing the data. You have to worry about pushing out upgrades. You have the same support costs as any Windows desktop app, and worse, because you're supporting a system that nobody else has ever seen because you wrote it yourself. Etc. Etc.

Of all your ideas, the Asus-eee one seems the best -- just make the customers buy hardware with the software preinstalled. If they screw it up, have them mail it in for a new one. If the eee gets discontinued, find another small OEM Linux PC and port the software over. If you go the vmware route you might as well be selling and supporting an installable Windows app, which you already are.

But the idea is still crazy. Customers are not stupid. They know the difference between a full-featured Windows app and a web app that has been crippled by cutting off the Web part. You're going to throw away all the advantages of moving to webapps in the first place, and invest mighty engineering effort, all to replace a Windows program with a program that (from the non-networked customer's perspective) does the same thing but with a different, feature-poor browser-based interface. That non-networked 25% of your user base is likely to respond by either (a) demanding that you continue to support the Windows version; (b) switching to a competitor's Windows- or Mac- or Linux-based product; or (c) buying some networking, and joining the other 75% of the customers. Once that process has shaken down, you'll be left holding an expensive, tricky Slingshot-esque technology that has almost no users.

"Buying some networking"? I admit I wasn't exactly clear with what the app does, but in the iPhone section I did say the app has to be used in places where there's no cell phone service, let alone wifi.

It's an app used by public health agencies, who _have_ to be able to visit clients in their homes and chart their progress. And plenty of homes in the rural US have no dial-up internet, no broadband, no wi-fi, and no cell-phone coverage, and no sign of that changing soon.

That said, I agree with you. The decision-maker at this company doesn't, and as I mentioned below, I've got little leverage to change things.

Reply on news.ycombinator.com