On 3/27/07, Csaba Nagy <nagy@ecircle-ag.com> wrote:
> > I agree with everything you said except the point about the GWT.
> > Using a framework like this you can have your query in the javascript,
> > and pass it through directly the database and pass the data back using
> > extremely simple (think 10 line) php or perl rpc that renders query
> > result back in json to the browser. In fact, you can write, compile,
> > and debug the app in java which is great advantage of gwt (imo). Of
> > course, this is not an appropriate way of writing an application over
> > untrusted network but otoh, is....very RAD.
>
> "Untrusted" is the key point here... in most of the real world cases you
> will be far away from such trust that you would run SQL coming from the
> end users browser...
well, untrusted meaning to general public. you can ssl encrypt the
session and do authentication in the middleware (10 line php becomes
50 lines). The real danger is that someone reverse engineer your .js
app and execute arbitrary sql which is quite dangerous to any databse,
even after basic armoring. However, in-house application development
is quite common, maybe the most common type of development.
> > What you get is the limitation of working through the browser but you
> > can kiss goodbye to deployment headaches that plague classic thick
> > client apps because the runtime is 100% contained in the browser
> > rendering engine and some mighty .js files.
>
> And this draws the next problem, in the moment your .js is too "mighty",
> the users will come screaming after you once their browser starts to
> regularly crash, drive the client box out of memory, bog it down to a
> halt, etc.
maybe...google and others have pretty much nailed the leaky browser
problem on modern browsers imo. I think you may find this is much
more reasonable than you might expect...
my point is that with thick server you can do very rapid development
eliminating the middleware completely and doing all work on
client/server. and, reversing .js is only slightly more difficult
than reversing vb6 for example, which is arguably most popular, albeit
reviled quick'n'dirty application platform of all time. If most of
the real work is done on the server, though, it's not so bad.
merln