Hacker News Reader

Comment by dinkleberg | Hacker News Reader

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.

View on HN

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.

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.

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.

For my learning, what kind of state management do you use or see commonly used with web components?

I currently have three large components that handle state between them, and a bunch of control components that don't care about state (they receive values as attributes, and trigger "change" events if changed by the user).

The larger components contain their own state, and communicate by events (so component Foo emits a change event when its state changes, and component Bar listens for that event and fetches the new state by checking event.target.data).

It's working reasonably well with this relatively small set of interactions. But I can see a point where I'll have to create a Flux/Vuex-style state store and use actions to mutate it.

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/s...

Edit: if signals are your jam you could us https://github.com/maverick-js/signals

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.

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.

Reply on news.ycombinator.com