PrimeFaces VS Spring Boot

> I use Quasar and Vue. This is my hammer for all nails, no matter the size of the nail.

Vue is great, especially with their Composition API (https://vuejs.org/guide/extras/composition-api-faq.html#why-...) and something like Pinia for state management, without the hassles of something like Redux: https://pinia.vuejs.org/

As for components, I really liked the idea behind PrimeVue/PrimeReact/PrimeNG/PrimeFaces (https://www.primefaces.org/) because I'm not aware of any other attempts of creating components that actually work similarly across different frameworks/libraries and it's really good because your skills carry over pretty well if you ever find yourself exploring a slightly different stack.

For what it's worth, the components also work decently (there's a whole list https://primevue.org/autocomplete/) and look okay (with various themes available, https://primevue.org/theming/), plus you can get examples (https://blocks.primevue.org/). Oh yeah, they also have their CSS utilities (a bit like Tailwind, https://primeflex.org/installation) and icons (https://primevue.org/icons).

I actually look forwards to the day where most of these concerns are less of an artisanal craft but rather a set of boring and well known things that just work well for quickly putting together a CRUD or whatever you need.

That said, I also explored VueRequest for handling network requests a bit more easily (https://www.attojs.org/guide/gettingStarted.html) and VueUse for stuff like LocalStorage (https://vueuse.org/guide/) and while it doesn't feel like I'm building a crappy alternative to Vuex and the complexity is reasonably manageable and the usability present, occasionally it all still feels a bit annoying to deal with - reactivity, ways to shuffle around data that I get from the back end, props, various bugs... so it's not all good, but still less complex than some of the things I've seen with React or Angular.

Visit the changelog for the complete list of changes.

Used this years ago for JSF apps https://www.primefaces.org/ I know they've kept it updated for current angular/react/vue JS front ends, but I've never used those. Might be worth a look.

It might be related to this

PrimeFaces (PrimeFaces official page has implementations for Angular, React and Vue)

> I'd like to hear any strategy one has to deal with that. I have taken up Figma and Sketch so I can meet them "where they are" but still, plenty of disagreements can happen.

One option would be to use a premade design system or a component library/framework that gives you a consistent look and feel, most of those design decisions having a good enough baseline. Then just add a color theme and some branding on top of it and call it a day. It will also increase your development velocity and save you from some pixel pushing.

For an example of this, consider PrimeFaces: https://www.primefaces.org/

They have working components that are good enough (and support multiple themes, if need be), their own icon solution and also a CSS utility library, including stuff like layouts. For most projects it'll be enough to create something that works and looks okay.

> A UI library for React, Vue, Svelte, Solid, whatever... Imagine being able to have a component library that works with any of them (or none of them).

That seems to be a worthy goal, but I don't see that being usable in prod projects, at least not in the near future.

The closest I've seen is something like PrimeFaces, which has components for Angular, React and Vue, which is the majority of projects I've seen out there: https://www.primefaces.org (I've also used the Java JSF variety, it was... sometimes problematic)

If you need something that works the same (or as close as you can get) across multiple front end frameworks/libraries, while still having most of the components you could possibly want, I don't think there are many other options out there.

For example:

- Angular calendar: https://www.primefaces.org/primeng/calendar

- React calendar: https://www.primefaces.org/primereact/calendar/

- Vue calendar: https://www.primefaces.org/primevue/calendar

I liked Prime ( https://www.primefaces.org/ )

- Usually manually wired and configured vs the spring boot "starter" pattern of having libraries that automatically do some of the manual setup work for you: https://github.com/spring-projects/spring-boot/blob/main/spr...

I wish more client library sets had the feature-matrix that the pulsar one does, because in practice most end up being the same: Java supports everything because it's either built in the same codebase or is the most used client and gets the most support, while the dotnet client codebase has many feature-requests or performance improvement issues, often leading to a "third-party client" being created.

https://github.com/spring-projects/spring-boot/pull/39754/co...

If you’re currently running with an earlier version of Spring Boot, I recommend that you upgrade to Spring Boot 2.7 before migrating to Spring Boot 3.0. It minimizes compatibility issues as much as possible.

Okay, we need to build the game? No problem, we will use Spring Boot and Swing!

It's weird that some people including you directly attack my competence. As a power user you should have plenty of experience getting something to work that is not properly document, does not work how the documentation promised it to, or has weird problems on top of it. Look at idiotic things like this:

https://github.com/spring-projects/spring-boot/issues/33044

Take any similar issue and you'll see a bunch of people who try to find a solution for them because they just aren't repeatable at all. The underlying issue is the auto configuration doing things you can't follow quite properly. It's like it wasn't mean to be understood. Issues like the one I linked above also show me that the spring dev crowd also doesn't understand the ecosystem anymore. The problem is complexity and automagic.

An interested reader can decide for themselves:

https://github.com/spring-projects/spring-boot/tree/main/spr...

Explicitly decoding URL query parameters occurs less often because many frameworks, including Spring Boot, handle decoding automatically.

https://aws.amazon.com/lambda/ https://aws.amazon.com/api-gateway/ https://aws.amazon.com/serverless/sam/ https://aws.amazon.com/cloudformation/ https://aws.amazon.com/s3/ https://spring.io/projects/spring-boot https://start.spring.io