We have a beautiful in-house icon set Vaadin Icons https://vaadin.com/icons. One of its design goals has been to offer a drop-in replacement for FontAwesome, without the bloat, with additional useful icons for web applications.
For some reason, we're still using FontAwesome as the Framework's built-in iconset. Now that we're making a major release, we should take the opportunity and replace FontAwesome with Vaadin Icons. We should still repackage FontAwesome as an add-on, so that migration from FW7 to FW8 would be as easy as possible from icon set's point of view. This would allow us to maintain a more up-to-date version of FontAwesome as well, as add-ons are easier to update.
There’s a community add-on that should be a drop-in replacement, which is actually being kept up-to-date with FontAwesome updates.: https://vaadin.com/directory#!addon/fontawesomelabel
I support this change. Now its up to PD to tell us if/when this can be done during 8.0.0 beta cycles.
I do not completely agree with this, icons are a constantly growing source of elements which needs to be constantly updated and worked on, and Font Awesome is a reliable provider for that (like Atmosphere is for websocket, for example). I would not underestimate the effort needed to maintain a icon library for web applications.
BTW, I'll hope FontAwesome add-on will be keep updated with the latest FA releases, now that FA 5.0 is being developed and will introduce several breaking changes.
Thanks for the feedback @heruan, much appreciated.
One of the reasons to remove the FontAwesome directly from the core is to allow it to be updated more frequently and with less heavy process as the main framework itself. This has at least been a problem for many of our users in the past, that our bundled version is not up-to-date, and they are forced to work around it. So it would basically be more inline with what you ask for (“to be constantly updated and worked on”).
This actually applies to most of the things bundled in the core, that they would be easier to maintain as separate dependencies, and we would be faster to deliver value to you in the more modular way. There’s a lot of historical reasons why we aren’t doing it that way today, and some political reasons why we aren’t going completely in that direction either. And bundling Vaadin Icons instead is mostly a “political” decision, as we want to promote that and make it really easy for our users to start using that.
It might be that we would like to adopt the community maintained add-on as an official add-on (and if @bdunn44 would be willing to donate), but I don’t think that’s necessary initially.
How much trouble is it to use an add-on for the icons in your opinion? I agree you lose some convenience, but at the same time you gain more control over the exact version of the icons you use.
And just to reiterate what Hannu said, there’s also a clear user value from the switch: “One of [Vaadin Icon’s] design goals has been to offer a drop-in replacement for FontAwesome, without the bloat, with additional useful icons for web applications.”
I completely agree with you @jouni and your response reveals all the pieces of the strategy that I was missing. Answers like this + all the work on Vaadin 8—which is transparently discussed and committed here—are strong and valuable facts that support our decision process on the adoption of Vaadin for enterprise projects next year.
In my opinion there's little to none trouble using add-ons, as long as they adhere to the quality standards of Vaadin.
I'm absolutely willing to donate the add-on.
@heruan makes a great point - FA 5.0 will require significant changes. Vaadin development is frankly on the back-burner for me at the moment, so code contributions would be welcome.
Most helpful comment
Thanks for the feedback @heruan, much appreciated.
One of the reasons to remove the FontAwesome directly from the core is to allow it to be updated more frequently and with less heavy process as the main framework itself. This has at least been a problem for many of our users in the past, that our bundled version is not up-to-date, and they are forced to work around it. So it would basically be more inline with what you ask for (“to be constantly updated and worked on”).
This actually applies to most of the things bundled in the core, that they would be easier to maintain as separate dependencies, and we would be faster to deliver value to you in the more modular way. There’s a lot of historical reasons why we aren’t doing it that way today, and some political reasons why we aren’t going completely in that direction either. And bundling Vaadin Icons instead is mostly a “political” decision, as we want to promote that and make it really easy for our users to start using that.
It might be that we would like to adopt the community maintained add-on as an official add-on (and if @bdunn44 would be willing to donate), but I don’t think that’s necessary initially.
How much trouble is it to use an add-on for the icons in your opinion? I agree you lose some convenience, but at the same time you gain more control over the exact version of the icons you use.
And just to reiterate what Hannu said, there’s also a clear user value from the switch: “One of [Vaadin Icon’s] design goals has been to offer a drop-in replacement for FontAwesome, without the bloat, with additional useful icons for web applications.”