980 likes | 993 Views
This article discusses the challenges of choosing a web framework and proposes criteria to consider. It covers topics such as JVM in server, web client options, client-centric vs server-centric approaches, dynamic languages, and the benefits of Java and single-page interfaces.
E N D
HowToChoose a Web Framework …and besurprised Jose María Arranz Santamaría Agosto 2010
THE PROBLEM OF CHOOSING • Choosing the appropriated web framework which fits • Your requirements, needs, convenience, desires, taste… • Is not an easy task • This will be a path, with some criteria we will discard options
THE PROBLEM OF CHOOSING • These slides propose and advocate some criteria to pick the right framework • Advocating for freedom of choice, of design, robust, secure… • May be you do not agree with everyone • I must to try… :)
CALM! you will see, THERE ARE NOT VERY MANY! • Many of them are very similar • Some strong criteria are very important • Most of frameworks can be classified by groups
CRITERION: JVM in server • The Java platform is the most robust, secure, speediest and richest for web development
CRITERION: Web Client • Flash/Flex, Silverlight… • Will be replaced by HTML 5 in a short future • HTML/CSS/JS is more flexible and open than Flash/Flex • Data applications do not need to be so “baroque” • Flash/Flex: SEO compatibility is not easy
CRITERION: “Client-Centric”?? • Coding in JavaScript • Unmanageable when code grows • Not typed, not compiled, not true OOP • Hard to organize • Hard to debug and test • Tends to generated cryptic code • Hard to divide the work to do • Hard to divide the code in archives • Slooow • Impossible for Single Page Interface apps.
CRITERION: “Client-Centric”?? (cont.) • Coding in JavaScript Do you really want to code this way?
CRITERION: “Client-Centric”?? (cont.) • Coding in JavaScript: the myth of Rich Interface Application = JS Library • RIA = beautiful web, Single Page Interface, with movements and opacity changes • Beautiful Web • Good design of HTML, CSS, images (nothing to do with JS) • Single Page Interface • Partial changes of the page (client-centric is not implied) • Movements and opacity changes • Funny games with style attributes and timers • The only case a JS library is very useful
CRITERION: “Client-Centric”?? (cont.) • Coding in JavaScript NO THANKS!!
CRITERION: “Client-Centric”?? (cont.) • GWT • Allows coding JS in Java • GWT compiles Java code as JavaScript sent to the client • Visual logic (and some business logic) is executed only in client • Solves the problem of coding in JS • BUT MORE PROBLEMS REMAIN…
CRITERION: “Client-Centric”?? (cont.) • Visual Design is programmatic or with specific IDEs • Bye web designers • Components “black-boxed” • Almost only CSS customization • Cryptic generated JS • Only debugging in Java
CRITERION: “Client-Centric”?? (cont.) • Paranoid server • No confidence with client (and everything is there) • Duplicity of checking/validations • Client-server custom communication data bridges (GWT-RPC) • Duplicity of data management in client and server • SOFEA: utopian approach • Impossible sending SQL from browser • Eternal fight about what is on each side
CRITERION: “Server-Centric” • In “server-centric” business logic and visual logic are executed in server • The server generates markup and/or JavaScript • No need of JavaScript programming • Data and visual state are together • Safer • Better options for freedom of web design (templates) • Easier Search Engine Optimization compatibility • Rule: life in server is more comfortable
LET’S LOOK BACK • JVM in server • Web Client • Server-Centric
CRITERION: Dynamic Language?? • Initially are very productive • But they become a problem when • The source code grows (1000 classes?) • Several persons in the same code • IDEs cannot help very much • Slooow http://www.codecommit.com/blog/java/groovys-performance-is-not-subjective
CRITERION: Dynamic Language?? (cont.) • Can you live without a true “Find Usages” of NetBeans? • Can you live without refactoring tools?
CRITERION: Java Lenguage • The compiler gives us robust and speeder code • Compiler is your friend • Tools like “Find Usages” and “Refactor” (NetBeans) • Allow us to manage thousand of classes • Developer knows how changes affect to any part of the code
CRITERION: Single Page Interface • In Single Page Interface (SPI) a web site/application runs into the same page (no reload) • By using AJAX (or similar) we get new markup or JavaScript for partial updates • Event based programming and only partial changes designed and coded • The same as desktop applications
CRITERION: Single Page Interface (cont.) • No more unexpected Back/Forward/Reload and double form-submitting • No more “post-redirect” • Back/Forward buttons of browser can optionally work in SPI and remain SPI and deterministic • No more unexpected caching (GET) • No more unexpected “form autofill” • Changing values provided by the server on page load • No more stupid full page rendering when anything is changed • Avoiding annoying blinking and scrolling • Increased performance
CRITERION: Single Page Interface (cont.) • No more includes into includes into includes • Templates ONLY containing initial page or page fragments • More tolerance to visual changes • No more direct access to internal pages • No more problems when the same user opens two page windows • Pages of a SPI application DO NOT share state by default • Session is NO longer the place to save temporal data • No more problems with modal windows • Browsers do not like them (hack) • In SPI you can simulate modal windows
CRITERION: Single Page Interface (cont.) • End users increased productivity! • Example: showed errors while introducing data • FACT: no one desktop application is paged (multi-frame) • No, a “wizard” is a single modal window, the same “frame” (=page) is kept • The SPI concept is NOT NEW http://devedge-temp.mozilla.org/viewsource/2003/inner-browsing/index_en.html • SPI is much more than “a bit of AJAX” • If the web framework is not SPI oriented the page must change to load new AJAX based components
CRITERION: Single Page Interface (cont.) Click “Standard” < v2.0 (no AJAX) Another reason to discard both again
LET’S LOOK BACK • JVM in server • Web Client • Server-Centric • Java Language • Single Page Interface
CRITERION: Not a forced web • Tools like EclipseRAP and AjaxSwing are interesting for quickly porting desktop applications to web • The result is a “forced” web application
CRITERION: Templates based on plain HTML with no logic • Allows division by role between developers and web designers • Two clear roles: visual design, lógic programming (visual and business logic) • Reusing of visual design (visual patterns) • Reusing of visual logic => OOP • Can be very independent of concrete visual design • Absolute control of layout when “markup is alive”
CRITERION: Templates based on plain HTML with no logic (cont.) • JSF flavours…. NO!
CRITERION: Templates based on plain HTML with no logic (cont.) • JSF flavours…. NO! • Black-boxed components • Visual aesthetic is imposed • Hard to change, “is what you get” • Mixed visual design and logic (lots of Java bindings and EL expressions) • Too much Java Reflection, security risk • Struts security hole (in ONGL): http://struts.apache.org/2.2.1/docs/s2-005.html • Spring security hole: http://securityreason.com/securityalert/7526 • Specific visual editors needed (= FAILURE)
CRITERION: Templates based on plain HTML with no logic (cont.) • ZK? …. NEITHER! • Similar to JSF “I don't think UI Designer would have patient to learn how to polish his web site in ZUL file, they want CSS and HTML” http://stackoverflow.com/questions/327328/any-real-world-experience-of-the-zk-ajax-framework
CRITERION: Templates based on plain HTML with no logic (cont.) • Vaadin? NO TEMPLATING! • Visual design fully programmatic!
CRITERION: Templates based on plain HTML with no logic (cont.) • Wicket to the rescue? • “Wicket does not mix markup with Java code and adds no special syntax to your markup files” http://wicket.apache.org/meet/features.html • Let’s see AJAX “Tree and TreeTable” ex. • Where is the tree markup? => Black Box! (again)
LET’S LOOK BACK • JVM in server • Web Client • Server-Centric • Java Language • Single Page Interface • Not a forced web • Templates based on plain HTML with no logic
CRITERION: “Push” Templates • In a “push” template the contained markup is the visual pattern managed by Java code pushing data to the template (this is not executable) • Java code has complete control of the lifecycle of instances, begin and end of transactions • Promotes visual reusing and OOP • IoC/DI is not imposed (optional) • Example: Wicket load phase (no AJAX) • But Wicket is fully discarded…
CRITERION: “Push” Templates (cont) • JSF flavours and ZK • Executable (pull) templates • Java objects controlled by template • Vaadin • Template? What is a template?
CRITERION: Easy Creation of Custom AJAX Components • Answer to the “fine but can it do…?” • JavaScript minimum or nothing • New markup defined as markup (sort of template) • Not as JavaScript • We can decide what elements send events • Event processing in server can insert/modify/remove our markup
CRITERION: Easy Creation of Custom AJAX Components (cont.) • JSF pre 2.0 • Tons of “hacks” • Markup management with client JavaScript https://bpcatalog.dev.java.net/ajax/textfield-jsf/design.html http://www.oracle.com/technetwork/java/javaee/tutorial-jsp-140089.html http://media.techtarget.com/tss/static/articles/content/JSFReference/JSFReferenceCH11.pdf • JSF post 2.0 • Simplified creation of “composite” components… WOW a new sort of include was invented! • AJAX calls standardized. WOW! • The same annoying JavaScript http://www.ibm.com/developerworks/java/library/j-jsf2fu-0410/index.html
CRITERION: Easy Creation of Custom AJAX Components (cont.) • ZK • There is some example beyond adding AJAX listeners to markup on load time? • New markup management again with JavaScript in client http://docs.zkoss.org/wiki/Component_Development_Tutorial http://www.zkoss.org/doc/compdevguide
CRITERION: Easy Creation of Custom AJAX Components (cont.) • Vaadin • According the manual is not an easy task. The reference manual is sincere: • “Creation of new widgets involves a number of rather intricate tasks” http://vaadin.com/book/-/page/gwt.html • A new GWT component must be created, another one for server, code for client/server coordination and data communication, several registries • Positive: fortunately management of new markup is Java based (GWT) but pure programmatic (bye web designers) ?
LET’S LOOK BACK • JVM in server • Web Client • Server-Centric • Java Language • Single Page Interface • Not a forced web • Templates based on plain HTML with no logic • “Push” Templates • Easy Creation of Custom AJAX Components