> (...) I think 'state' variables are an anti-pattern. I use webcomponents (...)

It's unclear what you mean by "state variables". The alternative to state variables you're proposing with webcomponents are essentially component-specific state variables, but you're restricting their application to only cover component state instead of application state, and needlessly restricts implementations by making webcomponents mandatory.

> (...) but now with WebComponents there is separation of (...)

The separation was always there for those who wanted the separation. WebComponents in this regard change nothing. At most, WebComponents add first-class support for a basic technique that's supported my mainstream JavaScript frameworks.

"State variables" is a section in the original article. It shows a variable in the view, "name", that holds the value separate from the DOM.

setName(value) first checks the local state variable, and if different the value is both written to the state variable and the DOM.

The GP's pattern uses getters and setters to directly read and write to the DOM, skipping the need for a local variable entirely.