Labeling UI frameworks as artificial complexity is simply a sign of inexperience manifested as NIH syndrome.

The vanilla approach is fine for a personal or toy project, but it's an unmitigated disaster for a project with even a moderately complex UI.

Eventually, the vanilla project becomes its own bespoke UI framework with a bunch of poor design choices because all the complexity that was dismissed as "artificial" eventually gets patched in using a rube-goldberg-machine approach to architecture.

▲ lenkite 24 minutes ago | parent | next [-]

Regarding puzzling design choices, I am wondering at the preponderance of data attributes like

   <e-toast
    data-type="success"
    data-position="top-right"
    data-hide-after-n-seconds="5"
    data-close-icon="/images/close.svg"></e-toast>

For custom web components, maybe the author forgot that you don't need to prefix attributes with data ?

▲ umvi an hour ago | parent | prev [-]

Not everyone is building complex UIs like google sheets. Most people are building static pages with a sprinkle of interactivity, or maybe form pages for doing CRUD.

	▲	ganzsz an hour ago \| parent \| next [-]
		It starts as simple crud, but then product introduces a business rule where some fields need to be hidden when another option is selected somewhere. O, but not when this checked, etc. Having a reactive framework when this happens is very much needed to keep all these effects working without a lot of vanilla JS. This can be solved later, but is a lot harder when you have an entire application that needs to bee kept working, and almost trivial if you started with some reactivity built in.
	▲	root_axis an hour ago \| parent \| prev [-]
		As I said, any app with at least a "moderately complex UI". If your app is just a sequence of web forms and stays that way forever, then you're not the target audience of a UI framework anyway.