Lan Barnes wrote: > On Sat, Jun 24, 2006 at 04:30:26PM -0700, Andrew Lentvorski wrote: >> Lan Barnes wrote: >> >>> And I would miss these because ...? >> Because there are good uses for Javascript. Much like the initial >> horrid abuse of Flash, once people start to figure it out, it becomes a >> useful tool. >> > > -snip of good uses for JS- > > I'm not attacking the apache/javascript axis ... OK, I am, but not that > much. > > I'm questioning how JS pertains to what I said, which was: > > 1. I wouldn't do a c/s program with a browser interface unless forced to > (as in by a PHB or because I'm Amazon and can't distribute my front end) > > 2. if forced to, I wouldn't choose apache, but rather something more > light weight, mentioning Tclhttpd > > You responded that I would thus loose the richness that is javascript, > and I said (in effect) so what? > > Here's why I feel that way (and I say this with great respect for > apache). > > Good c/s design is: > > FRONT END <--> MIDDLEWARE <--> BACK END > > Middleware is business rules, processing, magic. I don't care where it > lives, but likely it'll be on the back end server or its own server > where I can: > > a. have one production copy > > b. have security and control > > c. not deal with the headaches of distribution and supporting multiple > versions. > > Now we all tend to want to push the middleware to one end or the other, > because writing the extra interfaces is a pain, and the temptation is to > push it to the front end BUT THIS SHOULD BE RESISTED (raise a chant: > "Thin client, thin client ..."). Integrity checking and data massaging > DO NOT belong in the front end and required fields should NEVER be > enforced in the form. Send your data over to the server and let the > server either fix it up or send back a scolding message. > > So now you're telling me that I'll miss javascript because without it, I > can't do cool processing on my client. Hmm ... is Andrew telling me that > I should not just want a FAT client, but an obese client, a client with > its waistline flowing over its belt? No thank you.
Well, one of the attractive uses of javascript/ecmascript in recent fashion, uses XMLHttpRequest/AJAX to make the client experience more interactive, without moving business logic or other traditional server functionality into the client. Andy, for example mentioned/alluded-to google maps, which everybody seems to classify as a _good thing_. Another example might be in background-validation of forms input, where (say) the js might conduct an XMLHttp round trip with the server, to determine whether a new account username was valid/already-taken, etc. The exceptions could nicely update the browser output (via js DOM interface) to report, say "Username already in use; choose another", right on the form, while the user is still composing his input. Well, that's a simplistic example, but nevertheless illustrates an interactivity benefit, compared to how it was done last year. > > "But," you say, "the whole reason for thin clients is to avoid the > hassle of continuously redistributing updates and supporting a variety > of versions. And javascript on a browser gives you a universal platform > on which your server can call for nifty client actions, kinda like > inter-machine call-backs." > > To which I say, how universal has it proved to be? How many flash > modules, JS implementations, language stubs, etc am I expected to load? > Must I use IE? How much does it buy me? What is the bang for buck in > terms of programming effort? Is the single platform the ONLY reason for > thin clients (hint: hell no! Think design and coding simplicity with > concomitant robustness)? And is there, perchance, a tiny security issue > in letting unknown people run stuff on your machine? I haven't actually implemented anything of this sort yet, but clearly there does have to be additional server functionality added, as well as shipping the javascript with the HTML. The js, of course, may be optimized via src=".." in the <script> tags, so that common functionality needn't actually be embedded in every page, and the browser will find it in its cache. I have nagging suspicions about javascript security issues (where is the audit evidence?), but conventional wisdom seems to be that the javascript sandbox barriers are _pretty good_. Anyone care to add insight to this? > > So I say again, I wouldn't do a c/s program with a browser interface > unless forced to. And if I did, javascript (and flash and whatever other > goodies du jour are about) would be rejected from my design. Not > ignored, rejected. > > Now Tclhttpd has some features designed to make my kind of approach > easy. > > http://www.tcl.tk/software/tclhttpd/ for everything, > > http://www.tcl.tk/software/tclhttpd/TCLHTTPD.html for a nice chapter > from a good book. > > It was never meant to be an apache replacement ... how dull that > would be! Sure, you can use it as a well featured web server if you > don't need the apache bells and whistles (or are afraid to lift the > apache book without a weight belt and steel-toed boots). And you can > embed it in your own applications if you ever want a web server to be > tucked into your own programs. > > But what really scratches Lan's itches are the Application Direct URLs, > which basically means, hit this URL, trigger this back-end action. Of > course, the back-end program can be in just about anything that runs on > the platform, but if I write it in Tcl and use a safe interpreter, I > really don't have to worry too much about security (assuming intranet or > ssh tunneling), which is not the way I would feel about a fully > tricked-out apache server, and certainly not javascript. > > And _even then_ I would resist doing a browser interface because It > would require me to write everything twice and support everything in two > places. Yuk! > > Keep it simple; make it work; go on to other things. > > Perhaps more of my philosophy that you cared to know, but there it is. One problem with web-based applications is the sacrifice of responsiveness. Prior attempts to alleviate this have indeed put business logic into the client (eg javascript hard-coded validation of forms), but maybe the XMLHttp/Ajax stuff changes the tradeoff menu. Hey, it's probably even doable in tcl-servers. The protocol adds not much complexity beyond standard HTTP. (I trust you'll forgive a bit of hand-waving, above) ..jim -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
