Modernize VaadinIcon icons

[stefanuebe]

Describe your motivation

The current set of Vaadin icons looks outdated and is rarely used even by ourselves. On the other hand it is built in and the first address for new devs to use, when they want to have icons in their application.

The current way of integrating other icons is either search the directory or implementing your own icon set, which is extra effort and thus not really #ffs.

Describe the solution you'd like

With Vaadin 8 we used font awesome icons to provide a neat looking set of icons. We should replace the Vaadin icons with an up to date icon library like Line Awesome or Google Material Symbols (if the respective license allows that kind of usage of course).

I would not extend the current enumeration, but only replace the icons. If for some reason icons cannot be replaced, it should keep the old VaadinIcon to prevent breaking changes.

Describe alternatives you've considered

Using the icon set generator and generate a enum.

Additional context

[rolfsmeds]

There have for a few years now been plans to replace VaadinIcons with a modern, third party alternative.

However, it also feels a bit questionable to have a rather bulky icon set included in the default bundle (we have that now with VaadinIcons, and they take ~300kB; a new third-party icon set is likely to be even bigger), especially for projects that choose to use another icon set.

So one option would be to not include any icon set by default, and instead encourage developers to use whatever third party icons they like.

You mentioned the icon set generator, but that's a V14-era thing. Since V24, it has been possible, and quite easy, to use any third party icon set, as individual SVGs, SVG sprites, or icon fonts: https://vaadin.com/docs/latest/components/icons#using-third-party-icons.

That means using strings to refer to icons, of course, which is suboptimal for DX, or at least the initial dev experience. AI dev tools could easily generate an enum for it, and we could add a feature for it in Copilot, but a third possibility might be to include a new command-line tool for it.

[stefanuebe]

Sure, we should of course only ship the icons we provide via enumeration. I thought I had written that, but appearantly I left that part out. So if we take Line Awesome Icons and it would come by default with 10k icons, we should of course only ship the 200 icons, we use in our enumeration (numbers are just for example purposes, I don't know the exact numbers :) ).

I dont think that we should remove built in icons, for exact that reason. For most cases the VaadinIcon enumeration provides all the icons you need. Without it every application would have to specifically serch for the common icons, hand pick them, create an enum, because using the whole icon set at once would blow up the frontend bundle and also a potential enumeration (I tried to generate an enum from some lib before and it led to "too much enum items" compiler issues).

#ffs

[rolfsmeds]

Right, so that would mean creating a subset of the chosen icon set, which is certainly also an option.

I actually think we could have a set even narrower than VaadinIcons, which ended up including a lot of project-specific icons that don't make any sense in a generic icon set. I think VaadinIcons has approximately 600 icons in total, and we would probably be fine with 200 or even just 100. (LumoIcons used in Lumo has ~60.)

We could also consider leaving the icons outside of the dev bundle entirely, and making them opt-in, to further shrink the bundle size in case you want to use some other set.

The new component base styles and Aura use https://lucide.dev/icons/, so that would seem like an obvious candidate.