Have you done a feature comparison between what capabilities you would need for an
OpenShift based console only and what is needed for the full bare metal console. It may be
worth starting with the OpenShift console related features and have it match the look and
feel of other console based products. Then if demand needs it you can extend to cover the
bare metal aspects as well.
Another option is to use rust/yew Framework as per the Trusted Content team - may be a
radical move though
On 2 Aug 2023, at 10:22, Harald Pehl <hpehl(a)redhat.com> wrote:
With the latest release of PatternFly 5 [1], I'd like to open a discussion about the
future of the HAL codebase and possible major updates.
HAL currently depends on PatternFly 3.x, released on Feb 1st, 2016 [2]. PatternFly 3.x
itself depends on many old JS dependencies like jQuery 3.x and Bootstrap 3.x, which are
either no longer supported [3] or don't receive new updates.
While HAL itself is pretty stable, this brings the danger that we run into CVEs that can
no longer be fixed simply by updating the dependency. One possible solution would be to
update to the latest PatternFly version. This would have more advantages:
- Fresh, new look and feel
- Enhance user experience
- Align with other consoles like OpenShift & Keycloak
I see two basic approaches when updating to PatternFly 5:
1. Switch the technical stack to TypeScript & React
Pros:
- Recommended way how to use PatternFly
- Well documented
- Active community
- State of the art
Cons:
- Rewrite HAL from scratch
- Hard to re-use existing codebase
- Technology-independent building blocks like DMR-related code, RBAC security checks, and
model-based UI would be lost
- Weak expertise
- Contributors need to adapt
2. Stick with the current architecture (Java & GWT) and migrate the codebase
Pros:
- Technology-independent building blocks can be re-used
- Could also be the foundation of halOS
- Well-known and rock-solid architecture
- Strong expertise
- Some work has already been done [4]
Cons:
- GWT community does still exist, but it is small and not very active
- Rewrite a lot of UI-related code
Finally, we should consider the following issues:
- With the focus on running WildFly in the cloud, do we really need to make this effort?
Is it worth it?
- When updating HAL, we should keep in mind that the test suite can be adapted with
minimal effort.
Before going into any direction, I'm keen to hear what you think about it.
Suggestions, ideas, and critics are welcome!
---
Harald Pehl
JBoss by Red Hat
[1]
https://www.patternfly.org/get-started/upgrade
[2]
https://github.com/patternfly/patternfly-3/releases/tag/v3.0.0
[3]
https://blog.getbootstrap.com/2019/07/24/lts-plan/
[4]
https://github.com/patternfly-java
_______________________________________________
wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org
To unsubscribe send an email to wildfly-dev-leave(a)lists.jboss.org
Privacy Statement:
https://www.redhat.com/en/about/privacy-policy
List Archives:
https://lists.jboss.org/archives/list/wildfly-dev@lists.jboss.org/message...
---------------------------------------------
Mark Eastman
Middleware Engineering Director
Red Hat UK Ltd.
meastman(a)redhat.com
t: +44 (0) 191 495 7407
m: +44 (0) 791 228 1527