Link Details

I think we're being deliberately provoked. 'Put as much logic as possible into Javascript'? I think Mr Script Uncle is just trying to start an argument for some attention. He has a point or two - most people don't use PHP *and* Java - but the conclusions drawn are fairly flimsy...

No, I'm not provoking anyone. I am trying to get attention, though. :) I genuinely recommend you to try out the approach. My main point is just that it is in my experience more effective to completely decouple client-side presentation from server-side logic. I know on which side the problems pop up, when they do. This is not the case when generating the client out of the server. Also, security and business logic must always remain on the server, but as much of the other stuff you can carry over to the client will make your life easier. Don't trust me - Try it !

I know what you mean - the MVC design pattern is a great example of this, and it does help a lot to separate presentation and logic layers. I just confused your article for proposing to put business logic into Javascript. Eek. If you're not talking about doing that, then I agree.

Also, it *is* possible (sometimes even easier) to separate these layers by using a framework. To me, your argument there is just another reason why using a framework is better, cos it helps me to separate the layers more effectively into M,V, and C parts...

Well, yes, of course things should be cleanly separated. But what I mean is that by losing the V part of MVC from the server-side, you immediately get a simpler server. Ideally, I think the server should be some good server-side framework (not: Just not a Web framework) like Spring, for instance (Yes I know, but I wouldn't be using that part :) and Hibernate.

Since most people realizes the end-user benefits of "Ajax" technologies and try to add them in parts to the existing server-side web frameworks, the frameworks gets more complex, because they were not made that way in the first place.

By separating concerns completely, and by using a mature client-side framework like Dojo 1.x och perhaps jQuery, I have found it much easier to do what I do, and know ehre and how I go wrong when I do, compared to the XML config-file free-for-all I have to endure when making sketches on how the client should look on the server, before it exists.

I just built a Facebook app and chose to go with no web framework, for various reasons: performance and framework constraints included. Ultimately I mined out a local web framework specific to the application --to separate concerns. The experience was quite refreshing! Sometimes it's nice to just work with good old HTTP and have no surprises and little to no configuration.

That's a good thought indeed.
It is common to find developers that are overwhelmed by all kinds of frameworks and they can't realize that those layers - in most cases - represent unnecessary complexity to the application.
Simplicity allows quick code change and better productivity.

i agree with two things: 1) most frameworks are clumsy, and 2) keep the interface to the server simple, and beef up the client.

however, javascript is heinous. unless you project is VERY small, then javascript + html = tedious to build and maintain. GWT (which i have used) and Flex (which i have only read about) offer the best of both worlds. elegant client-side development, and java (or whatever you want) on the back end. additionally, large projects (with several developers hitting the same code base) work much better with a typed language - so that design is self-explainatory. i don't know how much crazy javascript code i have had to look at for hours to piece together what the hell it was doing.

with good techology it is easy to do things right, and hard to do things wrong. javascript has neither of those qualities. jhc, it's not even cross-platform!

flex and gwt are at least forward-looking. javascript is analogous to C on the desktop 15 years ago. you could do anything with it, it had a lot of libraries, but it's clumsy, crude, and antiquated.



,

For RIA web apps (Flex, Silverlight, JavaFX, GWT), the old school web framework on the server-side (of all stripes - including RoR), is superfluous. Just need to write a much simpler SOA middle-tier. RIA + SOA.

Doing MVC down on the client-side leads to less complexity than trying to do MVC on the server-side.

@burtonmiller: I think that no language are impervious t morons. Also, I have seen at least as much idiot Java code as I have seen idiot JavaScript code. Maybe you should look up my actual points and respond to them, as you clearly have the required experience of having implemented medium-to -large scale projects in both Java _and_ JavaScript, not just enduring some 16-year old kids version of one or the other.

Currently working on a project...(was brought into it) that has the entire front end in Javascript...while the server side is simple, the client side is horrendous...I wouldn't wish this type of architecture upon anyone. Not only that, but if the application is at all large, as this one is, you wind up asking your end-users to have beefier machines, download MBs worth of javascript (even after compression), and you open yourself up to a number of security holes. (Granted you've got holes in other places too, but to me thats too much on the client).
For smaller apps, I think that is fine, but for larger apps....I'd stay far away.