5 ms·

For the ones who want to get (a similar) developer experience while coding actual JS(X): you can use `react` together with `mobx` to the same effect. Additional

For the ones who want to get (a similar) developer experience while coding actual JS(X): you can use `react` together with `mobx` to the same effect. Additionally, take a look at `mobx-state-tree` to get more structured code. And of course, there's Elm if you want to get a completely different thing.

desireco42 8y ago
Elm, Elm, Elm!
- fbonetti 8y ago
  Elm is extremely opinionated and bottlenecked by one person. It’s great for the specific usecases it was designed for, but it gets tedious once you start interacting with external code and the outside world. The development cycle is slow and communication from the dev team is sparse. Some would argue that the slow deliberate, development pace is a good thing, but I was personally turned off by the fact that compiler bugs (and even documentation spelling mistakes) would stay open for months or years. I know somebody is going to jump in and tell me I’m wrong, that they’re using Elm in production and it’s the best, etc. This is my personal experience from using Elm on several side projects and also in production at my last job.
  - kungtotte 8y ago
    If your opinion lines up with whatever opinionated tool you use, you won't experience friction and will perceive the tool as aiding your work. It's not rocket surgery. It was the same thing when Ruby on Rails hit it big; some people swore by it and others detested it. It's like having a car that will only turn left, as long as you need to go left the car is perfect for you.
  - desireco42 8y ago
    I appreciate you sharing your experience. I think point you raised are valid. Elm works for me and makes me happy. I couldn't ask for more. Any perceived slowness in initial development is gained later by very solid foundation on which I work. Again, all you said is true.
  - boubiyeah 8y ago
    Elm actually means Elm + JS. Given 1) The language development pace (localStorage does not have an Elm equivalent, let alone service workers, etc) and 2) The Elm ecosystem is very closed and only one person can actually release powerful libraries in the blessed package manager. Make it so that Elm will still not be able to do everything we need it to to write an SPA in 5 years without javascript on the side.
- hellofunk 8y ago
  I wonder more and more what Elm offers that langs like ReasonML don’t?
  - mjaniczek 8y ago
    Elm is more constrained, eg. no synchronous JS interop; no side effects, only explicit effects, etc. As has been said in other thread, for some that's great news, for others it's limiting.
jadbox 8y ago
mobx-state-tree is really neat and feels like the next step beyond redux. Not having to create explicit event names and 'action dispatchers' is a real boon to DRY. The only issue I've had is more to do with typescript and using mobx-state-tree plus react router... the type definitions and type error messages can get rather confusing to debug.
- mieseratte 8y ago
  > Not having to create explicit event names and 'action dispatchers' is a real boon to DRY. What about an action creator / reducer isn't dry?
  - negativ0 8y ago
    in redux there's so much repetition that most of the time you do copy->paste->find&replace entity name.
  - nightski 8y ago
    You have the name of the action and the name of the action creator which essentially represent the same thing. I've never seen a project which had multiple creators for the same action name.
- gunn 8y ago
  You might like my library - no actions or reducers, and great typescript support. You just use regular JS to manipulate data and the library updates the store immutably. https://github.com/gunn/pure-store https://github.com/gunn/pure-store
erpellan 8y ago
I'm quite excited by ReasonReact. React with strong types! https://reasonml.github.io/reason-react/ https://reasonml.github.io/reason-react/

desireco42 8y ago

Elm, Elm, Elm!

fbonetti 8y ago
Elm is extremely opinionated and bottlenecked by one person. It’s great for the specific usecases it was designed for, but it gets tedious once you start interacting with external code and the outside world. The development cycle is slow and communication from the dev team is sparse. Some would argue that the slow deliberate, development pace is a good thing, but I was personally turned off by the fact that compiler bugs (and even documentation spelling mistakes) would stay open for months or years. I know somebody is going to jump in and tell me I’m wrong, that they’re using Elm in production and it’s the best, etc. This is my personal experience from using Elm on several side projects and also in production at my last job.
- kungtotte 8y ago
  If your opinion lines up with whatever opinionated tool you use, you won't experience friction and will perceive the tool as aiding your work. It's not rocket surgery. It was the same thing when Ruby on Rails hit it big; some people swore by it and others detested it. It's like having a car that will only turn left, as long as you need to go left the car is perfect for you.
- desireco42 8y ago
  I appreciate you sharing your experience. I think point you raised are valid. Elm works for me and makes me happy. I couldn't ask for more. Any perceived slowness in initial development is gained later by very solid foundation on which I work. Again, all you said is true.
- boubiyeah 8y ago
  Elm actually means Elm + JS. Given 1) The language development pace (localStorage does not have an Elm equivalent, let alone service workers, etc) and 2) The Elm ecosystem is very closed and only one person can actually release powerful libraries in the blessed package manager. Make it so that Elm will still not be able to do everything we need it to to write an SPA in 5 years without javascript on the side.
hellofunk 8y ago
I wonder more and more what Elm offers that langs like ReasonML don’t?
- mjaniczek 8y ago
  Elm is more constrained, eg. no synchronous JS interop; no side effects, only explicit effects, etc. As has been said in other thread, for some that's great news, for others it's limiting.

jadbox 8y ago

mobx-state-tree is really neat and feels like the next step beyond redux. Not having to create explicit event names and 'action dispatchers' is a real boon to DRY. The only issue I've had is more to do with typescript and using mobx-state-tree plus react router... the type definitions and type error messages can get rather confusing to debug.

mieseratte 8y ago
> Not having to create explicit event names and 'action dispatchers' is a real boon to DRY. What about an action creator / reducer isn't dry?
- negativ0 8y ago
  in redux there's so much repetition that most of the time you do copy->paste->find&replace entity name.
- nightski 8y ago
  You have the name of the action and the name of the action creator which essentially represent the same thing. I've never seen a project which had multiple creators for the same action name.
gunn 8y ago
You might like my library - no actions or reducers, and great typescript support. You just use regular JS to manipulate data and the library updates the store immutably. https://github.com/gunn/pure-store https://github.com/gunn/pure-store

erpellan 8y ago

I'm quite excited by ReasonReact. React with strong types! https://reasonml.github.io/reason-react/ https://reasonml.github.io/reason-react/