Back

Why it’s faster to use Vaadin Designer than write Java

I’ve always been against WYSIWYG editors since the early days of Windows GUI design tools, because I felt that with those tools developing good-looking UIs was slower than writing code. I did some testing to find out which one actually is faster: my fingers and Eclipse auto-complete, or Vaadin Designer. I made a pretty simple form and timed my performance. To my surprise, with Designer I was more than 2x more productive. Here’s a side-by-side video of 9 minutes distilled into 30 seconds.

The declarative format of Vaadin doesn’t add any dirty abstraction on top of my components as I still must implement the event handling and logic in Java code. It is undeniably faster to create Vaadin layouts using Vaadin Designer than writing those in Java. It was quite a surprise to me that my 5+ years of experience in Vaadin doesn’t help me much when competing against the quickness of using a graphical design tool. There are a couple of reasons why using Vaadin Designer is faster than using only Java. Here are the features I found to be the biggest productivity boosts.

True WYSIWYG

The most obvious productivity comes from seeing the changes immediately while editing instead of having to re-deploy changes. Even when using some class reloading tool, you may still need to navigate to the view you changed or have some interaction with the application to see your dialog or form you just modified. Designer uses actual Vaadin layouting so what you see in the Design paper is the same you see in browser. The immediate apply of changes is even more prominent when doing modifications to the application theme.

Layout hierarchy visualisation

It’s pretty hard to keep the component tree as an abstract image in your head. UX designers don’t necessarily know how Vaadin layouting works so the view mockups might not have the correct layout components outlined. Instead, you need to figure out what components to use and try to build a correct layout with only Java API, which usually means some amount of trial-and-error. Having the layout displayed correctly while editing makes it easier to concentrate and deliver correct results without a hassle. Even better if you can teach your design person to install Eclipse or IntelliJ and build the UI for you instead of doing static mockup pictures.

Sizing quick-actions

Vaadin Designer displays quick action buttons for setting a full width or height to a component. It also helps you make correctly behaving layouts by hiding the sizing actions when using those would result in an invalid layout by having a relatively sized component inside an auto size component.

Changing component order is faster in Outline

Using drag-and-drop to position components is faster than writing addComponent even with auto-complete. The effect of drag-and-drop is highlighted even more when reordering components.

It’s not just the big features

There are some other features, too, that make me more productive, for example using copy-paste with components, having paper size presets to help do responsive design and the ability to use split-view when doing SASS changes. In the end, even though Designer has its limitations, I tend to pick it up more often than not. I don’t have to go all-in Designer or all-in Java, but I can mix-and-match and use Designer where it’s best suited - building good-looking layouts fast.

Vaadin Designer
Comments
Add Comment
Thanks for this article. The reason I haven't tried Designer yet, is that I tend to compose the page using multiple levels of reusable components. For example:

- a main layout with top and left nav menu and an area that will display the Navigator views
- the Navigator views would have a title bar component and an area for the view content
- the title bar would have the page title and breadcrumbs on the left and some buttons or a search field on the right
- the content area would be composed of different blocks / sections always with the same margins etc. applied
etc.

So I guess I would need a lot of designs with only very few components in them.

Also, I think the Designer works best if the content is fixed. For example, in the title bar I would define the logic/css for positioning the title, breadcrumbs and right side widgets only once, but the exact content (which title, which widgets) would vary for each title bar instance. I'd rather not make a separate design for each instance.

Please let me know if I'm seeing it wrong.
Posted on 1/11/17 10:06 AM.
If I understood you correctly,I think you got it right, and Designer doesn't seem to fit your workflow. Designer currently kind of forces you to create your UI from bigger "blocks" instead of these smaller pieces.

I would welcome a feature, where Designer would allow creating a master design file to have nested design pieces (not necessarily separate files), where you could define a separate "controller" classes easily for each nested piece. Or something like that, I'm not sure I can explain it well.
Posted on 1/11/17 10:45 AM in reply to Herman Bovens.
Actually the designer (1.2.0.final) is really nice - and for the most cases faster than writing code by hand.

But much more slower in case of refactoring:
component renaming and package restructure is currently no supported, neither for eclipse nor IntelliJ. Refactoring must be done manually by editing the html file (package-mapping entry and tags for the components). This is really a pain.
Posted on 1/16/17 7:04 AM.
Thanks for your comments. I agree with you 100% regarding the refactoring.
Posted on 1/16/17 8:07 AM in reply to Gerald Leeb.