IBM Think


26 Jul 2016

Before I started working with IBM’s XPages framework in 2009, I was starting to use AJAX calls in web applications and starting to dig into Dojo charting options for an application. So not unsurprisingly, when I started with XPages I blogged quite a bit about Dojo charts and understandably chose to write the Dojo-related chapter and a half of “XPages Extension Library”. I also contributed a Dijit Tooltip custom control and an extension to the Dojo Legend component, to allow more sophisticated formatting of the legend.

But after my early projects I was already preferring Java as a server-side language to IBM’s proprietary shim on top of Java, Server-Side JavaScript or SSJS as it is commonly known. When it was explained to me that SSJS was compiled as a string and parsed at runtime to call underlying Java methods, it just made much more sense to cut out the SSJS layer, regardless of how daunting Java might seem. The benefits of getting more familiar with Java grew when writing “XPages Extension Library”, to be able to understand what was happening under the hood, and when using more standard Java packages like Apache POI. I began to find a choice appearing, one I saw appearing for more and more developers, between specialising in Java or JavaScript. My background in logical languages and the editor made my mind up towards Java.

Having been a full-stack developer for so long, and a “developer” rather than a “programmer”, my preference is to develop smaller applications with Java access to the back-end database. My preference is also for a Java framework that gives a decent look and feel but lets me focus on functionality. Some will prefer building pretty widgets that give an optimal look and feel, but I am happy to accept a more standard user interface. Many will not agree with me, but the existence of many frameworks leads me to believe that some do. It’s a personal preference, one of many in the world of development.

There are a number of Java frameworks out there, with Spring MVC, Spring Boot and JSF being very popular in this year’s survey by ZeroTurnaround. But Vaadin is in the “chasing pack”. I was introduced to Vaadin by a colleague about 18 months ago and it soon became a firm favourite. Vaadin has been pretty easy to pick up after XPages, with a nice look and feel and component-based approach, as well as being open source. The class and method names were pretty similar to XPages as well as being very self-explanatory. The theming approach also fitted well with what I was used to.

Based on my experience of the last (mumble mumble!) years, documentation and community are also key aspects for me. The documentation is of a high quality with good examples and the certification exam is comprehensive and challenging (I’ve yet to pass it, I tried about a week after I started and failed - I know there are aspects I’m yet to dive into). The community has been impressively open and vibrant, the Vaadin developers and developer advocates have been very welcoming and actively engaged with the community. I was approached late last year to write a blog post on getting started with Vaadin on Domino and the company (not surprisingly) are committed to the product. They also are not shy about recommending best practice and Vaadin Designer structures the files it creates in order to create the best practice separation between UI and business logic. This all makes it a framework that’s enjoyable to work with and minimises floundering with new technology.

The main downside is fighting positioning and CSS, which the forums show is a not uncommon challenge. But the posts also help solve the problems. Vaadin Designer makes some of this easier. It is a fairly new (licensed) add-on (version 1.0 came out last October), currently just for Eclipse although an IntelliJ version is in the works. It’s a good starting point and useful for small layouts, but there is still room for improvement (e.g. interaction with the valo theme when setting styles). As part of the Vaadin Pro Tools, I am sure there will be further enhancements.

Speaking of the forum, it is extremely useful and has typically answered very quickly any questions or challenges I’ve encountered. The Vaadin developers and technical advocates are very active there, as are others in the community.

And speaking of community, there are already a large number of add-ons, some of which I am conscious I need to dive into much more (particularly viritin). Looking at the names of authors, many are familiar as people working for Vaadin, so it’s good to see very active contribution from the developers and advocates. Some seem to reference Vaadin 6 (we’re currently on Vaadin 7), so I’m not sure how active they all are. But the specific categories in add-on releases to licensing, maturity and versions supported are very useful, as well as links to code samples and other related links. After all, the critical requirements for any open source repository of extensions is to make it easy to identify whether a given extension will work with the specific versions you need, make it easy to get a proof of concept into your development environment and give confidence in future-proofing. It’s also of interest to me as an OpenNTF Board Member helping manage an open source repository for projects that have accumulated over a large number of years.

A vibrant community demonstrates a passion for a product. And if the company responsible for that product are engaged with their community, the community response drives them to keep enhancing the product. The community will also enhance and evangelise the product, helping it to grow. A symbiotic relationship between the company and the community is key, and if both are engaged, great things can happen. I’ve seen that over the last few years with XPages, although IBM seems to have disengaged from the development community over recent months. The relationship between Vaadin and the community has impressed me greatly over the last 18 months. With a company whose core business is application development, that should continue providing they are not acquired by a larger company that dilutes their vision. No one can consistently predict the future, but the current vision of Vaadin means it is a development framework I look forward to working with for the foreseeable future.

Posted with : Vaadin