I might get a chance to pitch Elm in a green field rewrite of a messy pile of React + Redux + a combination of other state management systems. Everything is overarchitected and too hard for remaining developers to follow and the object-oriented wrappers written around all of these React and Redux things (I know) are so tightly coupled that to address the underlying performance issue around traversing up to hundreds of thousand nodes in the UI thread is probably going to be easier with a rewrite. There could also just be a ton of inefficiencies beneath the rug doing way more loops than needed/we've spun up a REST server from Electron for whatever reasons/you get the point.
After discussing with coworkers, it seems what the 'correct' solution would be to decouple literally everything from the UI and throw it in a web worker. This separation of concerns makes sense with this many nodes being traversed/etc. So basically in TEA, the web worker would do the all Commands and updates in the worker and `postMessage` out when the data updates--allowing the UI thread to only be responsible for the view, rendering the model. This approach on paper seems like it could be a general good idea for general state management--or even say `Html.App.Program` and/or the virtual DOM library to use these things behind the scenes. I could see without it being an integration I could still use `Elm.MyApp.worker` inside a web worker and doing only state management, but when it comes to trying to `postMessage` `MyMsg Payload` out, I'd likely lose the context of the union type when trying to biderctionally `port->postMessage->port` between the UI and the Worker and would have to have something decoding string and payload types with the way Elm exists today (which would lead to a ton of complexity around just that piece). What I'd like to know is if this is a) a good idea/am I overthinking something, b) feasible. I'd really like to pitch Elm so I can possibly work on it full-time instead of giving talks and half-assing side projects. I know it can fit the bill in most directions because the data structures and vdom rendering are quick, but I'm worried that if everything's still on the UI thread, I might continue having thrashing/unresponsiveness. I know I could try to batch some of these calls better with on-demand data calls, but I could still potentially see perf issues decoding huge JSON blobs into Elm's immutable records and complex updates. - toastal -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
