[phaedryx]

I think the idea of "sprinkling" JavaScript into your server-rendered HTML is a good one. However, I think that Stimulus is terrible.

1. There isn't a good way to test it. There is nothing in the docs about how to test it.

2. Keeping state in the DOM is dangerous

3. Messaging between Stimulus controllers is painful

4. They disconnect parameters from functions. The functions have to scan through the DOM to find what they need which I think is fundamentally weird

5. Reusability is rare

6. It doesn't try to play nice with the larger JavaScript ecosystem.

I personally prefer Vue.

[abhgh]

Reg. #2 - I returned to frontend dev. after years for a hobby project (and even earlier, my frontends weren't very complex, I could get by with jQuery in the pre-React days), and I am surprised to see this is popular (or at least a supported feature everywhere). I would also think #2 is dangerous, but I am wondering if its just me being simplistic. Aside from a thin layer of reactive controls, when do people need #2?

[nchmy]

Care to elaborate on #2?

[phaedryx]

I remember when Backbone first came on the scene and “get your truth out of the DOM” was the rallying cry.

I'm going to cheat and get a list from AI:

1. Difficulty in maintaining and debugging: When state is scattered throughout the DOM, it becomes challenging to track and manage, leading to code that is hard to maintain and debug.

2. Performance issues: Frequently querying the DOM for state information can be more expensive and slower compared to accessing data stored in JavaScript objects or dedicated state management solutions.

3. Lack of a single source of truth: Storing state in the DOM makes it difficult to establish a centralized, authoritative source for application data, which can lead to inconsistencies and errors.

4. Synchronization problems: Keeping DOM elements in sync with a mutable list of data can quickly become complex, especially when dealing with dynamic lists or elements without unique identifiers.

5. State persistence issues: DOM-based state is vulnerable to loss during page refreshes or navigation, which can lead to poor user experiences, especially in single-page applications.

6. Scalability challenges: As applications grow, managing state in the DOM becomes increasingly cumbersome and can result in performance bottlenecks.

7. Difficulty in implementing advanced features: Techniques like time-travel debugging, state snapshots, and easy hydration become more challenging or impossible when state is primarily stored in the DOM.

8. Increased complexity in component communication: Relying on DOM for state can complicate the process of sharing data between components, potentially leading to prop drilling or other anti-patterns.

[tomnipotent]

In the "old days" I'd colocate data as HTML attributes:

    <div data-parent-id="1234" data-category="Article">

We'd use this data for any number of purposes to build out other little features that'd rely on the attributes.