Replace Hogan with Web Components

[heyainsleymae]

Hogan.js, the Mustache compiler used for generating the HTML report, has been marked as unmaintained for almost three years now; changing compilers or templating languages altogether seems to be a prudent move no matter what, and utilising the Web Components standard would remove Hogan as a dependency without the need to replace it with any other external code.

This is obviously a massive undertaking, but I think the reward makes the effort worthwhile. For a start, the existing Hogan templates could be converted to <template> elements fairly quickly, and I've plenty of WebComponent experience from my ProseMirror plugin work. (prosemirror-plugin-outline implements the WAI-ARIA treegrid pattern, and a large chunk of that code could be applied here to improve the accessibility of GoAccess's data tables, addressing part of #2742. I can spin up an example page for that if you'd like, but the relevant web component code is in ProseMirrorOutline.component.js.)

Simplifying the panel creation process would not only speed up HTML report feature development in the long-run, it would also allow those interested in different or more flexible data views—#714, #1079, #2238, #2485, #2642, #2654, #2687, #2731, #2740—to create them independently and with relative ease, either for personal use or as part of a pull request.

Ideally, this new templating approach would mean that a static HTML report—as discussed in #685—could be generated with very large tables, and those tables would be ingested by the custom elements for generating the charts and other dynamic elements.

I'd be able to start investigating this further in a week or two, though I know you are currently working on some of the filtering issues mentioned above, and I don't want to impede that work in any way. Let me know if this is seems interesting, and I can attempt to assuage any nerves by discussing some example approaches in more detail.

[allinurl]

I like the idea, it's pretty interesting! Honestly, I'm not too familiar with <template> elements yet, but I agree it's a good time to move away from Hogan if it's not being maintained anymore and we can improve the report this way. Yeah, I'd like to check out that ProseMirror component example you mentioned, if possible.

I'm curious about how much change you anticipate in terms of JS and the templating aspect. I ask mostly because as you have seen, the generated report is self-contained, so I try to keep it as lean as possible. That said, I do prioritize all these improvements.

[heyainsleymae]

Yeah, I'd like to check out that ProseMirror component example you mentioned, if possible.

I should have a demo up in the next couple days. I decided to pull it out into a separate ARIA patterns repo since that'll make it easier to work with, and I want to explore the patterns further anyway.

I'm curious about how much change you anticipate in terms of JS and the templating aspect. I ask mostly because as you have seen, the generated report is self-contained, so I try to keep it as lean as possible.

I think the final result would end up smaller, both in the number of files as well as the total size. The changes could be integrated similarly to those proposed in #2742; the refactoring to ES6 syntax can happen separately from Hogan's removal, so that things are replaced slowly, with caution and intention.

I think lots of JavaScript could disappear, or at the very least be consolidated into a flexible base for each section. There's not a single part of me that thinks the report would come out heavier than before.

I'll work on cleaning up #2750, as I don't think it's worth doing any code tinkering related to this until the outstanding semantic stuff is merged.

[heyainsleymae]

Another thing I haven't mentioned yet is that this and the semantic work will open up the opportunity to refactor the CSS as well. I've intentionally avoided doing so on the semantic work unless necessary, but custom properties would make theming more straightforward, and the semantic HTML would allow further consolidation of the custom CSS; that'd slim things down even more.

I think that Bootstrap could even be removed completely, but I'm not certain until we examine the specifics of the other proposed work further; I removed quite a few utility classes in the semantic work so far, so it doesn't feel too implausible.

[allinurl]

I think the final result would end up smaller, both in the number of files as well as the total size.

That would be fantastic, especially if it can be done natively, to keep things as lightweight as possible.

Another thing I haven't mentioned yet is that this and the semantic work will open up the opportunity to refactor the CSS as well

That sounds great too! I'm sure there are some unused parts, and I've been trying to run it through a CSS coverage tool to identify what can be cleaned up.

I think that Bootstrap could even be removed completely

I wonder if upgrading to a newer version of Bootstrap or switching to Tailwind would bring any benefits. What are your thoughts?