I think the question is whether you can implement ALL the view code in a server-side framework. If you cannot because there are some dynamic things you want to do client-side to provide a better user experience, then why not implement ALL the view code so it runs client-side? It seems that the most common, unspoken reason to use a server-side framework for generating HTML is that some developers prefer using a language other than JavaScript for that, not because they necessarily care about doing the work on the server-side.
Suppose you were implementing a Swing application that displayed data from remote services. Can you imagine writing services that return descriptions of how the data should be displayed rather than just returning the data? Services that return dynamically generated HTML to the browser seem like that to me. On Thu, Nov 11, 2010 at 10:37 AM, phil swenson <phil.swen...@gmail.com> wrote: > Separation of view code from controller/model is what the view layer > is for (jsp/.erb./.haml/.gsp/etc) > > All this does is move more of your logic into javascript in the > browser instead of in your rendering template. You can do this with > any web framework anyway if you like... but I will note it's harder to > test and debug javascript than java or ruby. And your code is less > reusable (if you do a bunch of javascript validation logic, that means > your model isn't doing it so you may need to duplicate the model > validation). > > > On Thu, Nov 11, 2010 at 9:07 AM, Mark Volkmann > <r.mark.volkm...@gmail.com> wrote: >> On Thu, Nov 11, 2010 at 9:45 AM, phil swenson <phil.swen...@gmail.com> wrote: >>> This is similar to what you guys are talking about from 37 signals: >>> >>> http://thinkvitamin.com/mobile/new-rails-like-framework-from-37signals-for-html5-mobile-apps/ >>> >>> I personally don't get the advantage of doing everything in javascript >>> on the client (less data to transport)? >> >> That's a small benefit. I think a bigger one is a better enforced >> separation of view code. Also, in a dynamic web application, you >> typically have to write some JavaScript code to modify the DOM anyway, >> so why not go the rest of the way and build all the non-static parts >> of the pages on the client. That way there is a single approach to >> providing dynamic UI changes. >> >>> On Thu, Oct 28, 2010 at 10:39 AM, clay <claytonw...@gmail.com> wrote: >>>> Five years ago, there were intense debates of web frameworks. There >>>> were Java framework wars among Struts vs JSF vs Tapestry vs Wicket vs >>>> Spring vs etc along with the the prominent non-Java frameworks such as >>>> PHP, ASP.NET, Rails, etc. >>>> >>>> Recently, I've been working on rich web applications that use: >>>> - 100% static HTML/JavaScript/CSS >>>> - Client-side JavaScript GUI framework such as ExtJS or YUI or >>>> something similar. >>>> - Server-side web services such as JAX-RS/JSON or something similar. >>>> >>>> No traditional server-side HTML web framework. >>>> >>>> This really seems like the perfect dev stack for the web. The tools >>>> are extremely easy to learn and use and debug. I can edit static HTML/ >>>> JS content and get feedback instantly or edit server-side code and >>>> restart web services in seconds. There is no code generation, which >>>> from past experience always leads to headaches eventually. Completely >>>> separate client/server source code is much easier to read, edit, and >>>> works much better with syntax highlighting than hybrid server-side >>>> template files that mixed template markup, server code, and client >>>> code. And, most importantly, the end web apps are extremely high >>>> quality, extremely fast, and fully customizable. >>>> >>>> Having done hundreds of web projects with dozens of web frameworks, >>>> and witnessing so much debate about which framework was better, I'm >>>> amazed at how much better web development is without any traditional >>>> framework piece at all. >>>> >>>> So, would people tend to agree? I'm also surprised that after how >>>> heated the server-side web framework wars got, few people have >>>> mentioned their obsolescence. >>>> >>>> -- >>>> You received this message because you are subscribed to the Google Groups >>>> "The Java Posse" group. >>>> To post to this group, send email to javapo...@googlegroups.com. >>>> To unsubscribe from this group, send email to >>>> javaposse+unsubscr...@googlegroups.com. >>>> For more options, visit this group at >>>> http://groups.google.com/group/javaposse?hl=en. >>>> >>>> >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "The Java Posse" group. >>> To post to this group, send email to javapo...@googlegroups.com. >>> To unsubscribe from this group, send email to >>> javaposse+unsubscr...@googlegroups.com. >>> For more options, visit this group at >>> http://groups.google.com/group/javaposse?hl=en. >>> >>> >> >> >> >> -- >> R. Mark Volkmann >> Object Computing, Inc. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "The Java Posse" group. >> To post to this group, send email to javapo...@googlegroups.com. >> To unsubscribe from this group, send email to >> javaposse+unsubscr...@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/javaposse?hl=en. >> >> > > -- > You received this message because you are subscribed to the Google Groups > "The Java Posse" group. > To post to this group, send email to javapo...@googlegroups.com. > To unsubscribe from this group, send email to > javaposse+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/javaposse?hl=en. > > -- R. Mark Volkmann Object Computing, Inc. -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to javapo...@googlegroups.com. To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
