5 ms·
> If you only need what's already there, Elm is glorious But how can you reliably know that'll be true in the future? Elm scared me away because I thought I'd
by iudqnolq 4y ago
> If you only need what's already there, Elm is glorious
But how can you reliably know that'll be true in the future? Elm scared me away because I thought I'd be going along perfectly fine and suddenly get a straightforward new requirement that is strictly impossible.
(For those who haven't looked into Elm the issue is that to call javascript functions synchronously you have to be whitelisted by the compiler. One of the explicit reasons for this is that the language designer thinks it's bad when there are multiple competing libraries solving the same problem).
- deleted 4y ago[deleted]
- pyrale 4y agoFor instance, the projects I worked on were professional software. People don't care so much about SSR and first page rendering speed. We also didn't need the latest shiny browser APIs, or to tweak CSS to perfection, and we reasonably could say that this wasn't going to be the case in the future. In that context where many devs were backend devs or self-taught, so using JS wasn't that important, since we were going to train anyway. Actually, training to Elm felt much saner than training to JS. However, the tech remained niche for all the reasons I quoted in my first message.