I’ve had the chance over a recent weekend to have a first crack at a web framework called Vaadin.
I was originally browsing for news about the latest release of Google’s GWT framework when I stumbled on a reference to Vaadin, and decided to go take a look. What I found intrigued me, and I decided to take it for a test drive, as I was down sick for a couple of days with a laptop nearby…. My back became annoyed with me, but it was worth it, I think.
First off, the practicalities: Vaadin is open source, and with a reasonable license, the Apache License. The essential bits of Vaadin are contained in a single JAR, and it’s both Ant and Maven friendly right out of the box.
The next thing that struck me about Vaadin was the documentation. The first unusual thing about it’s documentation was the fact of it’s existence, as open source projects are downright notorious for poor documentation. Vaadin is a pleasant exception, with tons of examples, a well-organized API doc, in the usual JavaDoc format, and even the “Book of Vaadin”, an entire PDF book (also available in hardcopy) that takes you through Vaadin in enough detail to be immediately productive.
Given that surprisingly pleasant start, I dug deeper, creating a little app of my own.
Just the Java, Ma’am
The main thing that kept me interested in Vaadin once I started digging further was that it’s pure Java. Many frameworks talk about writing your UI work in Java, such as Wicket, but there’s still a corresponding template and some wiring that happens to put the code and the template together. Not so with Vaadin.
Unlike GWT, though, the Vaadin approach doesn’t bind you to any specific source code though, it’s just a binary jar you put on your classpath.
The only thing in my sample app, other than 2 Java files, was a web.xml and a css stylesheet, both of which were only a few lines long. And this was no “Hello, World”, either, but a rich AJAX webapp with a tree menu, fancy non-modal “fading” notifications, images, complex layouts, and a form with build-in validation. And it took maybe 4 hours of total work to produce – and that was from a standing start, as I’d never heard of Vaadin before last Thursday. Not bad, not bad at all.
I haven’t yet tried creating my own custom components, but it certainly looks straightforward enough.
I did try linking to external resources, and included non-Vaadin pages in my app, with no difficulties, so it appears that Vaadin plays well with others, and can be introduced into an existing project that uses, for instance, a whack of JSP’s that one might want to obsolete.
I think Vaadin warrants more exploration, and I intend to put it further through its paces in the next few weeks. It appears extremely well-suited to web applications, as opposed to websites with a tiny bit of dynamic stuff in them.
It offers an interesting alternative to some of the patterns I’ve seen for advanced dynamic webapp development so far.
You get to use all of the tools you know and love for the back-end services to write the code for the UI, which you can then unit and functional test to your heart’s content.
The temptation to mix concerns between UI code and back-end service code must still be resisted, of course, but at least that code isn’t buried somewhere in the middle of a JSP page, ready to leap out and bite you later.
Because you’re using dynamic layouts, the app always fits properly on the screen without any extra work, addressing a pet peeve of mine, the “skinny” webapp, restraining itself to the least common denominator of screen size, thus rendering impotent my nice wide monitors.
Just because Vaadin is a Java library doesn’t restrict you to using Java to drive it, however. I made another little webapp where the whole UI was defined in Scala, calling the Vaadin APIs, and it worked like a charm. In some ways, Scala is an even better fit for Vaadin than straight Java, I suspect. I haven’t tried any other JVM compatible language, but I see no reason they wouldn’t work equally well.
Deployment and Development Cycle
As I was building the app with Maven, I added a couple of lines to my POM and was able to say “mvn jetty:run” to get my Vaadin app up and running on my local box in a few seconds. My development cycle was only a few seconds between compile and interactive tests, as I was experimenting with the trial-and-error method.
TDD would be not only possible, but easy in this situation.
I successfully deployed my little Vaadin app to ServiceMix, my OSGi container of choice, without a hitch.
Performance appeared excellent overall, although I haven’t formally tested it with a load-testing tool (yet).
So far, I’m impressed with Vaadin. I’m more impressed with any web framework I’ve worked with in a number of years, in fact. I’m sure there are some warts in there somewhere, but for the benefits it brings to the table, I suspect they’re easily worth it. I think the advantages to teams that already speak fluent Java is hard to overstate, and the productivity to produce good-looking and functioning webapps is quite remarkable.
Over the next few weeks I’ll push it a bit harder with a complex example application, and see how it stacks up against other web app technologies I’ve worked with in a more realistic scenario.
By: Mike Nash
- 40-60% of daily visitors come with an empty cache – the key to making these first-time visitors happy is less HTTP requests
- CSS sprites
- Combined files (combine all scripts into a single file, same for CSS)
- Inline images (not yet supported in all major browsers)
- Reduces page weight and accelerates user experience
- Worthwhile to zip:
- HTML docs
- XML docs
- JSON docs
- Not worthwhile zipping (are already compressed – waste of CPU time and may actually increase file size)
- PDF files
- Allows for page to load progressively (display content as soon as possible instead of waiting until all data has arrived to display everything at once)
- Scripts block parallel downloads – browser won’t begin another downloads (even on different hostnames) while a script is downloading
- Minimize use of “document.write” (or equivalents to this functionality) ontil the bottom of the page
- Use the DEFER attribute where possible, which indicates that the script does not contain a “document.write” line and the browser can continue rendering (firefox doesn’t support this)
- Although powerful, these are evaluated more often than one would expect – they are evaluated when:
- page is rendered
- page is resized
- page is scrolled
- user moves the mouse over the page
- Yahoo’s developers found (using counters in these expressions) that mobing the mouse around the page can easily generate more than 10,000 evaluations
- Reducing the number of unique hostnames has the potential to reduce the amount of parallel downloading that takes place in the pagehowever;
reducing parallel downloads may increase the response times
- A balance must be struck between the number of unique hostnames and the amount of parallel downloading potential of each page – Yahoo recommends to split these components across at least 2, but no more than 4 hostnames; this generally results in a good compromise between reducing DNS lookups and allowing a high degree of parallel downloads.
- For more information, visit http://developer.yahoo.com/performance/rules.html#minify
- Minifying code is simply removing unnecessary whitespace and commenting to reduce file size.
- 3rd party automated minifying tools exist such as JSMin
- “favicon.ico” – an image that stays on the root of your server
- Even if you don’t care about it, the browser will still request it
- it is better to not respond to this request with a 404 Not Found, and cookies are sent every time its requested (which will be every page if you are responding with 404 Not Found
- To mitigate these problems:
- Make sure it is small (< 1K)
- If you don’t care about setting this to anything, give it a long expiry time
- Pros of using iframes:
- Helps with slow third-party content (ads, external pictures, etc.)
- Can be used as a security sandbox
- Allows for scripts to be downloaded in parallel
- Cons of using iframes:
- Costly, even if left blank
- they block page onload
- Preload only what is absolutely necessary for the page to render
- Make Ajax Cacheable
- Use GET for AJAX Requests
- All rules and guidelines also apply to Ajax
- Gzip Components
- Reduce DNS Lookups
- Avoid 301s, 302s, and 404s
- Avoid 301s, 302s, and 404s whenever possible
- Don’t Scale Images in HTML (costs time to scale images – make the picture files themselves appropriately sized)
- Keep Components under 25K
- Remove Duplicate Scripts
- Investigate whether or not ETags are a good idea for your website
- Flush the Buffer Early
- Ideally right between the end of the head tag and before the body tag
- Yahoo pioneered research and real user testing to prove the benefits of using this technique (More Info)
- Use a Content Delivery Network
- Yahoo moved their static content from their web servers to a 3rd party CDN company and saw a 20% increase in user response times.
- Add an Expires or a Cache-Control Header
- Refers to an equivalent to our “Strong” and “Weak” cache policies, which we already implement heavily
- Reduce DOM access and the number of DOM elements
- Easy way to get the count of DOM objects on a page: in Firebug’s console, typedocument.getElementsByTagName('*').length
- Reduce Cookie Size
- Choose <link> over @import (Allows for progressive rendering)
- Avoid Filters (such as the IE-proprietary AlphaImageLoader
- blocks rendering and freezes browser while the image is being downloaded
- Applied per element, rather than per image, which only multiplies the above-mentioned problem
- Develop Smart Event Handlers
- Split Components Across Domains where possible
- Pack Components into a Multipart Document – allows you to fetch several components with one HTTP request (iPhone does not support this)
By: Brett McClelland
For most small applications, scalability is usually not something that recieves much consideration. For applications that have potential to grow to tens of thousands of users and up, however; scalability may eventually become a concern.
Many web application success stories owe their scalability to the fact that they are written in Python/Django. It is extremely light-weight, as web application architectures go, and allows for much flexibility. Some of the things that we’ve kept in mind while coding that help with scaling are:
• Minimize external dependencies
• Replace/refactor/migrate components and modules as they become problematic (Python components help to streamline this process)
Emphasize ‘low coupling’ of code bases
• Attempt to localize and modularize failures (try and prevent them from spilling into other modules/applications)
• Limit the number of queries within loops (object.get(), object.filter(), etc.)
• It is much more efficient to fetch all records necessary in one query, and work with the retrieved dataset within a loop, rather than querying once per loop.
• Get rid of all obviously unnecessary leaf services.
• Customize reliable open-source software – bend it to your will.
• ‘psyco’ compiler – specialized Python compiler – extremely optimized
• Processor-heavy functions, or highly-executed functions, can be ‘psyco-ized’
• This compiler is something we have not yet tried using, however some development companies report as much as a 400% performance boost by using it properly.
A few rabbit-holes that developers should avoid running down if at all possible:
• Always be aware of the difference between “fast” and “fast enough”
• Python/Django has many scalability optimizations built right in; implement your functionality and test it under appropriate load-testing environments first, before spending too much time optimizing manually.
• Strive for hardware efficiency, but do not obsess over it
• Do not make the assumption that a technique for code optimization for one language will work for the language you are working in.
• Keep in mind that eventually you will have ‘no cards left to play’.
By: Brett McClelland