4 ms·

> This is the biggest downfall of Elm projects that I’ve seen in the real world. Teams end up spending half of their time or more solving problems that could ha

> This is the biggest downfall of Elm projects that I’ve seen in the real world. Teams end up spending half of their time or more solving problems that could have been accomplished quickly with some off the shelf React libraries with numerous tutorials online. This is an important point; I think it applies to varying degrees to any less popular language or framework. It’s a little worse with Elm because of the restrictions they’ve placed on JS interop. I'll add that unless you're very familiar with the framework/language you'll be using, it's pretty hard to estimate scope of work; you'll just encounter surprises during implementation along the lines of "wow I can't be believe they don't have a library for x." On the plus side, since the work of implementing these libraries is very generic with regard to any specific application, it's easy to delegate to other employees or contractors. I’m currently working on a large PureScript project. At various times I’ve had to implement my own base libraries and components, but in many cases I’ve just been able to wrap existing JavaScript code. Some of the key libraries I use, which were developed by other community members are wrapped JavaScript libraries. This has been a pretty powerful mitigation strategy. In the case of PureScript, I also have the benefit of reusing a substantial amount of front end code on the server. For me, on this particular project, the benefits of using a language with advanced features has far outweighed the above mentioned costs, but I think you've got to look at each situation differently and do that evaluation.

Silhouette 5y ago
I'll add that unless you're very familiar with the framework/language you'll be using, it's pretty hard to estimate scope of work I think you've just defined a pretty good benchmark for when it's sensible to consider a less popular choice. Are you familiar enough with it to be confident of coming out ahead by using it? Perhaps you have a backup plan like the interop you mentioned if some functionality is missing. Perhaps the tool is so much more productive in general that you are reasonably confident any extra development work to fill in the gaps will be outweighed by the overall benefits. But there should be some clear reason you think the risk is justified.
platz 5y ago
curious if you using halogen or react-basic? I've gone with halogen for a small project and it's been fine but sometimes i wonder if react-basic is a better choice.
- aranchelk 5y ago
  This is an area where I ventured far from the ordinary and wrote my own application framework. I'll eventually open source it and write an article about the process. In short: I was completely sold on the Elm architecture, but I used Haskell too long to be comfortable working without typeclasses, so I went through a couple different elm-like frameworks written for PureScript. I settled on one only to later realize what (I think) people are talking about when they say "Elm doesn't compose", which is not well articulated in that statement. I take it to mean: you can never really deal with stateful components in isolation because they have to work off of a unified global data structure. I developed some new tech that makes different tradeoffs and it got me what I wanted. I knew developing my own framework was going to add a lot of extra work: * Writing the framework (not too bad, actually) * Writing the reusable components and combinators (exactly what you'd expect) By far he hardest part has been establishing patterns and best practices working with a new and different architecture, I struggled with that for a while. I'm a strong believer in the points made in Graham's Beating the Averages (actually what brought me to HN) and in my case I'm establishing a tech stack for my current and future projects, so I believe the framework was a worthwhile investment.
  - mst 5y ago
    I thought the idea was that you'd have layers of actions so you have a top level handler of some sort that would then dispatch a contained-within-the-primnary-action component-scoped action and then pull the new component data back into the global store. (apologies for the lumpy phrasing, insomnia is a pain)
    - aranchelk 5y ago
      That may be best practice, I'm not sure. Regardless, you can imagine as a result of that style of coding, any changes to the type of your components state will require at least some changes within the component, changes to one or more of those layers of action handlers, and a change to the initial/default instance of your applications model. I'm absolutely not an authority on Elm architecture, I just know that my experience doing stuff like forms with validation really sucked.

Silhouette 5y ago

I'll add that unless you're very familiar with the framework/language you'll be using, it's pretty hard to estimate scope of work I think you've just defined a pretty good benchmark for when it's sensible to consider a less popular choice. Are you familiar enough with it to be confident of coming out ahead by using it? Perhaps you have a backup plan like the interop you mentioned if some functionality is missing. Perhaps the tool is so much more productive in general that you are reasonably confident any extra development work to fill in the gaps will be outweighed by the overall benefits. But there should be some clear reason you think the risk is justified.

platz 5y ago

curious if you using halogen or react-basic? I've gone with halogen for a small project and it's been fine but sometimes i wonder if react-basic is a better choice.

aranchelk 5y ago
This is an area where I ventured far from the ordinary and wrote my own application framework. I'll eventually open source it and write an article about the process. In short: I was completely sold on the Elm architecture, but I used Haskell too long to be comfortable working without typeclasses, so I went through a couple different elm-like frameworks written for PureScript. I settled on one only to later realize what (I think) people are talking about when they say "Elm doesn't compose", which is not well articulated in that statement. I take it to mean: you can never really deal with stateful components in isolation because they have to work off of a unified global data structure. I developed some new tech that makes different tradeoffs and it got me what I wanted. I knew developing my own framework was going to add a lot of extra work: * Writing the framework (not too bad, actually) * Writing the reusable components and combinators (exactly what you'd expect) By far he hardest part has been establishing patterns and best practices working with a new and different architecture, I struggled with that for a while. I'm a strong believer in the points made in Graham's Beating the Averages (actually what brought me to HN) and in my case I'm establishing a tech stack for my current and future projects, so I believe the framework was a worthwhile investment.
- mst 5y ago
  I thought the idea was that you'd have layers of actions so you have a top level handler of some sort that would then dispatch a contained-within-the-primnary-action component-scoped action and then pull the new component data back into the global store. (apologies for the lumpy phrasing, insomnia is a pain)
  - aranchelk 5y ago
    That may be best practice, I'm not sure. Regardless, you can imagine as a result of that style of coding, any changes to the type of your components state will require at least some changes within the component, changes to one or more of those layers of action handlers, and a change to the initial/default instance of your applications model. I'm absolutely not an authority on Elm architecture, I just know that my experience doing stuff like forms with validation really sucked.