Tag Archives: browser

Choosing Between Vaadin and JSF

With the recent release of Primefaces 3.0, JSF finally reaches an unprecedent level of maturity and utility that puts it face to face with other popular Rich Internet Applications (RIA) options, such as Google Web Toolkit (GWT), ExtJS, Vaadin, Flex and others. This open source project also proved to be very active and in a constant growing path.

I have been working with JSF + Primefaces since October 2010, when I started developing the project JUG Management, a web application conceived to manage user groups or communities focused on a certain domain of knowledge, whose members are constantly sharing information and attending social and educational events. JSF is a standard Java framework for building user interfaces for web applications with well-established development patterns and built upon the experience of many preexisting Java Web development frameworks. It is component-based and server-side user interface rendering, sending to clients (web browsers) pre-processed web based content such as HTML, JavaScript and CSS. My experience on this technology is openly available on java.net.

Meanwhile, I had the opportunity to create a Proof of Concept (PoC) to compare JSF and Vaadin in order to help developers and architects to decide between one of them. Vaadin is a web application framework for RIA that offers robust server-side architecture, in contrast to other Javascript libraries and browser plugin-based solutions. The business logic runs on the server while a richer user interface, based on Google Web Toolkit (GWT), is fully rendered by the web browser, ensuring a fluent user experience.

The result of the PoC was surprisingly interesting đŸ™‚ It ended up proposing both technologies instead of eliminating one of them. I found out, exploring available books, articles, blogs and websites, that despite being able to implement all sorts of web applications, each technology has special characteristics, optimized to certain kinds of those applications. In practical terms, if we find out that JSF is better for a certain kind of application, that’s because it would take more time and code to do the same with Vaadin. The inverse logic is also true. In order to understand that, we have to visit two fundamental concepts that have direct impact on web applications:

  • Context of Use considers the user who will operate the application, the environment where the user is inserted, and the device the user is interacting with.
  • Information Architecture considers the user of the application again, the business domain in which he or she works on and the content managed in that domain.

Notice in the figure bellow that the user is always the center of attention in both concepts. That’s because we are evaluating two frameworks that have direct impact on the way users interact with web applications.

Visiting the concepts above we have:

Environment
Some applications are available for internal purpose only, such as the ones available on the intranet, other applications are used by external users, such as the company website.

Users of internal applications are more homogeneous and in limited number, which means that the UI can be a bit more complex to allow faster user interactions. That explains the fight Microsoft Office vs. Google Docs. The last one is not yet fully acceptable in the office environment because it has less functionalities than Microsoft Office. The latter is, on the other hand, more complex and more expensive. However, a limited number of users to a larger number of features makes acceptable to have some additional costs with training sessions to profit from the productivity features.

A company website targets heterogeneous users in unlimited environments. It is not possible to train all this people, thus simpler user interfaces with short and self-explanatory interactions are desirable.

Considering the environment, we would recommend Vaadin for homogeneous users in limited environments and JSF for heterogeneous users in unlimited environments.

Device
Different devices demand multiple sets of UI components, designed to look great from small to large screens. Fortunately, both frameworks have components to support the full range of screen sizes from regular desktops to mobile devices. The problem is that different devices bring different connectivity capabilities and the application should be ready to deal with short band-width and reduced transfer rates. In this case, Vaadin seems to be more suitable for multiple devices, as long as the variety of devices is not so extensive, because the user interface is rendered locally, using JavaScript, and it has a richer Ajax support to optimize the exchange of application data with the server.

Business Domain
In principle, good quality UI frameworks such as JSF and Vaadin can implement any business domain. The problem is how experienced the team is with the technology or how small is the learning curve to master it. Business is about timing and the technology that offers the best productivity will certainly win. If your team has previous experience with Swing then Vaadin is the natural choice. If the previous experience was more web-oriented, manipulating HTML, CSS ans Scripts, then JSF is recommended.

Content
Content is a very relevant criterion for choosing between Vaadin and JSF. In case the application needs to deal with volumous content of any type, such as long textual descriptions, videos, presentations, animations, graphics, charts and so on, then JSF is the recommended over Vaadin because JSF uses a web content rendering strategy to profit from all content-types supported by web browsers without the need for additional plugins or tags. The support for multiple content is only available on Vaadin through the use of plugins, which must be individually assessed before adoption.

User
Last, but not least, we have the user, who is the most important criterion when choosing a UI framework. We would emphasize two aspects:

  1. The user population: the largest is the target population the highest are the concerns about application compatibility. It must deal with several versions and types of browsers, operating systems, computers with different memory capacity and monitor resolution. All these without failures or security issues. For larger populations, the most appropriate technology is the most compatible one in a cross-platform environment, which is the case of JSF, since it uses a balanced combination of HTML, JavaScript and CSS, while Vaadin relies only on JavaScript and CSS. But shorter populations would have better profit with Vaadin because cross-browser compatibility is and will remain being a very hard work to be done by Vaadin’s development team behind the scene.
  2. User’s tasks: If the application is intensively operated by users then it is expected that it has more user’s tasks implemented. On the other hand, if the application is rarely used or has short intervals of intensive use, then there is a lower concentration of user’s tasks. According to the PoC, Vaadin is the technology that provides the best support on delivering user tasks with richer user interaction because of its fast visual response. JSF is less optimized on which concerns the user interaction.

In conclusion, instead of discarding one of these frameworks consider both on the shelf of the company’s architectural choices, but visit the criteria above to make sure that you are using the right technology to implement the expected solution. A simple way to apply those criteria would be to assign weights to each criterion, according to the project’s characteristics; set which technology is appropriate for each criterion; and sum the weights for each technology. The highest weight elects the technology to be used in the project.

Applets are not surviving, they are restarting!

A long time ago, I had used Applets in the Planexstrategy application to render statistical charts, such as bars, lines, pizza and so on. I developed these charts by myself and they were perfectly suitable for the system’s needs.

Unfortunately, Sun Microsystems and Microsoft got into a patent fight and the first serious consequence was that Microsoft stopped distributing the Java Virtual Machine as a plug in of the Internet Explorer :(. Actually, after this disagreement, to distribute the JVM became very difficult for three reasons: first, Java was not widely known by non-technical people, thus they don’t know about the existence of a certain JVM. Second, even if they know what is a JVM, it is very heavy to download it, considering the lower internet speed at that time, and also difficult to install. Third, a concurrent technology called Flash, created by Macromedia Inc. (Incorporated by Adobe nowadays), entered into the game to definitively kill the need for Applets in the field of interactive web pages.

The applet adoption had gone to a critical situation with the advent of a set of technologies under an umbrella called Ajax. The combination of HTML, XHTML, XML, SVG, JavaScript, SCC, XSLT, canvas and the main catalyst, XMLHttpRequest, allows the development of dynamic content without needing to refresh the whole web page. Now, the web page can adapt itself according to the user behavior. The problem of this model is the incompatibility of an Ajax code between web browsers, like Microsoft Explorer, Firefox, Opera, Safari and others. Every code should be tested with all of them before the production phase and it takes a lot of time.

To address this problem, people started to develop frameworks, previously tested with all those browsers, offering a large set of widgets to be easily used on the web development. Google Web Toolkit (GWT), Yahoo User Interface Library (YUI) and Direct Web Remoting (DWR) are the main frameworks currently adopted. The problem now is the ability to add new components according to specific needs of the software. It’s too complicated for most developers to change a framework that mixes so many technologies. It is also difficult to be aligned with future versions of these frameworks.

Parallel to this revolution, the Flash technology has gained more and more attention with the possibility to create interactive applications on the web with the flexibility of a full featured scripting language, the Action Script. They saw an opportunity on the browser incompatibilities and created Flex to simplify the development of interactive web applications. In addition, they introduced Adobe Air, a runtime to execute Flash application directly on the desktop.

Flex and Air are technologies that show the future of web applications. Future? Well, the idea behind Flex was available on Java Applets for years! We can develop high quality web applications with incredible features using swing. With the availability of the web today, Applets are not valued just because of marketing reasons. Sun Microsystems just stopped to promote Applets.

However, in JavaOne’08, Sun brought a very important news: Applets will implement the JavaFX technology and the development of interactive applications will become even more efficient and gorgeous! It will simplify even more the model proposed by Flex + Air. Watch the video below and see what I mean!

Firefox wants to achieve the Download World Record

It’s a fact Firefox has become the most used web browser nowadays. I’m using it right now and there is 79% chances you are using it too, according to my blog statistics. I don’t have expressive numbers to show (that’s the reason I’m not using Google Advertising yet), but at least 237 visits came from users using Firefox in the last 15 days.

Now Firefow 3 is coming with dramatic improvements, but it is still in beta version, which allows you to navigate comfortably, but not to use all its plug-ins, since they are incompatible with the current implementation.

These days, the Firefox community started a promotion to achieve the greatest number of downloads within 24 hours. The idea is to break the world record and be part of the next edition of the Guinness Book.

Read more about it at http://www.spreadfirefox.com.