This content originally appeared on Go Make Things and was authored by Go Make Things
Yesterday, I had a few conversations on Mastodon around when Web Components are appropriate versus a state-based UI library.
I generally prefer to handle my interactivity in two ways…
- For stuff that gets saved or sent somewhere, an old-school form submit that gets progressively enhanced with JS when available.
- For stuff that only lasts for the current session, old-school DOM manipulation.
For both of these approaches, I really like web components.
I started wondering when I would reach for a state-based UI tool instead. My go-to example used to be something like a todo list. They start simple, but get complicated quick.
But that complexity comes, frankly, from trying to manage too much of the UI with JavaScript.
I started digging through examples of various apps and demo code from the big state-based UI websites. In pretty much all situations, traditional DOM manipulation or forms and Web Components would, in my opinion, be a simpler, easier, more resilient way to build things.
I’m increasingly of the belief that state-based UI is an anti-pattern, with a very specific but limited use case.
This content originally appeared on Go Make Things and was authored by Go Make Things
Go Make Things | Sciencx (2024-06-12T14:30:00+00:00) State-based UI is an anti-pattern. Retrieved from https://www.scien.cx/2024/06/12/state-based-ui-is-an-anti-pattern/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.