<ra*******@gmai l.comwrote:
Hi Everyone,
I work for a financial company. I am planning to give a
presentation to rest of the development team (15 people)
here on moving server side logic to client-side javascript
for an internal intranet application rewrite.
This approach will definitely stir up hot debate from
hardcore server-side Java folks who wants to do UI stuff
even on the server!. Since I am pretty much known as the
JS or UI Guy of the group, my Boss wants to hear the broad
spectrum of PROs/CONs from each proponent.
Personally, I think Javascript/Ruby is a more productive
language than Java.
Well don't even mention that (particularly to your Java programmers) or
you will find yourself not being taken seriously at all.
My idea is simple. It is to convert most business logic to
client- side javascript and have calls to server-side code
restricted to user roles with data validation. Thats as
simple as it gets.
While (if they are any good) the server-side Java programmers will
already have the business logic in the form of re-useable components and
will question the cost of re-creating what already exists. Or they will
point out that if they implement new business logic they will be able to
easily re-use it later projects. Or they will point out that in order to
validate on the server they will still need most of the business logic on
the server so anything new will be being written twice.
Here are my list of arguments
1. True separation of UI logic from server-side data
processing code (no more server code spitting out
client-side code)
Didn't you just say you were planning on putting the business logic on
the client?
Putting all the user-interface code on the client makes sense (though it
is not always practical: consider sorting a table of 400,000 transactions
on the client. That is not going to happen).
Consider this 'separation' carefully. The thing to go for is a situation
where the server doesn't care about the specifics of the client (web
browser, desktop client, etc.) and the client doesn't care about the
technology running on the server (Java, ASP, .NET, Ruby, etc). That
separation would be about how the two communicated (SOAP (web services),
custom XML, JSON or whatever, and what messages/data they transmitted).
Pitch the separation at that point and you are building UI components for
a browser that can be used with any similar communication interface, and
the server code can provide the same interface to any client.
2. Better user experience with faster response
That doesn't necessarily follow, as the odds are client desktop machines
are of varying capability and include many that are not that new and not
necessarily due for an upgrade in the near future, while a brand new dual
or quad, mult-core CPU server with 4GB RAM and the latest hard disks
(with appropriate RAID spanning) can have the server side code flying,
organisation wide, for $4,000 or so (they really have got very cheep over
the last year or so).
3. The whole web 2.0 thing (no page refresh) :)
Buzzwords are not a reason for making strategic or architecturally
decisions.
If you mention it be ready to be asked precisely what "web 2.0" means,
and to be ridiculed if all you say is "no page refresh".
Have you any practical experience of designs where the page is never
refreshed? Odds are we are talking about Windows 2000 desktop machines
and so no opportunity to upgrade IE 6 to IE 7 (which is far better in
this respect) and so the need to put a great deal of work into not having
IE 6 gradually accumulate ever more of the client PC's memory, and
operate slower and slower as time goes on.
4. Offload client processing from server therefore reducing
network traffic (not really a strong argument is this?)
As I implied above, the need to offload work form the server is
diminishing, and modern networks can handle the traffic (particularly if
HTTP compression is employed).
Keep in mind this is an internal app. Even if someone figures
out the JS logic behind the page and try to hack the app by
posting to Servlets, they will be restricted by their login
role, and data validation will take care of any bogus data
being submitted.
So you will not be selling the server-side Java programmers on the idea
of them having less work to do, as they will have to repeat much of what
you do on the client in order to validate whatever is submitted.
Any feedback greatly appreciated to help this lonely UI guy!
I would have thought (and particularly in the context of a financial
institution, and for an internal application) the case to make would be a
financial one. The impact of potentially increased/decreased productivity
of the users of the system, with and against the cost/benefit of R&D,
design, implementation, ongoing maintenance, and their knock-on effects
for future projects.
Richard.
