On 30 Jun 2009, at 00:23, Rick Praetzel wrote:
I am on the other side of it.
I find web apps to be unsightly, slow, and awkward because they run
in a browser which is unsightly, slow, and awkward.
So I write apps that run over the internet as desktop applications.
Not necessarily.
Breaking down your arguments:
- Need to write for at least three browsers: this is really not so
much of an issue as most ppl make it. Internet Exploder is about the
only browser that can possibly hold you back and even there Javascript
frameworks and a bit of CSS knowledge can easily resolve those things
- Unsightly and awkward: if you hire a good designer (or have one
inhouse), a web application can in fact feel more natural than a
desktop app. Even a desktop app takes a lot of GUI design in order to
feel right on every platform. If you want to adhere to the UI
guidelines such as button placement, you'll have to jump through hoops
to get them both right on Windows and MacOS X at the same time. The
only excuse you really have for not doing so is that most Windows
applications don't follow the guidelines anyway. Also a web interface
will have a more consistent look and feel across platforms. We also
have drag-and-drop and all those little bells and whistles that used
to belong to desktop apps and they are fairly easy to implement.
- Slow: I totally disagree on that one, especially if you have a very
data-intensive application. Our Javascript (and AJAX) heavy
application in fact perform better than a rich desktop app that
communicates directly with a remote database (i.e. one that is
accessed over the internet), even on older computers. On the local
network, our web apps are screaming fast. Add to that that a powerful
server can serve so many requests per second that a multi-user app
greatly benefits from having all processing server based. I'll even go
as far as saying web apps perform extremely well on older hardware,
better than a REALbasic app will ever do. I'm sorry to tell you, but
database communication, even when compressed, is in general a lot more
verbose than serving HTML views
That said, switching from desktop app development to web development
is a big leap and requires a totally different mindset. If you want to
stick to pure browser built-in features (excluding flash based
solutions like Flex apps), it requires you to learn at least three
different syntaxes: (X)HTML, Javascript and your serverside language
(in our case Ruby, with Rails as the framework). It takes time and
effort to get comfortable with them.
When we switched from desktop apps to web apps a few years ago, we had
the same concerns as you have. However, looking back now, it was the
best decision we ever made for our business and our way of deploying
apps (rapid release cycle). Some things that played out a lot better
for us:
- License management and piracy: since we have total control of the
server and our customer is paying for a hosted solution, we don't have
to worry about our app security being circumvented. It works a lot
better than internet activation (which seems to be just as easy to
work around these days) and gives us one centralized management point
- Pricing: we have been able to cut our software prices by half or
more in most cases due to a number of reasons: server cost is divided
over all customers, use of open source software and databases
- Bug fixes and upgrades: since the end user never needs to download
the new version, quick deploys of bug fixes are less of a hastle for
us than they used to be. Add to all of this that the number of bugs we
actually have in the application are far less than they used to be in
REALbasic due to being able to rspec (unit/functional/integration
testing) our whole app. I'm not saying you can't write your own
testing framework in REALbasic, but when we did it back in the days,
we never got it up to the standard we're used to right now. Overall
our customer satisfaction has gone up significantly, which brings me
to...
- Less support: right now we have about 5 times the number of
customers we used to have, yet our support load has been slashed.
Common causes:
- no more application crash related tickets: those took us a lot
of time to track down, since we couldn't reproduce most of them on our
own test systems. Our customers used to run a variety of operating
systems: Windows 2000, Windows XP, MacOS 10.2, MacOS 10.3, MacOS 10.4
(and if we continued, Leopard would also have come into the picture),
some Linux variants. On top of that, the background processes run on
those computers sometimes caused the crashes (virus scanners, spyware
scanners, other utility apps). I literally had 5 different virtual
machines on my hard drive to be able to test properly. In my opinion,
this is a lot worse than supporting three browsers and it's a lot
easier to ask a customer to install a new version of Firefox/Safari
than it is to force him/her to upgrade his operating system or even
buy a new computer.
- better error reporting from within the app itself: the
automated stack trace we are sent from our web apps (when an exception
is raised) is a lot more informative than what you can report through
REALbasic (if the error is actually caused by a mistake in the code).
We rarely have to ask a customer for reproducable steps to determine
the error.
- faster upgrades and fixes: I can honestly tell you it usually
takes us no time whatsoever to deploy new versions. Our next major
upgrade (new features etc) is done in a separate git branch, so we can
fix small bugs in the master branch. If needed, I write a simple new
test to cover the issue. Then we just run the complete test suite to
check if nothing else broke, and then it's a matter of typing "cap
deploy" and 10 seconds later everyone has the updated version (without
anyone ever noticing a new version was released).
- Mobile accessibility: all of our apps run out of the box in Safari
on the iPhone for example, no need to write yet another app. Even so,
we do provide an iPhone optimized version of some of our apps if
there's a need for it, but it takes us almost no time add that feature.
- REST-based API out-of-the-box: this is more related to the framework
we use, but we can give a third party a fully functional API in no
time using a REST-based interface and we still have complete control
as to what is actually exposed.
- Offline access: this was our main concern, but it turned out to be a
non-issue. Our customers only want very limited offline access to the
app and Google Gears and now HTML5 fitted right in there. But to be
honest, both wired and wireless internet access coverage is so
widespread that we rarely have the need for it.
All in all, for our business segment (database driven CRM/ERP apps),
web apps were definitely the way to go. I'm not saying desktop apps
don't have their place, I can't imagine a Photoshop or Final Cut clone
anytime soon. The web has evolved a lot over the last couple of years
and the boundaries that once ruled out a web app are quickly fading
away. But of course there are a lot of web apps out there that still
give the impression that web apps are dumb, unresponsive and inferior.
Best regards
Peter De Berdt
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>
|