4 ms·
> I had to stop because [...] and depended on some WebGL 3D and game libraries. There's a limitation of Elm hidden in there. If your code needs to interoperate
by idoubtit 5y ago
> I had to stop because [...] and depended on some WebGL 3D and game libraries.
There's a limitation of Elm hidden in there. If your code needs to interoperate with some JavaScript libraries, you need to define an Elm port for each action (i.e. define how Elm sends/receives "messages" to JS). If the Elm-JS messages are few, it's OK, but if not, the process is painful to code and slow to execute.
- cies 5y agoThis is true for interaction between pure functional code and the "outside world". It forces you to state all out assumptions about said interaction up front and often deal explicitly with all possible errors that may arise from your assumptions failing. Once that is done you can stay mostly in "pure land", which is quite a blissful experience.
- kadoban 5y agoThis seems more like a network effect than a limitation of Elm. A bunch of libraries are written in JS so of course that's going to be the least friction and fastest way to use them.
- dhucerbin 5y agoThat's only half of the story. Elm prohibits glue code. You can't take well tested JS library, write FFI definitions (like Rescript/Purescript) or typings (like TypeScript) and publish it. You can only publish pure Elm packages. That also means that you can't use WebAPIs if they are not wrapped in packages whitelisted by Elm core team. There are only two methods to interop with javascript and they both have massive downsides. WebComponents are WebComponents and even then Elm is very picky how you can write those. Ports are nice for heavy/async work but are unusable with small functional-ish APIs like Intl.