Hey thanks for the reply. Yeah I noticed in my original message I didnt go into any of that. I do mostly feel like Elm wasnt presenting any technical barriers to our development. I dont want to be unfair to the folks at the company who didnt like Elm, who probably did feel that Elm presented blocking technical problems. So let me try and list out some tense technical topics that maybe approximate what the other side felt was a blocking technical problem.
Our Elm projects used a lot of ports for http requests. This is because our company already had a strong frontend JS api project that was re-used everywhere for these kinds of requests. One day we tried to do all the http for an Elm project wtihin Elm, just to see how it would go. We quickly ran into problems with how to store and refresh an api token in the Elm model. No one had a really good idea on how to do that in our existing set up. I remember that being an embarrassing day for the pro-Elm side of the discussion because others felt it should be trivial.
This is a non-problem for me now, simply because I now know how to do this well in Elm. We really were on the bleeding edge of Elm development, and I dont think good examples even existed online. I think the competing JS implementation for how to do the API token stuff relied on mutable JS objects, which, I guess would indeed make the problem a breeze, at a big sacrifice to our stability. I remember some of us were looking towards Haskell for inspiration, and I think the leading example relied on typeclasses and very effect-ful and IO heavy operations.
Reusable view components
At least in my project, I feel like we suffered a lot of “similar is different than same” problems regarding our UI components. Two spots in the UI would look very similar but had subtle differences, that would tempt me to make a re-usable component. But, the subtle differences masked the code complexity involved in making one common reusable component, and that complexity was great enough to undermine the point of reusable components altogether. So, personally my solution was writing a lot of duplicate code manually. The amount of duplicate code I was writing might not have impressed the Elm-skeptics in the company.
Just like the previous point, this just is not a problem for me anymore. It took time, but I and seemingly the Elm community as a whole gradually learned good ways of making code re-usable in Elm. In some ways this is not even an Elm specific problem. The way I think about reusability now is not an Elm specific domain. Its just a nut you have to crack in every language and I could have gotten it wrong in React too.
As the 0.19 release approached, I think we knew the api for url navigation in 0.19 was quite strict, and that in 0.19 you could only do url navigation if your Elm app had control over the whole page. Well, guess what! We had a lot of small Elm widgets that did navigation, so in order to migrate we would probably have to come up with our own solution that involved a lot of ports. I recall someone saying “Evan thinks we are stupid” in reflection on this, as in, Evan wrote an api to force us to take a certain approach, which implies he doesnt think we can make this choice ourselves.
It seems like the Elm-skeptics had a point, that Evan did in fact add difficulty to our ability to upgrade. Whether or not this additional difficulty on our end was justified in the grand scheme of things, or whether or not it was a good design to begin with, are two questions I just dont know the answer to. But, either way, the whole topic was not relevant in any practical way: we were not at the moment trying to upgrade to 0.19; we didnt necessarily even need to upgrade to 0.19, 0.18 was doing great; and the upgrade path we did have to 0.19 was not in fact overwhelmingly difficult. So, in my view, which sides of the discussion were right had little relevance to writing Elm code; but it was probably taken as a sign that Elm is going to create big problems for us anyway.