Thanks for bringing this up Dávid. Istvan has covered a lot of ground in his reply and I generally agree with him. I agree that we should support server-side rendering over a JS-heavy solution. I agree that JSP is old but an entrenched standard, which has some appeal given our history.
I am concerned that we won’t ever attract frontend developers by leaning into such an old technology stack. This hurts the project doubly because it means both our product AND our website languishes looking old and outdated. I think that we should be able to selectively opt-in to more modern JS features. The Region Visualizer on the Master UI is one such example. To be my own critic on that feature, I do not know if the UI degrades gracefully for a client that does not support JS. On the comment about moving the JSPs over to consuming beans, I did start an effort around this by introducing a modern (at the time) Jersey environment. I think anyway that we can continue to build on Jersey to render model objects that get rendered out via JSP (or whatever). Thanks, Nick On Thu, 12 Dec 2024 at 12:55, Istvan Toth <st...@cloudera.com.invalid> wrote: > I never thought that I would voice support for JSP, but I think that the > Jamon situation is a good example of the advantages of JSP. > > Yes, JSP is old, kludgy and limited, but it has been around since forever, > and as it is part of the Java EE (jakarta) standard, we can also expect it > to be around for a long time. > Jamon was a hot new thing when it was adopted by us, but just two years > later it was discontinued. > > I think that given what the HBase web UI needs to do, and given the lack of > frontend focus and resources in HBase, something like JSP is exactly the > right technology for us. > It is simple, super easy to pick up, has minimal dependencies, and there is > a minimal surface area for security issues with it. > > If we move to another server-side rendering framework, there is no > guarantee that that framework would be around long enough for our purposes. > > (Having said that, the existing JSP pages could certainly be improved by > moving most of the Java code to some backing beans) > > I also want to pre-emptively mention that I would consider moving to some > client-side rendering framework a huge mistake, as HBase does not need such > functionality, and adding another intense upgrade and rewrite treadmill > that few of us has the expertise for would just waste our resources. > > Istvan > > On Thu, Dec 12, 2024 at 11:30 AM 张铎(Duo Zhang) <palomino...@gmail.com> > wrote: > > > Are there any new ways to implement this? > > JSP is also a very old technology... > > > > Dávid Paksy <paksyda...@gmail.com> 于2024年12月12日周四 17:58写道： > > > > > > Hi, > > > > > > Sorry for sending this again - but the former mail landed in spam > > (because > > > of the links) for some people. > > > > > > While I was working on HBASE-28832 to migrate Bootstrap I noticed that > > > HBase have a mix of JSP and Jamon code. Looks like HBASE-3835 started > the > > > work in 2011 of converting from JSP to Jamon, but the work didn't > finish. > > > I guess the best would be to either migrate everything to Jamon or back > > to > > > JSP as having both is not ideal from maintenance perspective. > > > > > > While Jamon has advantages (static typing of template arguments, unit > > > testing, etc), looking at the Jamon project, it seems that the last > > release > > > was on 2013-12-29 and I see no newer activity. > > > > > > From this I think moving back the Jamon files to JSP would maybe make > > more > > > sense now. > > > > > > What do you all think about this? > > > > > > Many thanks in advance, > > > Dávid > > > > > -- > *István Tóth* | Sr. Staff Software Engineer > *Email*: st...@cloudera.com > cloudera.com <https://www.cloudera.com> > [image: Cloudera] <https://www.cloudera.com/> > [image: Cloudera on Twitter] <https://twitter.com/cloudera> [image: > Cloudera on Facebook] <https://www.facebook.com/cloudera> [image: Cloudera > on LinkedIn] <https://www.linkedin.com/company/cloudera> > ------------------------------ > ------------------------------ >
