Comment by kcarnold | Hacker News Reader

Comment by kcarnold | Hacker News Reader

Parent Full thread

I really want to like Elm. When I'm writing JS/React code, I sometimes think "this would be so much nicer in Elm!" - especially for architectural issues. But the few times I’ve actually tried doing something in it, I find that the parts of what I want to do that fit cleanly within Elm’s walls are really nice, but the parts that don’t quite fit get hard quickly. Suppose I want to do something with the DOM that doesn’t quite fit into virtual-dom’s model -- I suddenly have to make a complicated JS interop and work around things to get at the raw DOM node... whereas with React I can just hack something together, try it with users, and learn that I should actually be doing something completely different anyway. Or maybe I don’t actually know yet what I want to have happen in every possible condition? Maybe I feel this way because I just don’t have enough experience, but it may be a fundamental trade-off involved in how Elm makes it hard to do things wrong.

Has anyone had some positive experiences with prototyping / rapid design iteration with Elm and can share some tips / encouragement?

Similar experience. Once you get to grids and calendar controls it is a hassle with no clear path.

I think two things are require for to solve this:

1. Some way to make it easy to drop in components into an existing view. Global state makes this hard, but it may be possible with some of Haskell's funky features, or even just type classes.

2. With the above we just need people to write some basic controls for Elm and give them more features. We need an ecosystem.

They really seem to be staying in the global state camp. I find it impractical too, but it would make their "time travelling debugger" and other similar tooling stop to work if components could have local state.

Global state is OK, but I think we need language features or sugar to help embed the components. If those language features can be nice mathematical generic features like you have in Haskell that is better.

An example is a calendar control, in a grid control in a tab. You click right to go to the next month. That event needs to be bubbled through layers of boilerplate code to direct it back to the calendar's view.

Also another consequence is that the model is a mix of business data and UI state data. The selected month shouldn't affect the business logic, but it is bundled with THAT data which is annoying.

Not sure what the solutions are though.

While it's easier to bang out code with React, you have to acknowledge the massive downside of that flexibility: you have zero guarantees that your code will work properly. Even if you use Typescript or Flow you still you won't have the guaruntee that your code accidentally "fire the missiles", because JavaScript is not a pure language.

I totally understand that DOM access is a pain point for Elm developers right now. I often run into that issue myself. But declaring a port is a small price to pay for the all that the Elm compiler gives you. When I have to refactor a React/Redux app, I absolutely dread it. With Elm, I love it, even if the project is older or unfamiliar.

Yes, purity goes an extra mile; but refactoring a functional typescript codebase (and I'm not talking about codebases written with typescript like if it was javascript) is also really pleasant, especially with the flawless Atom/Visual Studio typescript support.

Similar experience, especially if your ambition is to have a very neat application with rich components. Elm elegantly solves 70% of the problems, it's awful at the other 30%.

If we have to use JS via ports (and it has to be asynchronous! dang) to achieve complex things anyway, why not use typescript, which can do absolutely everything you need without the language context and async switch?

Is the virtual/real DOM chasm difficult to traverse in vue.js?

Reply on news.ycombinator.com