6 ms·

There is definitely something to be said for the locality of the definition with the element. Tailwind has shown that many (myself included) see defining your s

There is definitely something to be said for the locality of the definition with the element. Tailwind has shown that many (myself included) see defining your styles directly in your elements as preferable to doing it externally. JSX and templating in other frameworks gives you that desirable locality, which I think is why it can feel so painful to go back to vanilla js. I still default to plain ol' vanilla JS on a lot of things, but having to add definitions to elements after first grabbing them with selectors is annoying, particular for singular elements.

wwweston 3y ago
Tailwind has shown that, absent personnel with expertise and time to focus on a design system separating relevant concerns and/or absent tooling that can give you read/write changes, inline declaration of a somewhat constrained set of predefined options solves certain specific problems. A lot of the related complaints -- including some in this article -- basically boil down to the old complaint about object oriented programming: "everything happens somewhere else" so what's actually going on isn't something you can read in one place, you either have to wind your way through the various scope/inheritance contexts to build up a picture of the code/rules in play, or you need to have tooling do it for you. Or... you put it inline, mixing concerns, and eventually discover the tradeoff that comes with that choice.
- labster 3y ago
  The thing about OOP is that you can always trace down the methods as they’re called, or look at the parent class. JS can come from any place, reminding me of PLEASE COME FROM in INTERCAL. It’s not that, the fundamental issue is that the DOM is a big global that everything has access to. But you can’t look at a piece of HTML and know for sure it doesn’t have an event bound to it without reading every scrap of JS (or just running the code). In OOP at least you (should) have some guarantees of encapsulation. But since I don’t see an obvious way to make HTML more OO, I can see the appeal of a declarative style.
marcus_holmes 3y ago
I'm using Web Components for this stuff, and it works. If I need variant behaviour, I define a new tag and spec out the behaviour in JS. This removes the need for a vanilla JS routine that grabs the element with selectors and twiddles it. This feels like an improvement, even for a single tag :) But I'm not doing anything massively complicated yet, so I don't know how it scales for complex UI interactions.
- danielvaughn 3y ago
  My suspicion is that if you have a single page where there are lots of interdependent elements that update state together, then it may become difficult to maintain.
  - marcus_holmes 3y ago
    I agree. But the strategies that Elm/React/Vue/etc use to deal with this can be copied without taking on all the rest of the baggage. Creating a Flux/Vuex-style state container and a bunch of mutator functions isn't hard.
- christofosho 3y ago
  For my learning, what kind of state management do you use or see commonly used with web components?
  - sibit 3y ago
    I use something similar to React class components. Under the hood my set function calls Object.assign and I debounce the render function callback. You could implement it yourself in <80 lines of JavaScript[0]. I'm not sure what other people use but I've been using this style of state management for ~4 years and it's been fine so far. [0]: https://github.com/codewithkyle/supercomponent/blob/master/src/supercomponent.ts https://github.com/codewithkyle/supercomponent/blob/master/s... Edit: if signals are your jam you could us https://github.com/maverick-js/signals https://github.com/maverick-js/signals
  - marcus_holmes 3y ago

wwweston 3y ago

Tailwind has shown that, absent personnel with expertise and time to focus on a design system separating relevant concerns and/or absent tooling that can give you read/write changes, inline declaration of a somewhat constrained set of predefined options solves certain specific problems. A lot of the related complaints -- including some in this article -- basically boil down to the old complaint about object oriented programming: "everything happens somewhere else" so what's actually going on isn't something you can read in one place, you either have to wind your way through the various scope/inheritance contexts to build up a picture of the code/rules in play, or you need to have tooling do it for you. Or... you put it inline, mixing concerns, and eventually discover the tradeoff that comes with that choice.

labster 3y ago
The thing about OOP is that you can always trace down the methods as they’re called, or look at the parent class. JS can come from any place, reminding me of PLEASE COME FROM in INTERCAL. It’s not that, the fundamental issue is that the DOM is a big global that everything has access to. But you can’t look at a piece of HTML and know for sure it doesn’t have an event bound to it without reading every scrap of JS (or just running the code). In OOP at least you (should) have some guarantees of encapsulation. But since I don’t see an obvious way to make HTML more OO, I can see the appeal of a declarative style.

marcus_holmes 3y ago

I'm using Web Components for this stuff, and it works. If I need variant behaviour, I define a new tag and spec out the behaviour in JS. This removes the need for a vanilla JS routine that grabs the element with selectors and twiddles it. This feels like an improvement, even for a single tag :) But I'm not doing anything massively complicated yet, so I don't know how it scales for complex UI interactions.

danielvaughn 3y ago
My suspicion is that if you have a single page where there are lots of interdependent elements that update state together, then it may become difficult to maintain.
- marcus_holmes 3y ago
  I agree. But the strategies that Elm/React/Vue/etc use to deal with this can be copied without taking on all the rest of the baggage. Creating a Flux/Vuex-style state container and a bunch of mutator functions isn't hard.
christofosho 3y ago
For my learning, what kind of state management do you use or see commonly used with web components?
- sibit 3y ago
  I use something similar to React class components. Under the hood my set function calls Object.assign and I debounce the render function callback. You could implement it yourself in <80 lines of JavaScript[0]. I'm not sure what other people use but I've been using this style of state management for ~4 years and it's been fine so far. [0]: https://github.com/codewithkyle/supercomponent/blob/master/src/supercomponent.ts https://github.com/codewithkyle/supercomponent/blob/master/s... Edit: if signals are your jam you could us https://github.com/maverick-js/signals https://github.com/maverick-js/signals
- marcus_holmes 3y ago