Now this does not read well at all...
Just when I started my pet project using ZK - thank you John for your
input here - I'm starting to have second thoughts...
Looking at alternatives, your suggestion Trevor looks increasingly
appealing now.
However, not wanting to start an opinion war, my leaning towards server
side frameworks was the independence of browser rendering, transparent
AJAX (for some "minus JavaScript"), and the allure of developing web
based applications using desktop application development techniques (if
I can call them so) which I'm more familiar with.
Now, in the light of new potential licensing developments and future
support for *free* Java, I'm starting to lean towards client based
frameworks and the use of the libraries mentioned by Trevor in my
previous thread - knockout.js, backbone.js and upshot.js - I'm not that
far into this project that I cannot change my mind yet.
But I need some convincing.
Who knows, maybe Ellison will change his mind, but just in case he
doesn't - I respect Vikram Kumar's opinion expressed here:
http://www.nbr.co.nz/article/have-com-web-address-know-legal-risks-ck-113355
replace "Government" with "big corporation" and you get the idea.
So, considering that I'm talking about a database centric application
(using Postgresql as back-end) and being a newcomer into the web app
programming field, what would be the big PROs in using a client side vs
server side framework?
To be more specific, my main concern is basically browser compatibility,
having had some bad experiences with CSS, tables, and XUL/Gecko in the
past.
TIA,
Adrian
--
You received this message because you are subscribed to the Google Groups "CantyJUG" group.
To post to this group, send email to cant...@googlegroups.com.
To unsubscribe from this group, send email to cantyjug+u...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/cantyjug?hl=en.
A few pros:
- Farm off a lot of processing (e.g. template rendering) to the client.
- Incredibly responsive application, particularly good for real time
apps.
- Good scalability, low bandwidth requirement after initial load (JSON
only over the wire)
A few cons:
- No real sane path for graceful degradation for non JS browsers.
- Can quickly lead to code duplication, see below.
- Need a good cross browser testing strategy.
And this could either be a pro, or a con, depending on your viewpoint:
- You need to write a lot of JS, and maybe even *learn* it!
My personal preference in doing this kind of thing is that the server
side becomes a fairly thin layer that mostly provides a REST interface
to the Javascript client using JSON, handling authentication and
validation on the way to the data store. I use Backbone + Rails, they
are a good fit, though YMMV in Java land.
Code duplication is a real problem. For example, I have 'models' in
backbone that have validation rules to ensure they are valid before
submitting a request to the server. But I need to ensure the same
validation exists on the server side, and I need to rewrite that whole
slab of code in a different language. This problem rears it's head
repeatedly, and you can end up writing a lot of your classes twice.
There are a crop of server side JS platforms cropping up, which address
this problem, allowing you to run the same code on the client and
server. This stuff is in it's infancy, and may well make you shudder,
but I can see it getting a lot of traction. See http://www.meteor.com/
& http://derbyjs.com/
For cross browser testing I use http://busterjs.org/, which allows
concurrent unit test running against multiple browsers, plus integration
tests which drive a browser using selenium.
I can't really comment on things from a desktop app developers point of
view, and have no knowledge of the Java tools available for this stuff,
but the approach above works well for me.
Malc
Time for me to go back to reading...
Adrian