There are languages, frameworks, and libraries that strive to enable you to accomplish relatively complex tasks by writing a few lines of code. Jav...
For further actions, you may consider blocking this person and/or reporting abuse
To bring the point home, I would suggest showing version 2 of the Javascript code that fully implements all the protections and use case of the Elm version at the end. I don't think people fully appreciate what strong typing does for you if they've only ever coded in Javascript or. other dynamic languages. Excellent article. The point of simple vs simplistic was spot on.
The title is just a bit... misleading. is ELM really simplistic?
Simplistic - treating complex issues and problems as if they were much simpler than they really are.
I think simplistic solution is to wrap
await fetchinto try/catch. Better but less simplistic solution is to have own wrapper for fetch (or axios) with default error handling.2-3 times more lines count, all native APIs are wrapped into ELMs, Result type is used but not obvious where is it coming from, somehow you need to know and write return type of functions, like HTTP.get returns Cmd Msg. And in the end, only small community of people will be able to support your code.
Hey Roman, thanks for your comment.
This article is a translation from my original post (in brazilian portuguese, my native language) so maybe that's causing some noise in the translation.
But to better understand what I meant as being "simplistic", think about this definition (taken from wordnik.com/words/simplistic):
"Simplistic. Adjective. In a manner that simplifies a concept or issue so that its nuance and complexity are lost or important details are overlooked."
So the goal is not to say that we all should use Elm (as I tried to say in the conclusions, I still use JS/TS on some projects, and that's fine), but to always try to find the simplest solution that do not overlook the important details.
Your idea of using a wrapper around fetch to make it safer is exactly the kind of thought I was hoping to rise. And using the definition of "simplistic" above, your idea (if well implemented) could be a nice and simple (not simplistic) solution.
But it may be a little tricky to create a wrapper that also handles the situation of a return in an invalid format, for example. Or a return where a field is optional, and so on.
Languages like TypeScript take a step toward trying to help in these scenarios. Elm takes many other steps in this direction. But which language to choose is not the central idea of this post. JavaScript is a good technology, but we need to act even more proactively on these potential problems in this language.
Thanks for explaining, so you wanted to show that ELM takes care of data integrity so developer can keep calm and this is why it's "simple". And if it makes sense to always validate JSON data from server instead of trusting it - that's another question, for developer to decide, depends on situation
Yes, but not just data integrity. That was just the main example, but Elm takes care of all possible runtime exceptions. All those errors on the browser console? They never happen when you are using Elm. A little too extreme? Maybe. But Elm makes it so easy that I believe the benefits compensate the efforts.
But as you said, it's for the developer to decide, and I agree. But it's important we make an informed and well thought decision.
You might be interested in Hegel:
hegel.js.org/
It's a sound type checker for JS - enforces exhaustive checking for type unions and more of that Elm goodness.
I do wish this got more traction. I wish any language with sound typing got more traction and interest for that matter. Next level stuff for sure. 🙂
Hello Rasmus.
I wasn’t aware of it, looks really interesting! I will definitely experiment with it. Thanks for sharing.
TLDR; MVC helps structure code
I’m not a big fan of MVC for front end development. I prefer MVU (Model-View-Update, which is the same as The Elm Architecture). But yes, a good architecture helps a lot :)
guide.elm-lang.org/architecture
But the main focus on the article is not architecture per se, but the lack of care with runtime errors and such. I’ve seen pages created in js/react/redux with nice architecture and near 100% test coverage, and yet it was giving abnormal runtime errors during a presentation due the lack of care with http timeout issues. My guess is that that happens because most libs do not force (or even encourages) the handling of this kind of exceptions. And I think Elm does a great job avoiding this kind of pitfalls.
As long as you separate View, Storage(Models Types), Events(Controllers, Update), (maybe even separate business logic if necessary) a project is so much easier to read.
I know it's not really topic-related but why did you use a promise chaining in an async function? Seems redundant
I'm not sure if I understood what you said, but the
(async function() {is necessary otherwise I'll get aUncaught SyntaxError: await is only valid in async functions, async generators and modules.And I used a
thenchaining just because I find it more declarative (a more functional style code).And if I take off the
asyncand theawait, then thehideLoadingMessagefunction will run before thefetchfinishes. But maybe I could chain it as well, or something, and then theasync/awaitcould be taken off.