Rails - Feb 2006 - RoR vs JavaScript/AJAX vs Java interface. Conflicting ideas?

Hi,

Over the past month I''ve been playing with some ideas for an admin
interface for a ecommerce app.

1) Old-fashioned, forms-based, full-page-refresh, server-focused interface

2) Modern, JavaScript-Drag-Drop, AJAX, client-focused, Web2.0 interface

The more I work on the second option with JavaScript an AJAX the more
I feel like I''m moving away from building a server side application
that takes advantage of all the great things that Rails provides
developers for the interface: all those nice simple rhtml templates,
easy form validation error messages, etc.  I feel like I''m developing
a client JavaScript application that talks to the server Rails app.
That''s fine and sounds ok but is it really the best option? Right now
I''m convinced I want to use Rails for the server side but is
JavaScript the best option for the client side? More requirements
could be placed on the computer where the admin interface is used than
the storefront for shoppers.

I''ve been reading about Java Web Start applications. It might be
easier to build a big admin application with Java given all the mature
GUI libraries that exist for Java compared to those that exist for
JavaScript. And this would save some server time and make a snappy
interface for the admin user.

Could Rails be easily used to talk with a client Java application?

Am I crazy?

Thanks,
Peter

> Could Rails be easily used to talk with a client Java application?
A Java Web Start client application using SOAP web services to
comunicate with Rails server app?

> Am I crazy?
>
"Yes."

>
>
> I''ve been reading about Java Web Start applications. It might be
> easier to build a big admin application with Java given all the mature
> GUI libraries that exist for Java compared to those that exist for
> JavaScript. And this would save some server time and make a snappy
> interface for the admin user.
>
> Could Rails be easily used to talk with a client Java application?
>
> Am I crazy?
>
> Thanks,
> Peter
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>

I know how you feel, Peter.  There is a huge impedence mismatch in web
development as soon as you start to try to take advantage of the environment
that you are working in.

You have to know, on the server side SQL (if you want to do anything more
advanced than your ORM is allowing) and Ruby and the Rails framework.

Then, on the client side, you have to worry about html, javascript, css,
etc.  There are no good solutions for debugging through the entire stack,
say from a javascript click event, through the XmlHttpRequest onto the
server rails logic, into the, say, stored procedure, and all the way back
down the stack to the html client.

On top of all of that, you are giving up a lot of the benefits of the
powerful desktops we have.

In five years, when we have 8 CPUs and, perhaps, two terabytes of hard drive
space on a CPU, is all of that power really being used usefully inside of a
browser interface?

After working on web apps for almost a decade, it really is a joy to be
working on desktop apps that interface with servers via web services.


Robert
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://wrath.rubyonrails.org/pipermail/rails/attachments/20060218/412a706e/attachment-0001.html

If you need to go for Java-Webstart, you should have very very strong reasons
for this.  Usually you are much better of if you can avoid it.  Try to do
your app with HTML and very little JavaScript.  If that''s not enough,
use
more JavaScript.  If that''s not enough, consider Ajax.  If
that''s really
not enough, consider Flash.  Try to avoid Java on the client side.

If you build a public web-application that is to be used by 100 or more
clients around the web, that are not under your control, do not go for Java
Webstart.
It is really a pain to get it running on a messed up Windows-98-box with
Internet-Explorer, some mess in the registry and some mess in the DLLs already
around.  With a couple of clients you can do it on the phone and visit
the most difficult ones personally.  But **unfortunately** the policy of
a software vending company to disable java on the client has pretty much
succeeded.  So don''t fight the wind mills.

So let''s assume you install the Java-Webstart application for the
intranet
and you have some control over the Client-machines, to make sure they have
the right java-stuff installed and working.

Now the next issue comes into the picture.  Developing with Java-Swing is
quite a pain.  It is very powerful, very general and very strong.  But you
have to do a lot of work to get it going.  Usually it''s not worth it.
Unless you need it, which is sometimes the case.

And now, if you are interfacing java with java, it still does not work
too well, but the communication is more powerful than communition between
java and ruby.  So with ruby on the server, it makes even less sense.

I have some hope that Ruby/Tk, Ruby/Gtk, RubyFX or Ruby/Qt will be able
to provide a good cross platform GUI-development toolset in the long run,
to replace JavaSwing.  That could be great.  Java is not good for applets
or GUI-Applications, it is more for server side development.  But you
can still rely on Java, if you want to have cross-platform GUIs, at a
price.

Best regards

Karl

>
>
> I have some hope that Ruby/Tk, Ruby/Gtk, RubyFX or Ruby/Qt will be able
> to provide a good cross platform GUI-development toolset in the long run,
> to replace JavaSwing.  That could be great.  Java is not good for applets
> or GUI-Applications, it is more for server side development.  But you
> can still rely on Java, if you want to have cross-platform GUIs, at a
> price.
>
> Best regards
>
> Karl
>
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>

There are lots of great desktop java apps that can be provided as
counterexamples.  Ruby will need to support native threading before it is
able to compete on the desktop, really.  But I guess a lot of this is really
off topic.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://wrath.rubyonrails.org/pipermail/rails/attachments/20060218/b4a739b0/attachment.html

Hi Robert,

Thanks for the great reply.

I''ve been reading a lot about Java over the last few days and am
starting to feel like, that at least for website admin side of things,
building a desktop app will be way more powerful than using a browser.
Now I''m wondering about how to communicate with the server and what to
layer on top of the database program. Also where does the ORM go and
how to insure bad data is not allowed into the database.

One options is to use Rails and web services via SOAP on the server.
Do you think that is the best? Seems to me like this would require
duplicating the model definitions on the server and client so that
when a serialized object arrives at the client, the object can be
reconstituted. Programming the models in Ruby for the server and Java
for the client seems rediculous.

Another option would be to write a specialized server app to sit on
top of the database and communicate via some other protocol. This
makes me think that a pure java solution might be the best way to go.

I''m still investigating options so any more advice about ways to go
would be greatly appreciated.

Net technology. So many options!

Thanks,
Peter

Hey Peter,

If you are interested in writing a strong cross platform client side app,
then maybe download netbeans and give it a shot.  It seems like a very easy
to learn and use IDE.  Alternatively you could give eclipse a try too, but
it seems to have a bit higher of a learning curve.

On the server side, why not give Ruby a try?  There are some very nice soap
libraries that you can use, along with ActiveRecord from rails...  I think
that''d make it pretty easy to get something going.


On 2/18/06, Peter Michaux <petermichaux@gmail.com>
wrote:
>
> Hi Robert,
>
> Thanks for the great reply.
>
> I''ve been reading a lot about Java over the last few days and am
> starting to feel like, that at least for website admin side of things,
> building a desktop app will be way more powerful than using a browser.
> Now I''m wondering about how to communicate with the server and
what to
> layer on top of the database program. Also where does the ORM go and
> how to insure bad data is not allowed into the database.
>
> One options is to use Rails and web services via SOAP on the server.
> Do you think that is the best? Seems to me like this would require
> duplicating the model definitions on the server and client so that
> when a serialized object arrives at the client, the object can be
> reconstituted. Programming the models in Ruby for the server and Java
> for the client seems rediculous.
>
> Another option would be to write a specialized server app to sit on
> top of the database and communicate via some other protocol. This
> makes me think that a pure java solution might be the best way to go.
>
> I''m still investigating options so any more advice about ways to
go
> would be greatly appreciated.
>
> Net technology. So many options!
>
> Thanks,
> Peter
> _______________________________________________
> Rails mailing list
> Rails@lists.rubyonrails.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://wrath.rubyonrails.org/pipermail/rails/attachments/20060218/c2057247/attachment.html