Check out this comment for an explanation of why Ports cannot possibly cover all use cases: https://www.reddit.com/r/elm/comments/99bzf8/elm_or_reasonml...

Ports are an asynchronous interop boundary. You basically subscribe to a port from Javascript and attach a callback to handle data as it passes from Elm -> JS. Javascript errors then are relegated outside of Elm or they fail at the boundary (like serialization errors when passing data from JS to an Elm port). They're kept outside of Elm.

Native modules, on the other hand, let you create Elm functions that synchronously call Javascript. That means that what look like regular Elm functions can now synchronously blow up at callsite inside Elm.

The first native modules I saw in the wild as a beginner were people making shortcut functions for things like `Math.random()` instead of the proper way of threading a random seed into the entry point and keeping it in the model which has various benefits. Same with quick access to "Date.now()".

From this perspective, you can see why native module access was removed, and especially why you needed permission to publish a native module Elm's package repo. Native modules are tempting because they are easy, but widespread use eliminates one of the major upsides of Elm: no runtime errors inside Elm, or rather the ability to boundary them.

However, some forms of JS interop are hard or impossible without synchronous FFI, 1:1 JS library wrapping being the most obvious example. Having to use asynchronous ports for that is like wrapping a Javascript library's sync functions with an EventEmitter. You emit an event and then listen for the resulting event. Maybe you even decide to pass in a messageId echo for request/response reconciliation (I've seen people build this abstraction around Elm's ports!).

On one hand, a lot of people have the idea that because they are using Elm, they shouldn't have to write any Javascript at all. After all, this is what many compile-to-JS languages give you.

And on the other hand, no more synchronous FFI means that some Elm apps that exist today cannot move ahead, and some people think the approach is too heavy-handed or they disagree with the direction.

In my experience, Elm is best seen as a way to build a functional core that you wire up to an external world of Javascript. For example, a game simulation that emits game states over a port, and you write Javascript to render those updates with a JS library like Pixi.js, resisting the temptation to wrap Pixi.js in Elm and calling it from Elm.