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”?? (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
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 (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 (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