Play framework for Java - a radical rethink of Java web app development?

http://www.eweek.com/c/a/Application-Development/How-to-Arch...

Say you have a page that shows basically the same content for everybody, but has a handful of user-specific elements in there. In a typical MVC setup you'll a controller as the gatekeeper with overall knowledge of the request, it will assemble the data needed for the request and pass it to the view. The view may be one template, or it may be comprised of many, including a layout and several sub-templates. In order to fetch all the content efficiently, you want to know everything up front, so there is no n+1 problem or similar. This works pretty well for the gross content of the page, but not nearly so well for the minutiae. Whether a specific piece of data is often not reasonably known until deep inside a nested template.

So you have a conundrum, do you make assumptions about or replicate the view logic in your controller in order to efficiently load everything? Or do you suffer the performance penalties of looking things up in an ad-hoc basis within the templates at the point their needed?

The answer is simple, you leverage the client. The controller loads the gross content and the templates puts placeholder values for all the other data (classes and maybe some custom attributes). Then you have a javascript library that scrapes up the references to the needed data and requests it directly from the server. This effectively converts your page into a static page that can be served to everybody, cached to your heart's content, etc, and it offloads a good chunk of your processing to client machines which of course by definition scale in constant time.

I've done this in Rails using resources and json, and the performance and scalability benefits are amazing. You just need to know how to write good Javascript and be aware of the security concerns. The only thing that's need to make this uber-efficient in Rails is some kind of request bundling so that if you have more than 2 or 3 resource types needed you don't need to send a separate request for each one.

To all the doubters, you need to open your mind about this. I'm guessing most of you just don't like Javascript, to which I simply direct you to Douglas Crockford.

Until mine is ready, you can try mvnrepository.com. The reason that I'm building my own is because mvnrepository.com is often down, slow, and is not very easy to use. But it's there until I'm finished with mine!

Yes and I am somewhat regretting stiring this up, but I understand it, I was on that side of the fence for a long time, until I was dragged over to the other side.

The other posters are being very pragmatic, and that is a good trait to have. The problem is that we are creatures of habit and when we find something that works no matter how efficient we are hesitant to discard it.

I will tell you that when rich internet applications first came into popular use, I was one of the biggest detractors for the exact reasons that I am defending it's use today.

My initial reaction was that we have just added more convolution to the mix of technology soup that ASP, JSP, PHP have become. Now, not only does a developer need to know a server model but they have to understand a client model.

I thought to myself this is the worst of both worlds. It was not until someone more visionary than I, explained to me my wrong headed thinking. In that you have to abandon the server model for the picture of rich internet applications to become clear.

In the end we have had years of indoctrination to a certain model and it is hard to reason outside of that known reality. I was one of the most guilty of doing this, given that I have been doing this since the beginning.

"To all the doubters, you need to open your mind about this. I'm guessing most of you just don't like JavaScript"

This is a huge concern that I see time and time again, but what is funny is that this liberates the technology selection for so many other systems. No longer do I have to worry about trade-offs like Rails is faster to market but Java has a bigger library. With this form of architecture those decision decoupled. Services can be implemented in whatever language best fits the problem domain. You can use one or you can use many, it is a choice of each development house. Further, you can chose to third party provide whole sections of your application. This works very well at Google some systems are provided in python, some in Java and yet other are implemented in that team of choices language.

As for JavaScript as of now this is a limiting reality. Many of the browsers are working on alternative languages and there are converter that will allow you to write Ruby or Python or whatever and have it converted into JavaScript. But the reality is, yes web client programming is done in JavaScript. For me, it is not a big deal, as I find that UI development is best supported by a rapid prototyping language and JavaScript fits the bill. I am continually amazed at the flexibility of the language. Conversely, I prefer strong typed languages for services.