But you (almost certainly) started using those backend frameworks after you had experience. You learned the basics first, and then incorporated frameworks when you got to larger projects.

I came here to say the same thing as the original reply in this thread, albeit with slightly different justification:

If you don’t know the basics, and can’t build a functional site with just HTML/CSS/JavaScript, all of the frameworks will be a nightmare. You should really learn those first, even if it means building a practice site, or completely rebuilding your frontend when you decide to use a framework.

The frameworks can make your life easier, but there’s a learning curve, and a huge cognitive burden especially when you are just starting. You’ll fight them more than work with them at the start.

That all said, never use what’s “hip” on the frontend. JS frameworks typically have the lifespan of a house fly. React is one of very, very few that has remained popular, and continued to get updates for a long time (at least in JS framework terms). It’s a solid choice with a huge community, good docs, good tooling, etc. There may be other valid choices, but seriously - avoid anything new and flashy, because that usually just means its deficiencies haven’t been found yet, and as soon as they are, there will be a new framework.

I don’t know what you’re looking for, and what your “not super simple” is, but baseline browser tech provides various controls, layout mechanisms, styling, interactivity, etc.

Do you have a concrete idea of what and where specifically you hope for gains by using frameworks? Do you plan to hold a lot of state on the client that needs state separated from the DOM and its mechanisms? Do you want a standard library of styled components instead of using the native ones or styling them yourself? Do you want more robust JavaScript? Those are all very different concerns and requirements.

I like the low complexity, low barrier, low requirements of baseline web tech. The native html form controls may arguably look “ugly”, but those can be styled, individually or through a style-only CSS lib.

What’s “complicated stuff”? Your business logic will probably be complicated regardless of what you use. A framework will just add a few more layers of complexity and introduce a (usually fragile) build process.

Idk what you’re trying to build, but from this:

I “just” want to build a pretty standard, responsive, modern-looking UI. Ideally without too much boilerplate,

It doesn’t sound like you need a framework. Want responsive? Learn how to use flexbox. Want a “modern” look? Learn design, or find some CSS templates to start from.

If you’re trying to make a SPA (which a lot of beginners/insane people seem to think is a good default, which it definitely is not), then a framework might make it easier, or it might not. It depends on what you’re building. You may be able to use HTMX with a light sprinkling of JavaScript, or may need a full-blown batteries-included framework.

So. What are you building?

Web components exist.

With svelte I’ve only found like two “component” libraries and I’m not sure I’m going to continue to use them. Essentially they just are drop in components so you don’t have to write them yourself. But svelte really seems to like it when you just write the css yourself. I’ve been using tailwind with it and I honestly think I’m going to stop, because it’s harder than just writing normal css that covers either a specific component or the whole app.

I’ve heard that the original Vue was like Svelte, but I’ve heard that later Vue versions drastically switched to something like the React model. I’ve never used Vue though, so don’t listen to me about that. Really anything going in the React direction is bad in my mind.

Yeah, I’d say that’s true. I think the alternatives may be just as good, but React was the first mover in its category, gained and maintained popularity for years, is battle-tested, and the improvements they’ve made over the years has kept it fresh.

My understanding is that one of the benefits of Svelte, for example, is that it eliminates the virtual DOM abstraction that React uses, so if you cared enough to shave milliseconds off your frontend rendering time for a complex site, then you may want to look into Svelte, but the reality is that React is already very good.

In reality, your choice of framework is usually already dictated by whatever project you’re contributing to, and for most fairly modern projects that ends up being React, and sometimes Vue or Angular. Beyond that, I personally just try these new libraries occasionally, build a toy project to see if they solve some pain point that I have, and determine if that is good enough for me to switch or recommend.

If you want to try another, maybe Material. (The design guidelines or the components. But IMO the component docu has gotten worse.) But if you are going to overwrite the styles anyway, it may be easier to write your own CSS instead of debugging someone else’s.

So learn the HTML/CSS basics that you are missing, mostly on MDN. (CSS: selectors, pseudo-classes, flexbox, grid, css variables, units like rem/px/vh, media queries, collapsing of the margin, css reset and box-sizing, overflow, display, positioning, …; HTML/Web APIs: CSP, self-closing tags, fetch() API, querySelect(), URL.parse(), sessionStorage, form submit, form validation, blob, event bubbling, your browser’s inspect tools, …).

Even if you use a framework you will generally have to learn all this stuff anyway.

That seem reasonable. Don’t add more to learn before you know you need it. Is there an http server that is built in to Rust?

We use Leptos at work, which is similar to Dioxus and Yew.

Main downsides:

• You can’t really pull in component libraries, where someone has implemented more complex UI elements before. You will need to code more of these yourself.
• Because it’s mostly delivered as a big WebAssembly blob, it’s only really suitable for Single-Page-Application-style webpages (SPAs).

Main upsides:

• You get to use similar syntax and libraries as you do in the backend. Frontend code still has a very different paradigm, so it’s not completely free to jump between the two, but the hurdle is definitely lower.
• You can share code between frontend and backend. In particular, this means it is enforced at compile-time that frontend and backend share the same API.
• Some of the common code patterns benefit quite a bit from Rust’s design.
  For example, for conditionally displaying different UI elements, rather than JavaScript’s multi-line ternaries, you can use Rust’s normal if-else expressions as well as match-blocks.
  And when you make a request to the backend, you get back a Result. You can pass that up into the display code. If it contains an Ok value, you display the rendered component with the data inside. If it contains an Err, you render the error where the component would normally be.

Since you mentioned Rust is your backend, take a gander at Leptos. I’ll admit that i’m not quite versed in it yet but what I’m doing is learning React and building my apps on React while also learning Leptos.

Leotos takes heavily after React but isn’t actually like React. I know that doesn’t make much since so you will have to read the docs but it does seem to be a more efficient FE.

And to be clear, I absolutely hold my nose while working with React as that was actually my last choice of the big 4 front ends but since my end goal is Leptos and documentation and information online is widespread, it’s something I can live with

EDIT:

I am mistaken. Leptos takes after AwesomeJS, not react.

EDIT 2

I meant Solid.js

fairly static HTML generated by a backend

I don’t think this is a scalable, futureproof option. Neither is pure HTML/CSS/JS. I know you can get far with those things, but as another comment mentioned, what if I at some point want to turn it into a mobile app? What if I want to do some complicated thing that I didn’t anticipate ahead of time? An established framework seems more futureproof in that aspect.