Making the move...

[Richard Gaskin]

Dan Shafer wrote:

 > On 3/14/06, Richard Gaskin <ambassador at fourthworld.com> wrote:
 >
 >> But if the goal is to deliver the benefits of productive,
 >> flexible systems, Transcript can prove quite capable in
 >> ways that may surprise.
 >
 > Richard.....
 >
 > I *certainly* don't disagree with your response, but I'm earnestly
 > seeking a description of how you'd go about building an app in Rev
 > that is entirely deliverable via a Web browser, which is, I submit,
 > the definition of a Web application. I think that was the original
 > point/question. Creating thin-client Web appliances is amazingly
 > easy with Rev. Creating CGIs that run on a server -- including
 > back-end database access -- is also feasible, if somewhat limited
 > in terms of performance (no FCGI support as far as I know).
 >
 > If this is possible, I'd sure like to know how to do it.

A "web application" has at least a web-based interface, and often also 
has a server-side component to it.

There are three viable methods of making an interactive interface in a 
web browser:

a) Java
b) Flash
c) DHTL (recently re-christened "Ajax")

Rev doesn't produce Java or Flash output, so if those are desired you 
would indeed have to go to another tool.

But neither does Ruby.

Nor is Ruby embedded in web browsers.

Web browsers have only one universal language at this time:  JavaScript, 
which is the heart of DHTML/Ajax.

JavaScript is plain uncompiled ASCII text.  It can be 
generated/assembled/sliced/diced by a Rev-based CGI just as assuredly as 
any other language, such as Ruby, can do so.

Rev's merge function is enormously powerful, as are its chunk 
expressions and file handling.  Smartly-designed snippets of JavaScript 
and HTML can be combined and recombined quickly and easily with Transcript.

As for performance, most CGIs are loaded when called.  The exception is 
FastCGI, employing a stay-resident option to minimize load times.  Many 
ISPs preconfigure their Perl installations to use FastCGI, and FastCGI 
is the recommended interface when you install and set up Ruby.  It may 
be possible to use FastCGI with Rev; I'll leave it to the server experts 
here to fill us in on that.

When run as a CGI, the Rev engine loads _much_ faster than it does on 
the desktop, which is pretty darn fast as it is.  As a CGI it doesn't 
need to initialize any of its GUI elements, so the load time on a decent 
server should be roughly on par with any other engine of equivalent size.

It would be helpful is someone here has performance benchmarks on Rev as 
a CGI relative to Perl, Python, Ruby, and other server-side languages.

If FastCGI cannot be used with the Rev engine, then indeed we can expect 
a performance disparity between the Rev engine and the Ruby engine.  But 
"impossible"?  I don't see how.

One of the main bullet points for developing in RoR is the MVC 
implementation, but again that's not exactly new.  Smalltalk had MVC, 
and there are implementations in most OOPs and many non-OOPs as well, 
including a few done in Rev to varying degrees.  While the Rev ones have 
focused on native controls for triggers, one would have to write 
JavaScript triggers for web-based UIs, as they would with any 
browser-based implementation.

Ruby is a fine language, and the "on Rails" framework is well thought 
out and very useful.  But it's not magic; Ruby is just a language, its 
"Rails" just a framework, and I've seen nothing in it that couldn't also 
be done with Perl, Python, Rev, or any other CGI.  There may be 
tradeoffs with runtime performance and development productivity, but I 
see nothing which would discount all web applications as "impossible" to 
do in Rev.


And as you note, Rev does one thing Ruby can't:  compliment the range of 
deliverables with a net-savvy desktop app (think maps.google vs Google 
Earth).  While only useful in a subset of scenarios, it offers many 
benefits, esp. for intranets where employers are losing billions in lost 
productivity by providing open web access to their employees when all 
they really need is access to specific company- and vendor-specific 
resources.  Rev-based net-savvy apps (or "net apps", or "net 
appliances", or "thick clients", or whatever else one might call them) 
are like VPNs for the rest of us.  And, as with Google Earth, there are 
UI benefits to such desktop implementations as well.


All that said, there are two benefits to Ruby:  most of the code you'd 
need is already written, and as open source it's all freely available.

But while Ruby may have some advantages, that doesn't make using other 
languages to generate DHTML interfaces impossible.


Taking this a step further, I'll close with an exercise for the reader:

1. Make a web app development tool in Rev for laying out and generating 
DHTML controls for web pages.

2. Now make the same tool in Ruby.

  ;)

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