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?
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.
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.
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.
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.
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.
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.