I want to make a general comment on your channel : you are doing EXACTLY what the Rust community needs in my opinion. You don't do another tutorial about ownership or the same kind, nothing wrong with those. You are going for the niches and IT'S AMAZING. Really amazing job for the subject you pick
@@chrisbiscardi That's awesome! I love sycamore for real time data charts in particular (minus the canvas part). About 5 years ago, I rewrote my vue.js frontend (media server app) in yew, but I wasn't really happy with my resulting code. Seemed like way too much boilerplate. From my brief revisit, it does seem like yew has improved a bit in this regard. One day I might try rewriting it using sycamore.
In the JS world, I'm looking forward to when Meta open sources their stylex tool. It's a CSS-in-JS solution that can statically compile to atomic CSS. It also papers over some of the annoyances with overriding rules and also shorthand properties. Stylist doesn't really look like something I would want to use.
Stylex is similar to what Stitches, Vanilla Extract and griffel (Microsoft) does. It's closest to griffel in terms of API and it being compiled ahead of time, whereas Stitches has a small runtime. But I am also curious what it may bring that we haven't already seen in the CSS-in-JS space.
@@dealloc Stitches is more of a styled-components approach (which I personally dislike), Vanilla Extract is more about using Typescript as a replacement for less/sass that will compile bascially one-to-one to CSS files, but griffel is a lot like stylex, so thanks for introducing me to it!
@@JeffHanke I meant more in terms of generating atomic CSS, not so much API. Griffel has the closest API to stylex-I believe they even hint at them using stylex as an inspiration.
raw style attribute lacks selectors for psuedo elements and state, adds duplication and can result in large HTML files that are difficult for gzip to compress, so adds to bandwidth. I don't know how stylist works, but I presume you can use selectors like &:hover and &[data-attr] since it will generate CSS classes anyway-at least that is how the `css` function works in most CSS-in-JS libraries that support the styled components API.
As for highlighting, it should be trivial to provide an extension that highlights anything within "css!(r#...#)" macro as CSS by utilizing the language server, which should also provide linting and formatting support. This is how styled-components and lit-html provides it. It's unfortunate that it doesn't generate atomic CSS, which means that it won't scale well for larger apps with a ton of CSS. Additionally it would be nice to have an API for variants like Stitches, Vanilla Extract and others. I'm sure you could write a tool on top, but I expect today's CSS-in-JS solutions to have better ergonomics than styled-components.
I feel like if we're going to have CSS inside rust it could at least be checked for errors like rust code. Even if I had to write the CSS as actual rust code.
include_str!(...) might help make this nicer to use. However, I'm really not a fan of this approach. WASM already doesn't benefit from parallel downloads, and having all your CSS embedded in the binary seems a good way to reduce your apps initial load time significantly.
I want to make a general comment on your channel : you are doing EXACTLY what the Rust community needs in my opinion.
You don't do another tutorial about ownership or the same kind, nothing wrong with those.
You are going for the niches and IT'S AMAZING. Really amazing job for the subject you pick
Can not to not agree with you.
life hack: just use tailwind, their parser can read rust files and generate css based on the classes you used
Have u tried it with TailwindCSS based UI Librairies like DaisyUI? Love love to know if this works…
I've been binge watching your videos. Thanks for your content!
I like using sycamore these days, but yew is nice.
glad you're enjoying the videos! sycamore is on the list to cover as well.
@@chrisbiscardi That's awesome!
I love sycamore for real time data charts in particular (minus the canvas part).
About 5 years ago, I rewrote my vue.js frontend (media server app) in yew, but I wasn't really happy with my resulting code. Seemed like way too much boilerplate.
From my brief revisit, it does seem like yew has improved a bit in this regard.
One day I might try rewriting it using sycamore.
In the JS world, I'm looking forward to when Meta open sources their stylex tool. It's a CSS-in-JS solution that can statically compile to atomic CSS. It also papers over some of the annoyances with overriding rules and also shorthand properties.
Stylist doesn't really look like something I would want to use.
Stylex is similar to what Stitches, Vanilla Extract and griffel (Microsoft) does. It's closest to griffel in terms of API and it being compiled ahead of time, whereas Stitches has a small runtime. But I am also curious what it may bring that we haven't already seen in the CSS-in-JS space.
@@dealloc Stitches is more of a styled-components approach (which I personally dislike), Vanilla Extract is more about using Typescript as a replacement for less/sass that will compile bascially one-to-one to CSS files, but griffel is a lot like stylex, so thanks for introducing me to it!
@@JeffHanke I meant more in terms of generating atomic CSS, not so much API. Griffel has the closest API to stylex-I believe they even hint at them using stylex as an inspiration.
What is the benefits of stylist's styled component over writing the same CSS in the inline style tag of an element?
raw style attribute lacks selectors for psuedo elements and state, adds duplication and can result in large HTML files that are difficult for gzip to compress, so adds to bandwidth. I don't know how stylist works, but I presume you can use selectors like &:hover and &[data-attr] since it will generate CSS classes anyway-at least that is how the `css` function works in most CSS-in-JS libraries that support the styled components API.
@@dealloc I see, thank you!
Gods work!
As for highlighting, it should be trivial to provide an extension that highlights anything within "css!(r#...#)" macro as CSS by utilizing the language server, which should also provide linting and formatting support. This is how styled-components and lit-html provides it.
It's unfortunate that it doesn't generate atomic CSS, which means that it won't scale well for larger apps with a ton of CSS. Additionally it would be nice to have an API for variants like Stitches, Vanilla Extract and others. I'm sure you could write a tool on top, but I expect today's CSS-in-JS solutions to have better ergonomics than styled-components.
I feel like if we're going to have CSS inside rust it could at least be checked for errors like rust code. Even if I had to write the CSS as actual rust code.
include_str!(...) might help make this nicer to use.
However, I'm really not a fan of this approach. WASM already doesn't benefit from parallel downloads, and having all your CSS embedded in the binary seems a good way to reduce your apps initial load time significantly.
I feel like the zoom is to high, idk might be my personal preference but I prefer less zoomed in videos
Nah man the zoom is perfect