Think some of that (the dialog and friends) is the wrong way around: we wouldn’t have gotten all those nice DOM native components if libraries and frameworks hadn’t popularised them and driven adoption into the standards.

I am not sure I agree “the state of front end development” is due to “functional purism” either. React just provided a good abstraction that worked well for many people. It’s a meritocracy. If the abstraction that worked best (however we measure that) had been something more OOP then that would have been adopted.

Not sure I agree with the tone of the article, but I do find that Javascript developers have a weird relationship with "functional programming". I see so much convoluted code with arr.reduce() or many chained arr.map().filter().filter().map(), that would just be so much simpler and easier to read if it was a classic for-loop. I suggest this to people and they scoff at the thought of using a for-loop in Javascript.

> Consider the humble modal dialog. The web has <dialog>, a native element with built-in functionality. [...] Now observe what gets taught in tutorials, bootcamps, and popular React courses: build a modal with <div> elements

The dialog element is new! Only broadly supported since 2022. I find it hard to fault existing material not using it. Things like dialog, or a better select, are notable because they were lacking for so long.

I believe functional is the better (and best) paradigm we have right now. But the problem of why FE development still feels overcomplicated is because of a different reason.

There's a mismatch between how components are organized and how data flows through the front end application.

HTML is hierarchical. You have elements wrapping each other

   A
   └─ B
       ├─ C
       │   ├─ C1
       │   ├─ C2
       │   │   ├─ C2a
       │   │   └─ C2b
       │   └─ C3
       └─ D
           ├─ D1
           ├─ D2
           │   ├─ D2a
           │   └─ D2b
           └─ D3

The issue here is that you can have something like D3 changing the state of an element like C3. So data must be artificially grafted on the above hierarchy to make it work.

D3 wants to send data to C3? Well then that means B must be the owner of the data. So data that feels like it must live on D3 well now you got to make it live on B which has nothing to do really with D3.

This has one primary problem.

It destroys modularity and much of the benefits of functional programming making it sort of useless in react. If you did prop drilling most things that have a path from B to C3 and B to D3 now are no longer modular and can ONLY be used in context of data related to D3. If you didn't use prop drilling and used some contextual way to pass the data the problem is still there because now components on that path have access to contextual data that's irrelevant. Some developer may have a component access that context and modularity is broken... that component can now never be moved outside of the context.

Really how data flows through your program is actually a separate graph structure, and how HTML elements are organized in your program is another separate graph structure we try to graft into the first one and that creates a mess.

I think the best way to do this, hasn't been done yet. But really side effects like clicks and button presses should NOT live on components. Components don't know about these things. That keeps the hierarchy and modularity of these html elements pure. A framework that's well designed needs to enforce this separation. I even think this can be done in a way that is STILL functional, but not react.

HTML and jquery were sort of going in this direction, but the problem was HTML lacked modularization because you couldn't group tags into a component. You also have timing issues and complexity with state that jquery didn't handle.

Overall I think the old style was actually better. It was a better overall direction that had tons of problems and I think those problems could have been solved if we continued in that direction.

Imagine something similar to jquery but this jquery can only directly reference components on your component hierarchy and pass data directly to components (aka manipulate them). Context and state will also live on this jquery like framework and it will be handled in a similar way to how react handles it. While components themselves can wrap other components, and parameters that go into components can ONLY have default values. The components can never dynamically "call" other components with data and actually have anything truly dynamic going on.... only the jquery like framework can do this.

I don't disagree with the idea that people can be a little kooky about FP, but the idea that webapps are perfectly fine without modern front end approaches is a bit exaggerated. Managing UI state is much easier in the client - sure, if you don't have a stateful UI to begin with don't go build some JS SPA. But I've have been there done that with teams and companies that dislike JS then try to fake UI state back and forth from server to client, and it really sucks, overcomplicates stuff that should be simple.

A lot of these are implementation details and not necessary for the abstraction to work. Preact doesn't use a synthetic event system for example

Something about web development really does seem to break a person's ability to design/architect a proper event-driven, data-oriented UI.