Rev vs. AJAX...Or Web-Aware Apps vs. Web Apps

[Richard Gaskin]

For myself, I don't see this as a "vs" as much as an "also".

When I need to put an app inside of a browser window, I use whatever the 
project requires to do that, and old-school tech like AJAX often gets 
the job done well.

But for everything that lives outside of a browser window, for me it's 
all Rev, all the time.


As for the "sole source" question, in practical terms I wonder if 
language choice is really so big a factor.

Replacing a critical team member is always expensive to any substantial 
project, regardless of the language it's written in.  Code is 
disposable, replaceable, and much of it probably should be every few 
major versions.  But knowledge and rapport -- that's where the 
investment is, and that's always going to be expensive to replace.

In this industry it's really easy to fall into a gadget-centric view, 
focusing on compilers, languages, tools, and such.  But in the big 
picture, maybe the computer industry isn't that much different from any 
other.  The business of business is driven by human creativity.

If one's code is well structured and well factored, the underlying logic 
can almost always be ported to another language profitably.  Ask Chipp 
about the BASIC project he recently rewrote in Rev -- as I understand it 
they saved quite a bit making that upgrade, even though it meant also 
rewriting the app from the ground up.

For going the other way, Transcript is readable enough to almost any 
programmer.  And with Rev's growing base, there are plenty of 
consultants available who can help orient a rewrite team if needed.

So with all that in mind, maybe the real business question here is:  Is 
it worth ditching immediate ROI benefits for the possibility of maybe 
saving some time at a potential future date if a worst-case scenario 
happens?

All business decisions carry risk.  I'm not sure how many successful 
businesses got where they are by raising current costs in an attempt to 
approach zero risk for the smaller expenses associated with possible 
future misfortune.

Or to look at it another way:

If the client's goal is to migrate to commodity languages to use 
commodity labor, why wait until the programmer's dead?  If the work is 
the sort that can be commoditized, the client could do well to avoid 
paying US costs altogether and hire someone overseas today.

The languages we bring to the table can always be replaced.  But can our 
experience/talents/creativity?

That's only true if all we bring to the table is merely functional code 
that does only what was asked for.

Clement Mok doesn't sell pixels, nor Frank Gehry ink. :)

--
  Richard Gaskin
  Managing Editor, revJournal
  _______________________________________________________
  Rev tips, tutorials and more: http://www.revJournal.com