On 19 February 2012 21:48, Fabrizio Giudici <[email protected]>wrote:
> On Sun, 19 Feb 2012 18:51:54 +0100, Cédric Beust ♔ <[email protected]> > wrote: > > On Sun, Feb 19, 2012 at 5:30 AM, Moandji Ezana <[email protected]> wrote: >> >> 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<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. >>> >>> >> I think there are valid reasons to follow this approach, the most >> important >> to me being: what language is more convenient for you to render the >> template? There are a few cases where Java's module support can lead to >> more reusability/maintenance than Javascript when you start generating >> complex HTML+CSS stuff. This also applies when the UI composition is done >> on the back-end with something like GWT, obviously. Obviously, another >> advantage is a more unified stack (everything is done in Java/Scala as >> opposed to having to throw HTML/CSS/Javascript in the mix). >> > > After so many years, a thing that I still don't like, but it's present in > FreeMarker, Play, etc..., is that templating uses a syntax other than HTML. > This is fine for pure programmers, not good when a graphic designer must be > involved - or when you want to use a HTML editor. I prefer an approach > where everything is HTML. > > The catch here is that HTML is a *terrible* format for the way we use it. HTML grew out of SGML, and is still fundamentally a format that grew from the demands of publishing printed material; large blocks of text with the occasional special character, image, table, or heading. Web pages aren't structured like this. They're, well, much more structured! They're complex layouts with dynamic content, and rich semantic meaning - a world apart from the chapter/paragraph model used in traditional publishing. With XML/XHTML it gets worse. We not only ramp up the number of elements demanded by ever-richer content, but also have the rule that each element must be 'closed' so that we can maintain structural validity even whilst manipulating those elements. It's an explosion of boilerplate in a format taken far outside of its original use-case. Sad but true... HTML is still a necessity for no other reason than tool support. Even then, attempts to use HTML as a templating language have often been less than successful; I'm sure we all remember how many earlier tools would just choke and die when encountering JSP's <% %> and other such non-standard tags from alternate frameworks. Because of this mess, most web devs I know nowadays won't use that approach any more. They'll take assets supplied by designers (single images for buttons, borders, etc) and compose them in whatever non-html language is being used. The round-trip time in the current crop of tools (play/rails/grails/etc.) is essentially instant, so the approach works well. -- 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.
