Questions about JHipster, JHipster Lite, and Spring Boot 3
I'm a big fan of LinkedIn. I'm biased because I worked there from 2007-8, have alumni privileges like a free pro account, and learned how to unsubscribe from all their emails over a decade ago.
I communicate with a lot of developers via LinkedIn. I recently received a message from Raymond Meester about the JHipster project. Raymond asked many poignant questions, and I thought it'd be helpful to share my responses with y'all. Of course, I got permission from Raymond before posting this. You can find his blog on Medium.
Hi Matt,
I was reading through some threads on the dev mailing list:
https://groups.google.com/g/jhipster-dev
I'm not part of the dev team, but I thought I just share some of my thoughts with you. 
On the mailing list, there is an interesting discussion about JHipster vs JHipster Lite. Personally, I don't fully understand the debate. In my opinion, there could be one base that could be used for several kinds of generators. Say:
- Catered (default)
- A la carte (lite)
As far as I can see (at least that's the case for myself), I have more use cases for the first than the second. Just a generator with a few questions on what type of application and then the frameworks to choose (like Spring/Quarkus/Micronaut for the backend and Angular/React/Vue for the frontend) is enough in most cases.
Now that I am more experienced, I definitely want to use lite as well. It's an exciting project with some smart choices, but I don't think that it will become the majority of the users.
I do think JHL can be a new base for the normal JHipster as well. Only the generator (whether it's the CLI or GUI) on top of it will be different.
JHL could also provide a simple generator where I have the top three choices for a specific technology. Of course, when the architecture of JHipster Lite is set up well, it will be easy to add other choices (by blueprints) or change the default top 3 when popularity of a frameworks changes.
Currently, as far as I can see, there are two separate teams improving both JHipster and JHipster Lite. Good to try out different directions, but in the end, a waste of resources.
What I currently miss in JHipster (the main project) is regular updates. As an end user, I just want the latest versions when generating a new application, but lately there are huge gaps of three months between releases.
I really would like to see a monthly minor version with just dependencies updates (I understand that there is more to be done for major versions like the transition to Spring Boot 3. But even when nothing big changes it is good to have the latest libraries).
I agree with how Julien originally set up JHipster as simple as possible for end-users. But currently, Deepu seems one of the few that still stresses this point.
JHipster as it evolved is not only practicable to try out different frameworks, but also as a base for further development. Contrary to what seems to be the current belief about JHipster, it's not the speed, ease of use or the choices of generation that is the most important feature, but more that for the generated application the architecture is sound, a lot of best practices are used and the code is clean. This saves so much time for me as developer later on.
I also have a question about JHipster Native now that Spring Boot 3 has arrived. Spring removed the Spring Native library, which is not part of the framework itself. What does this mean for JHipster Native?
Keep up the good work!
This was a heavy message to receive early on a Tuesday morning. It was heavy because Raymond's questions were exact, and I thought they deserved a similar response.
> Currently, as far as I can see, two separate teams are improving both JHipster and JHipster Lite. Good to try out different directions, but in the end, a waste of resources.
Possibly, but as far as I can tell, the same people aren't working on the same project. I believe that JHipster Lite was created because Pascal and others understand Java better than JavaScript, and they were lost in the JHipster codebase and wanted a Java version. JHL also emphasizes DDD and is not interested in CRUD, AFAICT.
In reality, I think many of the contributors have had difficulty figuring out how things work. However, we've always had JavaScript heroes to bail us out. In the beginning, Julien knew everything, so he could fix things quickly. Then, it was Deepu - who has admitted to me he rewrote the JHipster core a few times when he was super active. Now it's Marcelo, and I think he's doing a great job.
I don't really look at the JHipster Lite project. I haven't even watched Julien's video from Devoxx, though I've been meaning to.
Marcelo, myself, and many others have done a lot with JHipster in 2022. I've focused on getting popular blueprints in good shape rather than the core. We've released the Spring Native blueprint this year and updates for Ionic and React Native. There's also been quite a bit of work done on the Quarkus and Micronaut blueprints, and I believe those are just a few hours away from new releases.
> What I currently miss in JHipster (the main project) is regular updates. As an end user, I just want the latest versions when generating a new application, but lately, there are huge gaps of three months between releases.
Three months between releases seems pretty good to me! If you're just looking for dependency updates, you should be able to do some of those in your project w/o relying on a new version of JHipster.
I started updating the JHipster Mini-Book in March of this year, and the current 7.9.3 version is the first version that's bug-free enough for me to complete the updates.
> What does this mean for JHipster Native?
It means it's only necessary for JHipster apps with Spring Boot 2.x. JHipster 8 apps will have native support by default since it's built-in to Spring Boot 3. Related to Spring Boot 3: we started upgrading in late September, and I believe we've made great progress. In the past, it's taken us six months to a year to upgrade between major Spring versions. I tweeted our current status recently.
Raymond and I had a bit of back and forth regarding upgrades.
I also think you missed my point on upgrading JHipster on a regular basis (say, a monthly interval).
My idea behind this is as follows:
1. Creating/Generating a new project happens only once, while upgrading happens dozens of times over the lifecycle of the software.
2. Applications (and also JHipster-generated apps) have a lot of dependencies. I rather don't want to manage those dependencies by hand (even with stuff like Dependabot).
3. It's important to be on the latest version for security, fixes, and to make dependencies work with modern frameworks (say JDK17).
4. Dependencies must work together well, and this must be tested.
I work mostly alone on my open source projects. It's my goal to work as much as I can on the 'business code/specific use cases and not be bothered too much about technologies and dependencies.
That's why I think it's so critical to start a project with the latest available dependencies when starting a new project, but also for using the latest versions when upgrading.
I let JHipster upgrade hundreds of dependencies for me. By this I am ensured that they work together and are safe to use, while I only need to focus on upgrading JHipster, instead of single dependencies.
Upgrading JHipster is btw not always that easy. Though I developed some scripts for it now. That's also why I discussed this topic at the beginning of the year on the discussion board of JHipster Lite:
https://github.com/jhipster/jhipster-lite/discussions/512
For now, both JH and JHL focus on generating new projects and not so much on upgrading projects made with older versions. That's fair, but I believe there is still a gap in the market here, just as significant as JHipster once filled for generating projects.
For me, the monthly releases could be just patch releases with only upgrades of minor dependencies (so nothing fancy like a major upgrade to Spring Framework 6/Spring Boot 3). Those major or even minor upgrades (with some added functionality and fixes) could be every three months (minor) or yearly (major).
I know JHipster is a community project, but I think that, for example the predictability of a release every six months with LTS releases is very nice.
I agreed that making upgrades seamless is not our strong suit. I've struggled many times when trying to upgrade 21-Points Health with npx jhipster upgrade. Sometimes, it works. Often, it does not. I think this is difficult to test because it can only be done after releases have happened. I wish I had a better answer. I suggested Raymond use some of his learnings to improve our upgrade sub-generator.
My responses are my opinions. I wanted to see what the JHipster project leads thought of my perspective, so I sent them a draft of this blog post. Pascal Grimaud responded with several excellent points.
> Possibly, but as far as I can tell, the same people aren't working on the same project. I believe that JHipster Lite
was created because Pascal and others understand Java better than JavaScript, and they were lost in the JHipster codebase and
wanted a Java version. JHL also emphasizes DDD and is not interested in CRUD, AFAICT.
Sorry Matt, but it's wrong.
I didn't start JHLite because of technologies, Java or Javascript. It's the same; I don't care.
I started JHLite to solve these problems I mentioned more than one year ago.
Problem #1: too many generated files.
Problem #2: hard to customize. Only a few users (less than 10) in the world maintain a blueprint. I know dozens of companies using JHipster (generator-jhipster). And none of them uses a blueprint.
Problem #3: too many options, too hard to maintain, so no new contributors for months. For an open source project, it's really sad.
Problem #4: complex templates.
A real story between a dev and me:
- dev: I found a bug in the SecurityConfiguration class. There is a missing line of code --> "xxxxx".
- me: Nice! We should apply it to our projects. Can you contribute back to generator-jhipster, too, please?
- dev: Good idea, it will be my first contribution to an open-source project! Let me try.
(hours later ...)
- dev: I don't understand. What's this f*cking SecurityConfiguration.java.ejs file?
- me: It's the template for managing security configuration for all existing options.
- dev: Should I apply it for JWT, too? for Session? Should I apply it for reactive too? Should I apply it for microservice?
- me: Yes, and you should test each config, please.
- dev: I don't care about these options, and as it's too complex, I gave up. As you're in the core team, you can do it yourself.
- me: OK, let's apply it only to our projects.
Problem #5: Too many projects, resulting in complex releases.
Problem #6: Yeoman, maintained only by Marcelo.
I started JHLite because:
- I don't use generator-jhipster anymore for my real projects, for real customers, because it doesn't fit.
- JHLite allows me to design my applications around BUSINESS instead of infrastructure.
- Modular approach, so it fits my needs.
- The quality of code, as each module is small, it's easy to have the best quality possible.
> In reality, I think many of the contributors have had difficulty figuring out how things work. However, we've always had
JavaScript heroes to bail us out. In the beginning, Julien knew everything, so he could fix things quickly. Then, it was Deepu -
who has admitted to me he rewrote the JHipster core a few times when he was super active. Now it's Marcelo, and I think he's
doing a great job.
It's a big single point of failure!
A big open source project like JHipster needs a community + contributors, not a hero.
Related to JHipster, I recently asked ChatGPT to write a poem about it.
I also asked it to compare JHipster versus JHipster Lite.
Wow, I'm impressed with both answers! 🤩
If you have additional questions about JHipster, hit me up on LinkedIn or ask your question on Stack Overflow with a jhipster tag.