A year ago I started using Elm for a side project where I wanted to let my users go beyond typical Markdown and templates and apply their own processing rules on html/css generated by an Elm view. Unfortunately I discovered Elm's libraries aren't really intended for that - a view can trivially create html nodes but you can't transform those same html nodes in the obvious way because their attributes aren't readable. If you want something you can transform in multiple passes you have to use your own IR or html wrapper.

Maintaining a redundant IR just to be able to transform attributes wasn't a price I was willing to pay for a fun side project so since Elm really didn't want me to work with the generated html the way I wanted to I looked around and decided to give Yew a try. Unlike Elm, Yew gives you a way to include arbitrary html in the rendered output. Accessing third party javascript with wasm-bindgen is also much simpler than using ports or custom elements in Elm.

Well after playing around with Yew a bit I found myself missing the effortless refactoring experience I had working in Elm so I decided to come back to Elm and go with a hybrid approach. Now I have static html/css with small Elm modules for forms and simple views and a completely separate app does the transformation. This wasn't the architecture I originally had in mind but overall I like it better.

Having said all that I can sympathize with the author's frustration. It's really really irritating when you encounter something that you think should have a trivial solution but turns out to be hard in Elm because of the choices the Elm developers made. In my case I felt like I was on a luxury cruise that was fun 99% of the way until finding out their policy was that I had to swim the last 1% on my own.