There are some things that I don’t like about the regular Vaadin SplitLayout, like that I can’t set split position in pixels, and can’t have more than 2 children.
So, as one of my first experiments with Claude Code, I asked it to create a SplitLayout web component with Vaadin integration, and after just a few more prompts I now have something that seems to fits my needs perfectly.
This leaves me with some questions
Does things like this still have any value to share, when everyone can generate their own?
Does it have any value to fill GitHub with AI generated code?
Why should I now spend time trying to get Vaadin to improve their SplitLayout?
I’d still prefer a proper Vaadin version, written by someone who understands TS/JS (I don’t) and maintained, but the path of least resistance is to just roll my own and not share, especially if share also means supporting it.
Here I have it running in my app with 3 SplitLayouts, where 2 of them have 3 children:
Outer layout with menu, screen, [sidebar]. Sidebar is added/removed on demand. When window is resized, only the Screen area is resized, since the other two have size set in pixels.
These are good questions and you are not the only one asking. And to some extent the questions did exists even prior to GitHub Copilot and Claude Code.
There has been always lot of personal taste related wishes regarding Vaadin components. Despite some of them have really bloated API like Grid for example, there is always demand for more customization options (naturally without extra hit in performance). This demand has been partially been satisfied by community add-ons in Directory. There is bunch of ComboBox / Autocomplete / AutoSuggest variants there amongst many other things that add functionality Grid etc. Directory has been an important playground and we have been picking the popular features to the framework.
AI generated code can be of different quality. It does not make much sense to fill GitHub with low standard code. But if you are able to generate a good baseline and then polish it to be of decent quality why not. And naturally it would be welcome as Directory add-on. The maintenance obligation is also something that varies. I would be mention clearly in README.md, that the repository and add-on is not actively maintained, or future development is based on community contributions. This is for each and everyone to define themselves.
So AI coding agents are here a double edged sword. It can lower the barrier to contribute to Vaadin ecosystem, but works only if the contributors have reasonable degree of self moderation. We would welcome all novel ideas, but if the Directory is bloated with AI slop, multiple copies of the same thing, etc., it is becoming harder to find the useful things from there. The same applies to contributions to framework. I know that some popular open source libraries have already stopped accepting PRs, becuase of abuse. That is really sad.
The irony here is that the maintenance aspect is also the reason why we are careful with accepting suggestions. In that sense, and add-on has an easier time than official Vaadin features that we promise to maintain for 15 years.
As a very tangible example, the official split layout has “primary” and “secondary” as explicit concepts in the API which makes it quite challenging to even consider adding support for more children without also causing breaking changes to the API (or introducing some weird trade-offs).
It seems like we’re heading towards a world where requirements are much more important than implementation. I don’t mean just a list of all potential things that should be possible but also a conceptual model for how different requirements interact with each other and explicit trade-offs around potentially conflicting requirements. On top of this comes careful API design to help users understand the conceptual model and avoid any potential gotchas caused by conflicts between different requirements.
While the main value lies in the requirements and the design, I often feel that the most efficient way of expressing those concepts is through an actual implementation where they are embodied. So yes, I think there’s value in sharing useful requirement designs and that it’s useful to share in the form of an actual implementation, regardless of whether that’s written by hand or generated by an AI.
