4 ms·

I had the same viewpoint, but something keeps me coming back to Elm for curiosity. I think if NoRedInk can use it for all their client side stuff then it must b

I had the same viewpoint, but something keeps me coming back to Elm for curiosity. I think if NoRedInk can use it for all their client side stuff then it must be capable and all of the advantages outweigh the annoyances enough to stick with it for a commercial setting. My analogy there is Agile. Years ago no company would do agile and probably because no other company was doing it. Then Thoughtworks etc. started doing it, and slowly the proof that it can work spread around. I think this could happen with Elm. But like agile I think there is some counter-intuitive ideas, sort of 'go slow to go fast' type of things that you need to get your head around. I struggled and still struggle but I want to give Elm a fair go. My peeves were: 1. Can't component-ize like React. 2. Lots of 'boilerplate' to wire things up. 3. No promise like API for async, you need to do stuff via pub/sub and ports. However the counter points seem to be that. 1. You don't need components - design a good model data structure and work out from there. There is a good video talk about this at an Elm conf. 2. By making us us wait and use ports for a lot of things in the meantime (and not just adding everything to the language or letting anyone use vanilla JS in their packages) the modules that you do use are "pure" and are almost guaranteed not to crash. And the API's of Elm are well thought out because there is no rush to fill in all of the web platform. This sort of thinking sounds like the "100 year language" way of thinking that PG writes about. What sort of language will we be using in 100 years? Hopefully something well thought out, not full of baggage because it was rushed.

dorian-graph 7y ago
> 1. Can't component-ize like React. Yes you can, whether should, is a different question. You can have a ton of mini TEA components. > 2. Lots of 'boilerplate' to wire things up. Very true. Generating code helps with that. > 3. No promise like API for async, you need to do stuff via pub/sub and ports. What are you using async for? API requests? Then those are async.
- sunseb 7y ago
  > Yes you can, whether should, is a different question. You can have a ton of mini TEA components. But can you make parent-child communication with these mini TEA components like in React or Vue? It seems to me that we can't.
- KurtMueller 7y ago
  1. Interestingly enough, Richard Feldman's elm-spa example is composed of a lot of different TEA components. 2. I think the boilerplate is good in making things explicit.
  - cuddlecake 7y ago
    > 2. I think the boilerplate is good in making things explicit. I think Boilerplate is the lack of a more succinct way of expressing your intent. So, boilerplate is never good in making things explicit, it's just the (current) shortest way possible to accurately expose your intent. For example, in TypeScript, if I delve into making datastructures `algebra-ish`, I always have the boilerplate of defining a `tag` field in my objects, and lengthy switch-constructs to match on the tag field. It's not good in making things explicit, it's actually just the only way (at the moment).
  - mc3 7y ago
    I don't think RF is against TEA components. But you just don't need to TEA all the things [1] - and to do so introduces a lot of work, and moreover reduces the deep thinking you should be doing about what data structures you need and building the view around it. But in react is is natural to say "oh I need a spinner, let's make a functional react component for that". And you can always keep some local state in React and avoid the message passing relay-race you'd have in Elm with the same approach. So Elm benefits from a different approach. [1] https://youtu.be/RN2_NchjrJQ?t=2136 https://youtu.be/RN2_NchjrJQ?t=2136
- dorian-graph 7y ago
  > But can you make parent-child communication with these mini TEA components like in React or Vue? It seems to me that we can't. I think parent-child communication isn't necessarily the right way to tackle problems. Otherwise, I'll link to the oft-linked "Child-Parent Communication in Elm: OutMsg vs Translator vs NoMap Patterns" [1]. [1] https://medium.com/@_rchaves_/child-parent-communication-in-elm-outmsg-vs-translator-vs-nomap-patterns-f51b2a25ecb1 https://medium.com/@_rchaves_/child-parent-communication-in-...

dorian-graph 7y ago

> 1. Can't component-ize like React. Yes you can, whether should, is a different question. You can have a ton of mini TEA components. > 2. Lots of 'boilerplate' to wire things up. Very true. Generating code helps with that. > 3. No promise like API for async, you need to do stuff via pub/sub and ports. What are you using async for? API requests? Then those are async.

sunseb 7y ago
> Yes you can, whether should, is a different question. You can have a ton of mini TEA components. But can you make parent-child communication with these mini TEA components like in React or Vue? It seems to me that we can't.
KurtMueller 7y ago
1. Interestingly enough, Richard Feldman's elm-spa example is composed of a lot of different TEA components. 2. I think the boilerplate is good in making things explicit.
- cuddlecake 7y ago
  > 2. I think the boilerplate is good in making things explicit. I think Boilerplate is the lack of a more succinct way of expressing your intent. So, boilerplate is never good in making things explicit, it's just the (current) shortest way possible to accurately expose your intent. For example, in TypeScript, if I delve into making datastructures `algebra-ish`, I always have the boilerplate of defining a `tag` field in my objects, and lengthy switch-constructs to match on the tag field. It's not good in making things explicit, it's actually just the only way (at the moment).
- mc3 7y ago
  I don't think RF is against TEA components. But you just don't need to TEA all the things [1] - and to do so introduces a lot of work, and moreover reduces the deep thinking you should be doing about what data structures you need and building the view around it. But in react is is natural to say "oh I need a spinner, let's make a functional react component for that". And you can always keep some local state in React and avoid the message passing relay-race you'd have in Elm with the same approach. So Elm benefits from a different approach. [1] https://youtu.be/RN2_NchjrJQ?t=2136 https://youtu.be/RN2_NchjrJQ?t=2136
dorian-graph 7y ago
> But can you make parent-child communication with these mini TEA components like in React or Vue? It seems to me that we can't. I think parent-child communication isn't necessarily the right way to tackle problems. Otherwise, I'll link to the oft-linked "Child-Parent Communication in Elm: OutMsg vs Translator vs NoMap Patterns" [1]. [1] https://medium.com/@_rchaves_/child-parent-communication-in-elm-outmsg-vs-translator-vs-nomap-patterns-f51b2a25ecb1 https://medium.com/@_rchaves_/child-parent-communication-in-...