I'm not sure this is a fair criticism. The nice thing about this tiny chunk of code is that there is only one aspect of this example program that needs to manipulate the already instantiated DOM, and that tiny chunk is explicitly brought up to the top level and separated and connected back to the program via the port mechanism. It would certainly be worse if this magic happen behind the scenes.

Of course it could be better, and that's probably what you are getting at. Ideally the machinery provided for building web applications would be more aware of the nature of web applications and have something in the box (still explicit and obvious, but in the box) to do something like setting focus.

It's absolutely a fair criticism. The real DOM is stateful, elm's virtual DOM is not, and elm doesn't provide any tools to manipulate the state of the real DOM. This impedance mismatch is bound to cause problems any time you are dealing with the stateful aspects of the DOM. And solutions like the one linked to by GP are error prone and fragile.

This is certainly annoying at the moment (although there are workable hacky solutions). However it's a well known issue and there is movement at https://github.com/elm-lang/html/issues/19 so hopefully it will be addressed in the near future.

Elm gives you the ability to hook into requestAnimationFrame, which allows you to execute some native js through a port when a piece of html first renders.

I have the same issue on React components as well. Had to implement setTimeout in componentDidMount.