Building components on top of Polymer

We at Vaadin have always been committed to creating great UX for businesses and helping developers build modern web apps. We’ve always strived to create better tools and components for all web developers. So in the past few years we’ve invested into Google Polymer as the library for building our next generation of components. By building with Polymer, we reach a wider community of business and hobbyist web developers.

Last week we attended the Polymer Dev Summit in London, a two day event of talks, codelabs, and conversations about Polymer and web development. Developer Advocate Marcus Hellberg and Vaadin Elements Product Owner Jouni Koivuviita gave a talk on why Polymer and Web Components make sense for businesses. 

At the event we met with quite a few people and businesses building apps with Vaadin Elements. There’s nothing quite as powerful as direct feedback from our customers. We love hearing from developers working with Vaadin Elements so we can learn from their experiences and make a better product.

We talked with many developers, and there were a few recurring topics about Vaadin and Polymer. I spoke with some of our Elements engineers to answer these common questions.

Why did Vaadin decide on web components with Polymer?

Back in 2014, Vaadin was considering a new way to reach web developers. We wanted to create components that follow the web standard, so that they’d live forever; we wanted to create components that are simple to use with any framework, so that all developers can build with them; and we wanted to create native web HTML and Javascript to decouple UI components from the server-client communication automation that Vaadin Framework provides. After considering different options, Vaadin made the decision to develop a new set of open source components based on the new Web Components Standards coming to browsers, with Polymer as the definitive choice.

Vaadin values simplicity and usability, so by working with standards instead of close frameworks, we make it easier for all developers and designers to use our Elements. At the same time, we have always believed that by making our products truly open source, we can get more feedback and build better UX faster.

Will Vaadin Elements switch to Polymer 2.0?

Yes, we’re going to make Vaadin Elements work with Polymer 2.0, which is the next version of the Polymer Library. Polymer 2.0 will use the latest web standards, and is faster and smaller. All of these benefits will come down to all of our Vaadin Elements users!

Vaadin Elements will wait until Polymer 2.0 is stable to create a full release, but we’ll probably build Polymer hybrid elements, which will be a compatibility layer between Polymer 1.0 and 2.0. Stay tuned to this blog and we’ll give you updates on Vaadin Elements progress.

Learn more information on Polymer 2.0

What have we learned from developing with Polymer?

We’ve learned that developers switch technologies quite often. Many technologies try to solve the same problems with different philosophies. Whether it’s by layers of abstraction, level of control, declarative vs imperative: frameworks and libraries vary so much. We’ve learned that we need to be able to adapt our components to work in many different environments, and one way to do that has been to embrace the web platform and Web Components. It has been a challenge for us to change out thinking from the classical imperative model to the declarative model of Polymer, but we met the challenge to better connect to the many ways people might use or products.

We still have a lot to learn about the ways people build for the web, which is why we were so happy to go to the Polymer Summit and talk face to face with developers using Vaadin Elements. We welcome feedback in person, on our Gitter, and in our forums.

What’s next?

The Vaadin Elements team has learned quite a bit from the Polymer Dev Summit, especially after giving our talk and talking with so many developers who build with Vaadin Elements.

The Elements team is hard at work on the next set of Vaadin Elements. Keep following this blog to hear more about where we’re going next and how we’re learning from you.

Vaadin Elements Team at the Polymer summit, sporting our great new t-shirts
Vaadin Elements Team at the Polymer summit, sporting our great new t-shirts

Learn more about Vaadin Elements

jOOQ and Vaadin: Lowering the Cost of Infrastructure Work

I had the pleasure of talking with Lukas Eder, Java Champion and member of the board of the Java User Group Switzerland. Lukas has been a speaker at many Java conferences, such as Geekout, Geecon, and Devoxx, for many years. He also is the founder and CEO of Data Geekery, the company behind jOOQ, a framework that, I would say, matches the philosophy of the Vaadin framework. Let’s find out his thoughts about it.

Hi Lukas, thanks for accepting the invitation. So, let’s get right to the topic... Can you tell us about jOOQ? How does it work? When is jOOQ a great option?

jOOQ models the entire SQL language as a fluent Java API, i.e. it is an internal domain-specific language. In essence, it’s “just” type safe JDBC, so whatever works in SQL/JDBC will also work in jOOQ, except that your Java compiler can type check both your SQL syntax and your database schema. An example:

  .select(ADDRESS.COUNTRY, count())

This is a very simple query counting the number of customers per country. jOOQ users use jOOQ for simple but also for extremely complex SQL queries with thousands of lines of type safe SQL in Java. Imagine a huge statement and now some developer renames a column. The huge statement will no longer compile and the Java compiler will immediately show what the problem is.

When executing the above query, jOOQ can translate the standardized SQL statement to any of the currently supported 21 RDBMS dialects, while still providing the full power of standard and vendor-specific SQL.

There are lots of additional features in jOOQ (such as SQL AST transformation), but in short, jOOQ is type safe JDBC and it’s great for anyone who wants to tightly integrate with their RDBMS, making SQL a first class citizen in a data intensive application.

Some developers might think that it's better/safer to use JPA because it’s "standard". Any thoughts about this?

I don’t think you can compare jOOQ with JPA on a mere technical level. jOOQ is more like JDBC – an SQL API. JPA solves the object graph persistence problem which has nothing to do with SQL. Unfortunately, many people default to JPA because they don’t want to do JDBC. That’s a shame, because SQL is an awesome language, but JDBC just doesn’t make it that awesome for Java developers.

Standards arguments make total sense in some environments where compliance is important, but like Vaadin, jOOQ is used by a large community of developers. Different surveys estimate jOOQ to hold between 2% – 8% of market share compared to JDBC, JPA, MyBatis, and all the others. So, jOOQ is the de facto standard for type safe embedded SQL.

Also, jOOQ is an extremely simple library, which is Open Source and very easy to extend. Remember, it’s just type safe JDBC. This means that you don’t really write jOOQ code, you write SQL, which is itself an ISO standard – a much more important and more popular standard than JPA, by the way. There are many libraries similar to jOOQ because type safe embedded SQL has always been the dream of many Java developers. Even JPA has a similar API, which is called Criteria Query. It only works for JPQL though, not for SQL. This is where jOOQ comes in. It offers a type safe embedded SQL API for standard SQL.

What’s the "killer feature" of jOOQ?

The killer feature is the mindset that jOOQ enables and encourages in developers. jOOQ makes developers extremely productive, because it is very well integrated into the Java language and into data centric architectures, for example architectures that make use of Java 8 streams. It makes SQL a first class citizen in Java (which it should be).

Once developers start using jOOQ, their applications become much simpler, leaner, more fun to write and maintain, less error prone, and thus more valuable for their customers. That should be *the* killer feature of every technology.

jOOQ makes it possible to use Java for your SQL queries, a bit similar to how Vaadin makes it possible to use Java for your HTML UIs. Sounds like a good match, doesn't it?

Absolutely. Both frameworks “wrap” external languages / technologies (HTML, SQL) in a way for those languages to become more native to Java developers. While Vaadin is built for the web, jOOQ is built for relational databases.

An ideal database backed web application would use jOOQ to run sophisticated SQL statements, Java 8 to transform data streams into Vaadin UI objects, and Vaadin to display database output to the user.

In such an architecture, developers could lower the cost of infrastructure work (bridging HTML+Java, bridging SQL+Java) by using two APIs that solve all of these infrastructure problems.

What can you share about the future of jOOQ?

Much like SQL, jOOQ has a bright future.

We’re currently working on an SQL parser that can parse any SQL dialect and with the existing jOOQ feature set, translate (and optionally: format) an SQL string to any other SQL dialect.

We’re going to add more features in the DDL space, to help users write type safe schema migrations similar to Liquibase, but in a much more general and complete way.

We’re experimenting with temporal validity and the emulation of the SQL:2011 standard syntax into databases that do not support this feature.

Also, we’re here to help our users write better SQL. This is why we blog at and why I talk a lot about SQL at Java conferences (I’m always the only one!) and deliver SQL trainings to Java shops.

Anything else you would like to say to the Vaadin developers evaluating backend technologies?

Do check out jOOQ. jOOQ makes SQL feel the way it should have always been: a part of Java. Once you’ve tried jOOQ, there’s no looking back. You’ll write awesome SQL whenever you can, because it’s a lot of fun and very productive! 

Thanks Lukas for sharing your knowledge. Keep being so awesome for the Java community!

Read the guide and try jOOQ with Vaadin

Getting started with IntelliJ IDEA and NetBeans

The latest Vaadin Community Survey showed that Eclipse is still the most used IDE to develop Vaadin applications. IntelliJ and NetBeans, nevertheless, make a not negligible 40% of the share:


Most content out there is tailored to Eclipse users, and although Vaadin is IDE-agnostic, I figured it’d be worthwhile to show how simple it is to set up IntelliJ IDEA and NetBeans with Vaadin. You can find these new videos below and also in the getting started page.

So, if you are a visual learner, watch the videos, try them by yourself, and let me know in the comments section what else you would like to see in future videos.

Getting started with Vaadin in IntelliJ IDEA

Getting started with Vaadin in NetBeans

Subscribe to the Vaadin YouTube Channel