151–160 of 191 posts
Earlier quoted context omitted.
They still rely on JS to instantiate though unless I've misinterpreted?
the point of them is that you are providing full proper HTML and CSS so client-side stuff kicks in only when it can and needs to be kicked in.
All web components are rendered eagerly, so it kicks in immediately the moment it appears on the page.
Earlier quoted context omitted.
So essentially what partials in a template or server-side include solve. That's the only "build-like" part of my current website, but I'd much rather manage this beforehand and serve static HTML, or run a server-side process than use JS/HTML web components at runtime.
JS/HTML web components are the static HTML – ``` {your standard static html} ``` This is just a better way of doing DOM scripting, enhancing without waiting for Document Ready event, and having more freedom when to load the dynamic bits.
Better than what?
> enhancing without waiting for Document Ready event
Instead you wait for `connectedCallback`
> and having more freedom when to load the dynamic bits.
You literally have no freedom over that. Web components are rendered the moment they are added to the page, and you have no control over that. So if something dynamic is happening in your `connectedCallback`, boom, our dynamic bits are loaded whether you want them or not.
Earlier quoted context omitted.
But we're talking about Styled Components
No, we're not. I responded to your second statement, starting with "Tailwind, on the other hand", and I'm arguing against some of the unfounded criticisms here.
Earlier quoted context omitted.
Why does the name matter? If it's a Wrapper or a Container or an InnerWrapper or whatever. It's just a 'label'.
When you label something the implicit purpose is that it is now reusable. But an InnerWrapper class defined within a React component should be private and not actually reused, whether you are using global styles or css in JS (because it should be a private implementation detail—otherwise the component consumer has to also figure out the classes to apply).
What makes you think that? I wouldn't use a wrapper element from a different component in another component. At some point you just have to use common sense.
Earlier quoted context omitted.
Styled components are code. You could easily have a value from a central config rather than a string, like ${company.padding.px}.
Sure. But now you need to maintain both places, you must think of units, and all the edge cases the Tailwind code base already handles.
I feel the same about javascript: "I think the folks building Tailwind are talented and nice people. But at a pure technical level, I simply don't like Tailwind. Whoever it was built for, it was not built for me."
What would you suggest as an alternative to enable rich web applications?
Recently, I started a new project for work with Blazor, and I felt at home again. It was weird, just a relief to work with what I know best.
I'm not saying Blazor is good or you should use it, but for me, coding was fun again. I truly hope I do not have to work a lot with JavaScript ever again. I just do not enjoy it. Maybe I have to go to full backend after so many years of full stack.
Earlier quoted context omitted.
What would you suggest as an alternative to enable rich web applications?
I am a .net guy and had to write react for over six years daily, combined with c#, so I got pretty decent at it. Even did some sideprojects with react. Recently, I started a new project for work with Blazor, and I felt at home again. It was weird, just a relief to work with what I know best. I'm not saying Blazor is good or you should use it, but for me, coding was fun again. I truly hope I do not have to work a lot…
Earlier quoted context omitted.
What makes tailwind feel wrong for me is that you put the css classes everywhere exactly like you would set inline style attribute. I would prefer using the css slectors and select by an id or class name and apply a css like that. I avoid frontend but this is how I see it used in my team. Would be nicer if you could do it like selector > color-xyz text0xyz paddifng-xyz and never add those classes inline
I know there are many tutorials doing that, but that is not how I use Tailwind. Tailwind entirely supports your own CSS files and you can use @apply to compose all of the existing classes together.
Decent arguments. Ultimately, I think your preference comes down to: - Do you care about how your html output looks? - I personally don't, just like I don't care about what my Webpack bundle looks like. Web standards will always be slower to evolve, which is why we build tooling on top. - How do you think web components will be used? - I believe they will be used sparsely, only by libraries. But if you want to replac…
It's not a good comparison. You won't ever read the output of your Weboack bundle, but you will surely read the html you write (or worse, is tasked to modify or debug).
Especially in the HTMX community I'm alwayws wondering why people are chosing Tailwind. I tried it too and had the same problems as stated in the article. Mainly that its polluting the HTML so much. I went the opposite route and am using PicoCSS now which works with semantic tags and can even work without any classes. Feels much cleaner
Locality of Behaviour: "The behaviour of a unit of code should be as obvious as possible by looking only at that unit of code" https://htmx.org/essays/locality-of-behaviour/ Some people want "cleaner" and that's fine, I much prefer things to be "right there" as much as possible. Must be how my brain works