Elm's primary selling point is "no runtime exceptions". The subheader on Elm's homepage even says this[1]:
Generate JavaScript with great performance and no runtime exceptions.
Type safety doesn't come for free. If you want to build an application that doesn't have runtime exceptions, you have to specify what external data should look like, how to translate that data into a native datatype, and what to do if that expectation fails. With this in mind, you can't just write `JSON.parse(data)` and expect everything to work. What if your data has a different shape? What if it's missing fields? What if field "foo" is a String instead of an Int?
Here's a short example in Typescript:
import fetch from "node-fetch"
interface Post {
user_id: number,
id: number,
title: string,
body: string
}
const postUrl = 'https://jsonplaceholder.typicode.com/posts/1'
const show = function(post: Post) {
console.log(post.user_id)
console.log(post.id)
console.log(post.title)
console.log(post.body)
}
function getJSON(): Promise<Post> {
return fetch(postUrl).then(x => x.json())
}
getJSON().then(show)
Do you see the bug? `user_id` is supposed to be `userId`, yet this example will compile without an issue. When you run it, `post.user_id` will be undefined, even though our interface clearly states that a Post most have a `user_id` field of type `number`. The compiler won't catch this even with `--strictNullChecks` enabled.
Everything in programming is about tradeoffs. If you don't care about strong type correctness, use something like Typescript. If you do care, Elm is a great choice.
[1]: http://elm-lang.org/