980 likes | 1.09k Vues
How To Choose a Web Framework. …and be surprised. 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
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