The mention of the ELK stack made me think of good ol' LAMP stack (Linux, Apache, ~~MySQL~~ MariaDB and PHP/Python/Perl). That's still a reasonable choice today for many, I would say. You can get quite far with this stack serving HTML and CSS, with some JavaScript added on top where you need it.

If you search for LAMP stack alternatives you might get some more contemporary spins. Nginx is a quite popular Apache alternative. PostgreSQL is a popular MariaDB alternative. Pretty much any language has some variant of an HTTP server than can serve HTML responses, and a more or less vibrant ecosystem of libraries that makes it easier to do.

You mention Python, something to look at there is Django. I've used it before and been quite happy with it, though Python isn't the language I use most.

In the JavaScript/TypeScript world there are perhaps too many options. One approach is to use a generic server library like Fastify or Express with a templating engine of your choice (f. ex. Liquid) to make the HTML writing part a bit simpler. Templates let you reuse fragments / components, loop over collections, add conditionals and such. For Fastify it's via a plugin called @fastify/view. You can then use whatever view library you want (if you need one at all) for handling things in the browser, such as Svelte which another commenter mentioned.

If you are interested in Svelte, something to look into there is SvelteKit. With that Svelte will be your "template engine" and it includes both server and browser functionality. Though depending on your needs it may also be overkill, solving for problems you don't have.

Counterpoint, what if you don't end up doing or needing that? Then you've paid the cost of complexity and added maintenance burden to update dependencies for no reason.

If you do end up needing a complex feature, perhaps the complexity can be isolated to just the part of your application that needs it? For example React can be used to render just parts of one page.

For mobile apps, perhaps all you need can be accomplished as a progressive web app (which is "just" regular HTML, CSS and JS at the end of the day)? That way you don't have to deal with or pay for app store distribution.

I would first ask what you expect your frontend to do. Will your UI get live updates? What do you expect will be an average session time, minutes or hours?

I forgot to elaborate why. My point being you might get what you need from fairly static HTML generated by a backend, with a sprinkling of JavaScript for interactivity (Progressive enhancement, gov.uk has more on that as an approach )

I would first ask what you expect your frontend to do. Will your UI get live updates? What do you expect will be an average session time, minutes or hours?

I “just” want to build a pretty standard, responsive, modern-looking UI.

You can accomplish that with plain HTML, CSS and JavaScript. https://developer.mozilla.org/en-US/docs/Learn_web_development can be a good place to start.

Ideally without too much boilerplate

What is considered boilerplate, and too much of it, is a bit subjective.

in a framework that “feels good”

That is very much subjective. Also, you might not need a framework.

in a way that might at some point attract other contributors as well

Now you're considering your own tastes, as well as the tastes of an unknown future stranger :D I'd say don't worry about it.

The language is in the works but JetBrains has not revealed a timeline for general availability at this point.

Won’t hold my breath for this ever shipping.

Assuming there will be an LLM involved because that’s what seems to be all AI is these days. How on earth they plan to get reproducible builds from this thing is beyond me (suppose that’s one reason I don’t work for JetBrains).