Minor Prometheus landing page facelift?

[Julius Volz]

Hi,

The Prometheus homepage (prometheus.io) looks very dated by now, and I wouldn't be surprised if it turns off a lot of first-time visitors just by its looks. While I don't have the capacity to make this another major project at the moment, in lieu of a more extensive docs & homepage rework, what do people think about me just working to update the design of the landing page to make it look at least slightly more modern? I was thinking of this kind of direction (just a start):

https://prometheus-new.netlify.app/

(user logos are blurry because many never provided us SVGs - this would have to be fixed)

This would mainly change the landing page, although of course the fonts and a few styles would also have to be updated on other pages to make them consistent. But that should stay a minor change.

I built the quick demo above using a more modern tech stack (Mantine, React + JSX, etc.) than our homepage, but I could try to backport the same styles to our old homepage framework with pure HTML + CSS. Eventually it would be really nice to port the homepage to a less medieval static site builder, but that's a much much larger project.

Cheers,

Julius

[Julius Volz]

(ignore the mobile version for now, it's not made to look right yet on mobile)

[Jesús Vázquez]

Love the idea!

The 3.0 UI revamp followed by an UI revamp of the docs site would feel like a breadth of fresh air! I'm sure some future users will appreciate it as well as existing ones seeing the changes.

I do like the proposed design and went to check others for commonly stablished dbs such as postgres or new hyped vector ones like pinecone and your proposed design seems to me to be already in par with them.

Regards

--
You received this message because you are subscribed to the Google Groups "Prometheus Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to prometheus-devel...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-developers/CA%2BT6YowodCHbDNJP%2BdP9hRg%2BvT1wqCTZyzhW9o5vh-dp%2BNBJag%40mail.gmail.com.

[Julius Volz]

Thanks! Yeah, I mean Postgres is super old-school, maybe not the best comparison actually 😅 But yeah! And of course we're not going to try and compete with the super hip custom-designed startup websites that cost $80k to make. But hopefully an improvement.

Ok let's see if anyone has big complaints, otherwise in a week or so I'll give it a more serious go.

[Julius Volz]

Just an update on this website revamp idea and why I haven't moved forward yet - of course after proposing it I started thinking about whether it would be much nicer to just immediately go for a complete reimplementation using a modern web stack. That brought up many issues to solve, but the main one is the following: most JS docs site builders these days expect MDX (Markdown with React-ish extensions) as an input format for docs pages, whereas we have plain Markdown pages that not only come from the current website repo, but also from historic branches of various releases of Prometheus and the Alertmanager. A lot of Markdown parses fine as MDX, but there are many constructs in our Markdowns that blow up the MDX compiler in my experiments (like `<string>` and stuff like that). If we only had current docs, that would be less of a problem (because we could just adjust things there), but if we need to pull in old versions of docs from other repos, then it's harder to solve. We'd either have to update the docs in all the old release branches or do some kind of pre-processing-patching on them to get rid of incompatibilities before using them as MDX. It would still be super nice to get rid of the old nanoc-based site at some point though.

Anyway, I'm still thinking about this and how to best approach it :)

On Fri, Sep 20, 2024 at 7:23 AM Julius Volz <juliu...@gmail.com> wrote:

[ayoub mrini]

Thanks for the update Julius.
How about keeping both stacks for some time? the new one for the latest version and the old one for the rest? Would this be easy to set up/maintain? This way visitors can get a taste of both the old and new worlds.

Or maybe we can fix the markdowns on `main` and add that MDX compiler in the CI to avoid regressions and just wait until the old versions "disappear"/become irrelevant and we can remove them?
I see we still have `1.8` in there https://prometheus.io/docs/prometheus/1.8/getting_started/, does that still make sense?

[Julius Volz]

On Fri, Apr 25, 2025 at 6:23 PM ayoub mrini <ayoubm...@gmail.com> wrote:

Thanks for the update Julius.
How about keeping both stacks for some time? the new one for the latest version and the old one for the rest? Would this be easy to set up/maintain? This way visitors can get a taste of both the old and new worlds.

If you mean serving both a complete old website and a complete new website in parallel for a while, that would be easy to do as long as the Markdown content that feeds both sites can be made to work with both at the same time. If you mean building a single website that partly uses the old stack and partly the new one, that would sound very painful to me (one is Ruby/nanoc, the other one is JS, and they'd be very different in general).

Or maybe we can fix the markdowns on `main` and add that MDX compiler in the CI to avoid regressions and just wait until the old versions "disappear"/become irrelevant and we can remove them?

 

I think then we'd effectively have to wait for years, so I think that's not a great option unfortunately.

I see we still have `1.8` in there https://prometheus.io/docs/prometheus/1.8/getting_started/, does that still make sense?

Good question, probably not, that was released in 2017 :) If that got in the way, we could probably remove it, but even with 2.x versions, we go back over a year currently.

Maybe an option is to start adjusting things in HEAD and then maintain manual Markdown->MDX patch sets for the older versions that are applied before the rest of the MDX pipeline. I'd have to play around with that a bit.

 

On Friday, April 25, 2025 at 2:27:25 PM UTC+2 Julius Volz wrote:

Just an update on this website revamp idea and why I haven't moved forward yet - of course after proposing it I started thinking about whether it would be much nicer to just immediately go for a complete reimplementation using a modern web stack. That brought up many issues to solve, but the main one is the following: most JS docs site builders these days expect MDX (Markdown with React-ish extensions) as an input format for docs pages, whereas we have plain Markdown pages that not only come from the current website repo, but also from historic branches of various releases of Prometheus and the Alertmanager. A lot of Markdown parses fine as MDX, but there are many constructs in our Markdowns that blow up the MDX compiler in my experiments (like `<string>` and stuff like that). If we only had current docs, that would be less of a problem (because we could just adjust things there), but if we need to pull in old versions of docs from other repos, then it's harder to solve. We'd either have to update the docs in all the old release branches or do some kind of pre-processing-patching on them to get rid of incompatibilities before using them as MDX. It would still be super nice to get rid of the old nanoc-based site at some point though.

Anyway, I'm still thinking about this and how to best approach it :)

On Fri, Sep 20, 2024 at 7:23 AM Julius Volz <juliu...@gmail.com> wrote:

Hi,

The Prometheus homepage (prometheus.io) looks very dated by now, and I wouldn't be surprised if it turns off a lot of first-time visitors just by its looks. While I don't have the capacity to make this another major project at the moment, in lieu of a more extensive docs & homepage rework, what do people think about me just working to update the design of the landing page to make it look at least slightly more modern? I was thinking of this kind of direction (just a start):

https://prometheus-new.netlify.app/

(user logos are blurry because many never provided us SVGs - this would have to be fixed)

This would mainly change the landing page, although of course the fonts and a few styles would also have to be updated on other pages to make them consistent. But that should stay a minor change.

I built the quick demo above using a more modern tech stack (Mantine, React + JSX, etc.) than our homepage, but I could try to backport the same styles to our old homepage framework with pure HTML + CSS. Eventually it would be really nice to port the homepage to a less medieval static site builder, but that's a much much larger project.

Cheers,

Julius

--

You received this message because you are subscribed to the Google Groups "Prometheus Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to prometheus-devel...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/prometheus-developers/7c5f39d9-48ae-4851-ae9f-742092c25880n%40googlegroups.com.

[ayoub mrini]

> If you mean building a single website that partly uses the old stack and partly the new one, that would sound very painful to me (one is Ruby/nanoc, the other one is JS, and they'd be very different in general).

Yes, that’s what I meant, having one proxy to the other or having a reverse proxy in front of them or linking them together at build time, though I suspected it wouldn’t be easy to pull off.

> Good question, probably not, that was released in 2017 :) If that got in the way, we could probably remove it, but even with 2.x versions, we go back over a year currently.

Yes, I assumed we could only have versions from the current LTS onward (which is 2.53 now) it there, given that 3.5 is the next LTS... but that doesn’t really work I think.

(Maybe LLMs can help with the conversions)

[Julius Volz]

Another update: I've spent the last couple of weeks evaluating a lot of JS-based static site building options, from Astro over Next.js to TanStack Start, and also had another close look at documentation-specific frameworks such as Docusaurus, fumadocs, Nextra, etc. I started a stub implementation in multiple of these to see how they would fare and quickly ran into various limitations given the specific needs we have for our docs site, or the maturity of the framework (like TanStack Start, which is probably going to be really nice, but is still too alpha to use).

In the end, it looks like I'm going to go with a custom site built on top of Next.js. Reason being:

* Next.js is the most popular React framework out there, so finding people who know it will be easier than for anything else.

* Its router and static site export features suit the needs of the docs site well.

* I can build any custom features around Markdown import / parsing / custom transformations, navigation rendering, etc. that I need.

* I can use component frameworks like Mantine.dev, which wouldn't have been possible with something like Astro.

Due to the fetching of docs from other repos and then integrating everything into a coherent whole, it'll probably still take a bit to finish this, but I'm feeling that I'm off to a decent start at least now.

[Julius Volz]

On Tue, May 6, 2025 at 5:17 PM ayoub mrini <ayoubm...@gmail.com> wrote:

> If you mean building a single website that partly uses the old stack and partly the new one, that would sound very painful to me (one is Ruby/nanoc, the other one is JS, and they'd be very different in general).

Yes, that’s what I meant, having one proxy to the other or having a reverse proxy in front of them or linking them together at build time, though I suspected it wouldn’t be easy to pull off.

Yeah, I don't think that'll be necessary. In my rebuild I'm starting with the hard part (the docs), and then the rest of the pages should be relatively easy. In any case, we can totally have the old and new landing page run completely separately on two different domains for a while though.

 

> Good question, probably not, that was released in 2017 :) If that got in the way, we could probably remove it, but even with 2.x versions, we go back over a year currently.

Yes, I assumed we could only have versions from the current LTS onward (which is 2.53 now) it there, given that 3.5 is the next LTS... but that doesn’t really work I think.

I'm now going for a Next.js approach where I do the Markdown (not MDX) parsing myself vs. using their MDX integration which wouldn't have done what we need anyway. So I think that's gonna be fine, we can just stick with regular Markdown for now.

 

To view this discussion visit https://groups.google.com/d/msgid/prometheus-developers/e085d3e5-e663-4212-bd8e-c9da4a26531an%40googlegroups.com.

[Joe Adams]

I would be happy to help with this. While I don't do a ton of front-end development work, I have built several Next.js sites including a static site so I have some experience in this area.

Joe Adams

[Julius Volz]

On Tue, May 6, 2025 at 9:26 PM Joe Adams <adams...@gmail.com> wrote:

I would be happy to help with this. While I don't do a ton of front-end development work, I have built several Next.js sites including a static site so I have some experience in this area.

Great to hear, I'll hit you up on Slack and then we can see what would make most sense!

 

--

You received this message because you are subscribed to the Google Groups "Prometheus Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to prometheus-devel...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/prometheus-developers/e7b603b1-43e1-4a9b-8bff-5fbfc6532fc9n%40googlegroups.com.