On Fri, Feb 17, 2012 at 9:29 PM, Kevin Wright <[email protected]>wrote:
> This is certainly the REST ideal, but it's not so simple as it sounds. > Even in a rich-client environment you can still expect back end servers to: > > Handle json serialisation/parsing > Manage routing to restful endpoints > Perform caching and gzip compression > Co-ordinate chunked http streams > Convert coffeescript to Javascript > Convert less/sass to CSS > Minify/aggregate resources > Marshall data across domain boundaries > Authorisation/authentication/oauth/ssh termination > I agree with Fabrizio: most of those things should be handled by other libraries. The web framework should just translate HTTP to Java, Scala, etc. and back. From there, a well-designed framework would make it easy to integrate wro4j, Jackson/Gson, my favourite templating engine, an ORM, etc. It would be great if such a web framework could be built around just @Inject or maybe CDI, so as to minimise its impact while easing integration. even with a client-side framework like bootstrap, I still prefer to > generate the html from jade templates, it allows for better Modularity. > I was just reading a 37 Signals blog post<http://37signals.com/svn/posts/3112-how-basecamp-next-got-to-be-so-damn-fast-without-using-much-client-side-ui>about how they do exactly this. Instead of passing JSON to the client, they pass server-rendered HTML. A previous bad experience with a project that did that made me wary of the approach, but now I'm rethinking my stance. With a good templating engine <http://www.jamon.org> (ie. not JSP) and a disciplined approach, maybe it could work well. Moandji -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
