Agreed. I have a CMS project that uses both, but they are separated -- The CMS is a React front-end, with a node back-end. The sites maintained by that app are built by Astro via spawning a 'npm run build' in a separate Astro project that reads the CMS data, then writes the output to another directory from which I can deploy.
They do complement each other nicely... but there is little benefit to actually mixing them directly together.
I made this redesign for an assignment for a frontend dev gig I was interviewing for. It was a fun little exercise, might write a case study about it later.
Personally, I like the original (https://samber.github.io/awesome-prometheus-alerts/) better. Huge static page, no JS to search (just use your browser search), rather no JS at all. The original is a mess to build and maintain because it does yaml -> json -> yaml -> jekyll -> html, which looks a little rough to me.
> It's also important to note that while FIX frontend is open source, it utilizes commercial Material UI components. As such, to use it, you'd need your own Material UI license.
That is an odd choice for an open-source project. I'm curious to know what Material UI provided that any other open-source UI library did not.
The reasoning is explained in the very section of our Github org README you quoted this sentence from. Our main open source project is Fix Inventory (https://github.com/someengineering/fixinventory) and that is very well documented (https://inventory.fix.security) and uses no commercial 3rd party libraries.
The Fix SaaS frontend that you're referring to and that you find at https://fix.security builds upon Fix Inventory. We could have just made it closed-source like every other SaaS (think Grafana Cloud). But because I'm a big proponent of OSS we decided to open source our entire SaaS stack, frontend, backend as well as all internal tooling. The main intend here is transparency, not so you spin up your own SaaS environment.
Essentially we develop the SaaS for ourselves first and foremost, but saw no reason to make it closed source. So that is why it might be using any number of commercial 3rd party add-ons.
> I'm curious to know what Material UI provided that any other open-source UI library did not.
I believe it was some MUI X table features like multi row sorting that we didn't feel like re-implementing. I'm sure there's other open source libs that would do that, but we've settled on MUI and are not going to start mixing different UI libraries for different visual elements if we don't absolutely have to.
I've yet to use CMSs and I hear that content and publishing is what they excel at. I have been using Astro for a while and have found it to be a great way to build websites, at least at the small scale that I am working with.
This post marks a stepping stone to my journey toward more streamlined publishing using Notion and Astro.
Pirsch was also recommended by others and looks like a product I'll be considering for projects with the resources to use a non-free tool. For my website, however, I think it might not be worth the spend for me.
The most important metric I want to track at the moment is the number of people who come to my website using the link on my resume. It helps me understand how many of my applications might have been met with interest (which so far has been 1, unfortunately).
With everything else, I agree. I write as a means of documenting my findings and sharing it with others and surely the discussion section here on HN is where it becomes useful to me where I can engage in constructive conversation and learn new things.
I agree. With PostHog, I know that my ad-blocker will blocks the URL rendering the service useless, but I set up a reverse proxy using Cloudflare Workers to prevent ad-blockers from blocking it.