3 ms·

Yeah. My top 3 complaints: 1) The crazy boilerplate, the Elm architecture forces you to store all your app state in a single atom. In my experience, this does

Yeah. My top 3 complaints: 1) The crazy boilerplate, the Elm architecture forces you to store all your app state in a single atom. In my experience, this doesn't scale well and is bloody annoying (see, even the redux author say you should never store everything in the single atom/store); Also, when should state be cleaned up? When the component is shown again, but then you have stale state in the meantime; or when the component is removed? before or after it's being transitioned out? (you don't want to see a flash of empty data) 2) The snail pace at which Elm evolves. I will have delivered 3 or 4 apps for my clients by the time the single Elm maintainer added 5% of the WEB API as native Elm modules. By the time he's done, new WEB APIs will have to be covered. It's never going to end. That means, a complex Elm app always has javascript. In that case, I'd rather just use typescript and nothing else. 3) The religious focus on purity. The elm maintainer is an haskell user, and it shows. Can you believe that to read the current time or generate a random number, you must be within a component's update function, ask for one or the other and you will get your result later, asynchronously? I know some people love that their entire program are fully pure in a mathematical sense, but this always struck me as having way more cons than pros. Also, there is always "just one way to do this or that, all the other ways are disapproved by the Elm creator" The environment/community is so closed! If the Elm maintainer did anticipate your very specific need (low chance, he can't do everything by himself), the answer is: "always use that, you should never use this other thing, it's very dirty", if not, "just use this JS hack instead". This is good for beginners seeking very strong guidance, not good for power users trying to deliver stuff fast. You can tell Elm is still a beta product; it has lots of cool stuff, but even more rough edges. Otherwise the language is kinda nice and simple (some would say too simple, I don't know If I agree; maybe) and is great for teaching FP to first timers.

acemarke 9y ago
More specifically, to quote the Redux FAQ entry at http://redux.js.org/docs/faq/OrganizingState.html#organizing-state-only-redux-state http://redux.js.org/docs/faq/OrganizingState.html#organizing... : > There is no “right” answer for this. Some users prefer to keep every single piece of data in Redux, to maintain a fully serializable and controlled version of their application at all times. Others prefer to keep non-critical or UI state, such as “is this dropdown currently open”, inside a component's internal state. > Using local component state is fine. As a developer, it is your job to determine what kinds of state make up your application, and where each piece of state should live. Find a balance that works for you, and go with it.
- boubiyeah 9y ago
  Oh, this is milder than before. I had those tweets in mind: https://twitter.com/dan_abramov/status/725089775783391232?lang=en https://twitter.com/dan_abramov/status/725089775783391232?la... https://twitter.com/dan_abramov/status/759383530120110080?lang=en https://twitter.com/dan_abramov/status/759383530120110080?la... plus many other tweets. And that answer: https://github.com/reactjs/redux/issues/1287 https://github.com/reactjs/redux/issues/1287
seagreen 9y ago
> The religious focus on purity. The elm maintainer is an haskell user, and it shows. Can you believe that to read the current time or generate a random number, you must be within a component's update function, ask for one or the other and you will get your result later, asynchronously? You say this like generating a random number is a small deal. In a sense this is very true! From the machine's perspective generating a random number is a quick operation. However, from the perspective of maintainers who come after you losing determinism is no small thing, and IMHO deserves to be marked clearly in the type system.
- boubiyeah 9y ago
  I also respect this view. On the frontend, as long as I have a decent type system, I never needed to also encode effects using the type system, so I'd rather not burden the team with this if the ROI is very small.
Skinney 9y ago
1) I don't see a problem with this. If you have stale state, but no one sees it, who cares? Same thing regarding cleaning it up, if no one notices when, who cares? The great thing about storing all the data in a top-level datastructure is that you could dump that entire thing into JSON, send it along in bug reports, and then you can see the same state the application was in when a bug happened. This is gold! 2) In my experience, with typescript/javascript you instead get to deal with the fact that in the same period of time the API for webpack has changed, the api for react-router has changed twice, etc. Slow is not necessarily bad, especially considering the reason things are slow is because of the focus on doing things right. Also, just because you can't escape a tiny amount of javascript, having the rest of the application in Elm isn't worth it? How strange. 3) I admit that it sometimes is a bit annoying that you can't get things like the current time --right now--, and instead have to thread that through the update chain. But overall I find this to be a good thing. It's great when learning new code bases to easily identify where side-effects can happen just by looking at the type signature. > Also, there is always "just one way to do this or that... As a power user, this is the best thing about Elm. The fact that javascript isn't like this, is why I never want to maintain another javascript project that I didn't personally create, ever again. > You can tell Elm is still a beta product; Elm is a alpha product, so this is really a great compliment.
- boubiyeah 9y ago
  Thanks for the different perspective. And no, I wouldn't want to maintain a codebase written in a dynamic language ever again too :p

acemarke 9y ago

More specifically, to quote the Redux FAQ entry at http://redux.js.org/docs/faq/OrganizingState.html#organizing-state-only-redux-state http://redux.js.org/docs/faq/OrganizingState.html#organizing... : > There is no “right” answer for this. Some users prefer to keep every single piece of data in Redux, to maintain a fully serializable and controlled version of their application at all times. Others prefer to keep non-critical or UI state, such as “is this dropdown currently open”, inside a component's internal state. > Using local component state is fine. As a developer, it is your job to determine what kinds of state make up your application, and where each piece of state should live. Find a balance that works for you, and go with it.

boubiyeah 9y ago
Oh, this is milder than before. I had those tweets in mind: https://twitter.com/dan_abramov/status/725089775783391232?lang=en https://twitter.com/dan_abramov/status/725089775783391232?la... https://twitter.com/dan_abramov/status/759383530120110080?lang=en https://twitter.com/dan_abramov/status/759383530120110080?la... plus many other tweets. And that answer: https://github.com/reactjs/redux/issues/1287 https://github.com/reactjs/redux/issues/1287

seagreen 9y ago

> The religious focus on purity. The elm maintainer is an haskell user, and it shows. Can you believe that to read the current time or generate a random number, you must be within a component's update function, ask for one or the other and you will get your result later, asynchronously? You say this like generating a random number is a small deal. In a sense this is very true! From the machine's perspective generating a random number is a quick operation. However, from the perspective of maintainers who come after you losing determinism is no small thing, and IMHO deserves to be marked clearly in the type system.

boubiyeah 9y ago
I also respect this view. On the frontend, as long as I have a decent type system, I never needed to also encode effects using the type system, so I'd rather not burden the team with this if the ROI is very small.

Skinney 9y ago

1) I don't see a problem with this. If you have stale state, but no one sees it, who cares? Same thing regarding cleaning it up, if no one notices when, who cares? The great thing about storing all the data in a top-level datastructure is that you could dump that entire thing into JSON, send it along in bug reports, and then you can see the same state the application was in when a bug happened. This is gold! 2) In my experience, with typescript/javascript you instead get to deal with the fact that in the same period of time the API for webpack has changed, the api for react-router has changed twice, etc. Slow is not necessarily bad, especially considering the reason things are slow is because of the focus on doing things right. Also, just because you can't escape a tiny amount of javascript, having the rest of the application in Elm isn't worth it? How strange. 3) I admit that it sometimes is a bit annoying that you can't get things like the current time --right now--, and instead have to thread that through the update chain. But overall I find this to be a good thing. It's great when learning new code bases to easily identify where side-effects can happen just by looking at the type signature. > Also, there is always "just one way to do this or that... As a power user, this is the best thing about Elm. The fact that javascript isn't like this, is why I never want to maintain another javascript project that I didn't personally create, ever again. > You can tell Elm is still a beta product; Elm is a alpha product, so this is really a great compliment.

boubiyeah 9y ago
Thanks for the different perspective. And no, I wouldn't want to maintain a codebase written in a dynamic language ever again too :p