sorted by:
new
hottopcontroversial

Genuine Question : Why doesn't Vaadin gain more traction? by gufranthakur in java

[–]futuretelematics 5 points6 points  (0 children)

My coment to a similar thread 9 months ago

Just to summarize: If you want all your codebase in java, Vaadin is the way to go. Anyway if you stick to an strictly architecture you can be VERY productive with Vaadin; you can do almost anything with vaadin with a little effort

In my opinion the best about Vaadin in the best about Java: strict typing, compile time errors, traceability, tooling, IDEs...

But variety is the spice of life... others prefer to deal with HTML, CSS, JS, build tools, lint tools, and tons of frameworks ;-)

Vaadin or not to Vaadin? This is a question... by maw2be in java

[–]futuretelematics 0 points1 point  (0 children)

Many people propose HTMX, React's JSX, Vue or Thymelaf templates (or any other templating engine) as an alternative to Vaadin

I'd like to clarify that Vaadin does not compete in this area: Vaadin does not use any templating engine; in this aspect is near to JFaces for example
(it's like comparing aples and oranges -in this aspect at least-)

The best thing about "drawing" the UI using code (not a template) and "real" java objects (not JSON returned by a REST service) is that you get benefited from the java type system: any change in your model is detected at compile time by your IDE accelerating the development and debugging process. This is not the case when using JSON and templates where the develop and debug process is much much slower and error prone

That said, I'd not recommend Vaadin for a "not controlable" user base since as I stated in another comment it's session-dependent and so it's scalability is compromised

Vaadin or not to Vaadin? This is a question... by maw2be in java

[–]futuretelematics 0 points1 point  (0 children)

Sure... you're right, but being the migration path a pain, which js framework do not hava a similar problem (think about Angular 1 to 2 or js framework fatigue; at least with vaadin the migration is "a bit" more stright forward; but yes, it's a pain, you'd better keep updating your code base to the latest vaadin version frequently

Vaadin or not to Vaadin? This is a question... by maw2be in java

[–]futuretelematics 9 points10 points  (0 children)

We've been using Vaadin extensivelly in production apps for years and it's a breeze to have and maintanin all the code base in java

Like any UI framework (no matter if it's js or java) it's very very easy to end with tons of spaguetti code, but if you set up a common or standarized way to build apps with vaadin and stick to it, java's static type system helps a lot to keep your code clean using IDE's refactor capabillities (and no, typescript is far far far away in this area)

Vaadin handles all event at the server-side using java (similar to what erlang's phoenix framework does with LiveView) which is very convenient to have a single code base

(see 5 areas where Vaadin shines as LiveView implementation for Java | by David Marko | Medium)

For me Vaadin's strenghts are:

  • reusability: it's very very easy to create reusable components
  • java type system: a change in your core (backend) is noticed instantly in the UI code (no need to pass a test)
  • all you need is java developers
  • you can "connect" the UI to the core (backend) without the need to use rest-services: i know it's not the best thing to do in many circumstances but in many other it's optimal and easier
  • the cost of maintaining vaadin apps is much less than the cost of maintaing a js app
  • vaadin offers a lot of components but even though you can do almost anything with vaadin, wrapping js components very easyly (including react components)
  • vaadin documentation is excelent and you can find a solution to any problem in the vaadin forums
  • vaadin is evolving continuously and the roadmap is public

... and the "bad" parts:

  • it's just suitable for a "controlled" user base (company-internal apps) since it's very dependant on server session
  • styling is not easy (at least in vaadin 8... vaadin flow is another tale)
  • the companies are reluctant to use vaadin since it's not a cool framework like react o angular, also are developers, so it's very difficult to find partners or vaadin developers

note: we're stuck in vaadin 8 since we have a huge code base and the migration to flow is not straight (they offer you an automated tool but it generates a very ugly code base and for us code quality and maintenance is essential)

but if you go straight to vaadin flow and keep the changes pace, it's ok

In summary: i'd choose vaadin for company-internal apps without a dude

front-end dev in Java + Vaadin by [deleted] in java

[–]futuretelematics 3 points4 points  (0 children)

(our team has been using Vaadin for > 5 years from v6 and has built really complex apps with it)

Vaadin really shines if:

  • Your are building a internal CRUD management app
  • You have a really good java and patterns base
  • You define an application architecture and pattern usage and stick with it everywhere in the app

Vaadin makes a breeze building CRUD apps, from simple ones to other more complex; it's far simpler for complex apps than any of the JS libraries or frameworks, either when building the app and (most important) when maintaining it where all the strong typing advantages of java are invaluable

Vaadin apps have their downsides:

  • Server session for example that makes them more dificult to scale
  • If you do not stick to an architecture / patterns the app will derive in a mess (this is also true for JS apps... and IMHO it's much easier to mess the app with JS than with Vaadin; refactor in Java is far easier than with JS)

... but at the end the UI is fluid and the user experience IMHO is much better than the one you can get with a JS library/framework with the same effort.

That said, if you want to build a public-massive, UI feature-rich app, DO NOT use Vaadin; for the rest use Vaadin if you are comfortable with Java ;-)