Does anybody like React?

In my experience, the biggest problem in Elm is how unintuitive TEA's docs are. In some ways, Elm really feels like Haskell -- you want to avoid creating "stateful" modules and you prefer stateless modules.

For example, https://harmont.dev's app (landing page is not Elm) has a component to render a pipeline graph called DagGraph. In React, you'd do something like

  function DagGraph() {
    const steps = useState([]);
    const selectedJobIdx = useState(null);
    return ...;
  }

In elm, I lift this up (I will keep using React syntax for the sake of wider-audience readability)

  function DagGraph({ steps, selectedJobIdx } : IDagGraphModel) {
    return ...;
  }

This allows for better testability of the graph view. The parent then injects the model

  function PipelinePage({ graphMode, selectedPipeline }: IPipelineModel) {
    return (
      graphMode === GraphMode.DagView
        ? 
        : 
     );
  }

Now -- we need to bubble up the selected pipeline index based on when the user clicks a node in the DAG view. I personally prefer to do this completely orthogonally to the view rendering pipeline (which remains mostly pure). I create a new model, and define the message relationships to it:

  namespace PipelineState {
    interface Model {
      steps: Step[];
      selectedStep: number | null;
    };

    interface ISelectStepMessage { stepIdx: number };
    interface IUnselectStepMessage;

    type Message = ISelectStepMessage | IUnselectStepMessage;

    function update(m: Model, msg: Message): Model { return...; }
  }

  // main model
  interface Model {
    pipeline: PipelineState.Model,
  }

  type Message = PipelineState.Message | SomeOtherMessage | ...;

  function update(m: Model, msg: Message): Model {
    switch (msg) {
      case PipelineState.Message as msg:
        return update(m, msg);
      ...
    }
  }

And this seems to work quite well. Personally, I really like this architecture, because it enables me to think about state and UI separately. One of the really big gripes I have with React is how most components end up with `useEffect` and `useState`, and then immediately become untestable. Elm literally doesn't allow for that.

At the end of the day, there's a trade-off -- my logic is no longer localized to the "component" relevant to rendering the pipeline DAG. I never have one file open editing Elm code, but I'm a vim user so it doesn't bother me. In some ways, semantically, I think it makes sense to split the "state backend" of your UI from your UI, in my opinion.

Most of my app states are represented as state machines (coming from embedded this is quite natural) and UI is represented as pure transformations of that state.

With Elm, it really feels like you reason about state and UI separately, and I actually prefer that, both for testability and that's just how my brain works.

I feel similarly. I really liked React when it came out because compared to the alternatives at the time, it just felt perfect.

I still prefer it over almost everything, including Svelte, Vue and Solid. But I have started using Crank (https://crank.js.org/) which seems a step closer to where I want to end up. However, I have so far only used it for toy projects so I can't speak to how well it will scale, both in terms of performance and DX.

> but when I see the creators of a system I trust basically deprecate it,

What makes you think I trust Apple? So yes, that's very much a "you thing".

And SwiftUI is laughably bad. And my very early criticisms of Swift, for example, have panned out precisely as I predicted.

> > Every UI is always some mapping of the state.

> but it previously wasn't described as such.

Yes it was. Except this was seen as the obvious given that it is. Because, once again, a UI that is not a function (mapping) of the model is not a UI.

"In Smalltalk-80, a view is just a visual representation of a model" -- https://en.wikipedia.org/wiki/Model–view–controller#View

> IIRC, at the time, MVC had a common problem of controller bloat,

Nope. Non-MVC implementations had the problem of controller bloat, because they didn't actually implement MVC.

> the render function of the component is a 100% pure function of the state that the framework injects.

Except, as I've correctly pointed out: it's not.

[Advantages]

None of this is in any way specific ("The compiler". Seriously?) or clearly an advantage that can be tied to this type of framework. So yes: you're not even close to convincing me. Because there's no "there" there.

> the reason why this post rubs me the wrong way, is that you took a theoretical design document, misunderstood it for the actual, practical implementation

You misunderstood the post. Completely. The document claims "pure function". This is laughably false. The question is what is left when you remove "pure" from "pure function". And the answer to that is: nothing.

That doesn't mean there are no benefits, but the benefits cannot be "what you get from being a 100% pure function", because it ain't.

Just like the benefit of butter can't be "it's 100% fat free". Because it ain't.

And if you keep insisting that those are the benefits, then I don't know how to help you.

And again, it doesn't mean there are no benefits, but they are both smaller than and quite different from what you claim. And with the benefit being fairly small, the other question is what the cost is of pretending this is so when it is not. And the answer is: pretty high.

And it's funny that on the one hand you go with the same "well, you're taking the "100% pure" thing too literally", when just a few lines above, you yourself made "100% pure function" the defining characteristic.

So which is it? Make up your mind. It appears to be Schröding-important.

Any UI that actually is a UI is some sort of function of the state. Otherwise it is not a UI but random graphics and/or decoration.

I enjoy React and I’d take it over all of those other things. I wouldn’t take React over htmx/data-star and server rendering if that’s all I needed, and even if I had a couple of pages that needed a little bit more.

I do. Though I avoid using it as much as possible because it's an overkill for practically everything like any other modern frontend framework. It's a Computer Science thing used where it should not. We really don't need to keep the state of the entire dom. It sounds great in CS, but in the real world, it ends up in bloat. Few websites other than social network sites, financial/trading sites etc ever need to update every corner of the page. The majority of the web can just do with having 1-2 interactive, auto-updating zones on each page. That's why we are going back to where we were 15-20 years ago with things like the 'islands architecture'...