loading...

re: Comparing Elm to Ember Octane and React VIEW POST

FULL DISCUSSION
 

Hi Eber,
thanks for this great article.

As I am fan of Elm also I think you are missing some points in the Elm benefits. So I will put my view here.

The real problem here is that it uses plain strings as keys for the possible actions it can execute

Yes, in JS generally there is no way to make such approach safe. But in TypeScript you can force compiler to check if all options were handled.

Both on the React and Ember apps you will see that the "model" has a few flags like isLoading or isError

The thing is that the original author took that route as the simplest, but it doesn't mean we cannot make the model close to the Elm. We can use object literals and model Discriminant Unions. It would like smth like:

type Stories
    = { status: 'none' }
    | {status: 'loading'}
    | {status: 'error'}
    | {status: 'success', data: Story[]}

This is TypeScript, but you get the point.

We have a bug in this app. See... A story title or author can be a null value coming back from the API call

Yes but this bug can be fixed by simple condition. And in TypeScript we can model the type as Nullable - type | null and compiler enforce the check. We can even make Optional in JS/TS land, I don't prefer it though but its possible. More here - Maybe just Nullable

Despite its somewhat cryptic syntax, if you never dealt with anything like it, Elm introduces very few concepts: everything is a function ...

I agree with you 100% that Elm is superior language over JavaScript and TypeScript. And the superiority is in simplicity. Yes language is small, simple, there is in most one way of doing staff, one possible compiler, one possible code style and so on. The problem with that is - many devs have hard time to switch from c-type language with brackets and statements into expression based, for many it is a barrier which is hard to overcome. Elm requires to change the mindset.

Also for some things Elm looks very cumbersome, as it is pure language we cannot just make side-effect. So such simple tasks like - get current time are far more difficult than in JS land. Yes I know why, but for many such trade-off not pays of and I see the point. We are quite far away from the metal, and when in React/Ember we can just make some "kernel" code whenever we need, in Elm is not so simple.

What I want to say, despite the love I have to Elm, there are trade-offs which can be hard to accept for many.

 

Hi Maciej,

Thank you so much for your comments! I have only a couple of things I want to comment on...

Yes, in JS generally there is no way to make such approach safe. But in TypeScript you can force compiler to check if all options were handled.

The keyword for me here is "can". In Elm, even if I have chosen to use plain strings for my messages I still would need to account for all of the possibilities, ultimately using a catch-all condition (maybe TS does that as well? I don't have any significant experience with it). Anyway, that is something that Elm will force me to do, I don't have the option not to and for me that is a major pro.

TS is a huge step forward from plain JS but TS alone won't prevent you from doing things that might hurt you in the future. Add to that the possibility of using the any type and things might derail pretty quickly. Despite the possibility of writing correct code, TS won't really prevent you from writing bad code at all and the beauty of Elm for me is that it makes really hard to do so.

Yes I know why, but for many such trade-off not pays of and I see the point.

Yeah, I think you are right. For me what clicked was the idea that I'm paying upfront a smaller price for something that could cost me much more in the future. So a few things might actually be cumbersome to deal with, but it pays off in the long run.

code of conduct - report abuse