Hacker News Reader

Comment by cprecioso | Hacker News Reader

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.

View on HN

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.

> 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?

in redux there's so much repetition that most of the time you do copy->paste->find&replace entity name.

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.

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

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

Elm, Elm, Elm!

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.

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.

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.

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.

I wonder more and more what Elm offers that langs like ReasonML don’t?

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.

Reply on news.ycombinator.com