Opinion: Leptos should ship with an opinionated CSS solution, preferably support for component scoped CSS, a la, CSS modules

[saikatdas0790]

The whole point of a component based web framework is to let developers encapsulate UI into composable pieces that can be reused and composed independently. And styling is an integral part of that puzzle.

Having to stitch together community maintained styling solutions to have a coherent developer experience is counter-productive.

Cargo-leptos which is currently the meta-framework for Leptos ships with defaults for using Tailwind CSS but falls short when it comes to using native CSS out of the box.

I propose that we allocate some effort into setting up a basic mechanism to change this. The lowest hanging fruit to tackle this seems to be adding support for scoped CSS natively in the framework that works out of the box without the dev having to cobble together a half baked solution that falls apart every time any of the depencies in the toolchain updates.

[gbj]

but falls short when it comes to using native CSS out of the box.

Just to nitpick: I think what you mean is that we don't provide an alternative to native CSS out of the box. Using plain CSS (or using SASS) is actually the best Leptos experience, because CSS files immediately reload as you edit and save them. But I think you're talking about component-scoped CSS a la Angular, Svelte, or Vue, none or which are "native CSS" for what it's worth.

[saikatdas0790]

Yes, I agree. I worded it inaccurately to what I wanted to convey.

I am still arguing though that it is counterintuitive in the context of a component based framework to dump all our CSS into a singular file.

Which would beg the question then why not put all our HTML and logic in a single file as well.

It just makes more sense to be able to colocate all code concerning a single component together as well as to be able to edit it together as opposed to treating styles as a separate responsibility and handling it differently in a CSS file that lives separately and having to remember to maintain it separately as well as to deal with the cascade..

[tqwewe]

I think just like React has EmotionJS, StyledJS, etc. libraries for styling react components, and Rust people tend to use tokio even though its not official, it's good to let community libraries provide options for different ways of handling styles in your app.
Especially styling in web apps has so many different ways of handling it.

Having an "official" way in Leptos wouldn't be bad, but I think there would be more benefit letting community libraries provide options for developers.

[saikatdas0790]

I've done some Svelte before this when I wasn't wholly committed to Rust. And before I did Svelte I also did some React. I distinctly remember using both EmotionJS and styled-components in React land and it was an annoying experience struggling to make it work. Compared to that, being able to just add a <style></style> in Svelte was a breath of fresh air.

I agree that more choice is always a good thing. But I'm arguing that the framework natively should provide a batteries provided out of the box option to use scoped CSS, either something along the lines of CSS modules or a mechanism to do it alongside the component (with a macro maybe)? But it has to work seamlessly along with the other features in the framework like hot reloading. That kind of a smooth experience is quite unlikely with community libraries

[gbj]

My primary concern here is the added maintenance burden. As far as I can tell, stylers does what you're requesting here. I hear your point about the difficulty of guaranteeing that a whole ecosystem is actively maintained, updated to work with latest versions, and so on. But everything that gets pulled into the framework core ultimately becomes my responsibility to maintain.

On the other hand... I've been doing a lot of work with const evaluation recently for the next version and I'm wondering if there may be some cool opportunities here to use the same macro-less (or macro-not-required) and statically-typed approach here. Let me plant this as a seed in my brain for a little while and see if anything interesting starts popping out...