Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why I’m Leaving Elm

lukeplant.me.uk

Post reply on HN
Print view View original

431–440 of 450 posts

Re: Why I’m Leaving Elm

#431

Post by palerdot »

a_c wrote: post #122
jlokier wrote: post #80

For me, the best thing I got from this critique was the link to this 2018 talk by Evan: The Hard Parts of Open Source, https://www.youtube.com/watch?v=o_4EX4dPppA I found Evan's talking style really entertaining and enjoyable, and I totally relate to the first part about "why don't you just..." and "have you thought about delegation..."! The HN comments here are near uniformly negative towards Elm and supportive of L…

Reminds me a comment made by Rich Hickey https://news.ycombinator.com/item?id=15425632 Quoting top comment: “The presumption that everything is or ought to be a community endeavor is severely broken.” I believe in the BDFL model but can see history repeating itself. Being open source doesn't mean everyone is equal, and it shouldn't

I think you are missing the whole point of this discussion and it is no way similar to the Cloure/Rick Hickey incident. No one is asking for disproportionate say in language design. Everyone agress on that.

The problem with Elm is their messaging about their production readiness, luring people to try things out for critical production systems and then pull the rug out from under in the name of 'this should be the right way to do things; you are doing it wrongly', when people are already neck deep with their solutions in their production systems.

As an aside, there is no way we can compare Clojure to Elm, as the former is unimaginably brilliant in giving access to the host/target platform (JVM) so that people can get all the benefits of the battle tested libraries of Java/JVM. This Elm saga is completely the opposite. Elm core team is trying so hard to prevent people from using more tested and stable solutions from the JS world without offering them an alternative.

Re: Why I’m Leaving Elm

#432

Post by emerongi »

gdotdesign wrote: post #427
emerongi wrote: post #416

Earlier quoted context omitted.

Mint looks cool! Maybe this is answered somewhere, but what would you say is the differentiator between Mint and Svelte? Many of the design choices seem similar. I am in the position of starting a new hobby project soon myself and currently Svelte is the one I have landed on. Thank you for your efforts.

Thanks :) Mint has what Svelte doesn't: - consistent language with a good type system - at its base it is a functional language - styling is built in - https://www.mint-lang.com/guide/reference/components/styling... - routing is built in - https://www.mint-lang.com/guide/reference/routing - language constructs for error handling - language constructs for asynchronous tasks - compiles to Preact so the build output is…

Thanks for the great answer, very comprehensive. I will try out Mint :)

Re: Why I’m Leaving Elm

#433

Post by girishso »

cultofmetatron wrote: post #118

This came at an awkward time. I just bought Richard Feldman's book "Elm in Action" a few days ago and was working through the first 2 chapters. This has made me reconsider my intention use Elm in my startup. Having features randomly fail on me and having to rewrite an entire library in elm vs calling out to js means less time creating features that matter to my customers! I was drawn to elm as a way of spending less…

Just sharing my experience with Elm. Using it in production for over two years, 150K LOC elm codebase. Yes elm does have some problems, but I’ll choose elm over react/vue etc. for new project, simply because of the awesome development experience.

Re: Why I’m Leaving Elm

#434

Post by smaudet »

I have wondered, it seemed like there was a community of dev professionals who had managed to make things work for them, they could have forked the project easily? The ideas were nice, nobody needs the sort of toxic behavior being exhibited by the ELM core devs.

Perhaps its a case of wanting something for nothing...this is a long post and a lot of mental energy better put into a fork, and getting like minded folk involved. New users also quickly discover that the language is unsuitable for use, there would be many interested in such a thing.

Re: Why I’m Leaving Elm

#435

Post by eternalban »

salimmadjd wrote: post #113

I believe Elm took some major missteps. Despite doing so many things right with the initial designs (and still one of the best designed front-end experiences) it never grew much beyond the early adopters and it basically remained a fun hobby language. I criticized the basic lack of communication and the infrequent updates in r/elm (I believed these infrequent updates were going to kill the momentum of Elm). I was con…

> Immediately, after posting it was clear it was a major concern by others as well. So what did Evan do with that criticism? He spent the opening part of his European talk mocking it [0].

I just watched that segment. He argued his position with a satirical touch. A summary of his position that characterizes him as "mocking critics" is inaccurate, imo.

Re: Why I’m Leaving Elm

#436

Post by yhoiseth »

palerdot wrote: post #430
anthonybullard wrote: post #417

Earlier quoted context omitted.

I've personally never seem them say "the language is done, you can expect no breaking changes". Hence the fact that it is v0.19

> the language is done, you can expect no breaking changes Well ... I don't use Elm in production. But, I'm sure there are people out there who got gaslighted because of this ill-conceived move, and they can better explain about 'production readiness' story that was weaved around Elm. > Hence the fact that it is v0.19 I also don't understand how can a minor version 0.18 -> 0.19 completly break backwards compatibility…

It's in line with semantic versioning, point 4 [1]:

> Major version zero (0.y.z) is for initial development. Anything MAY change at any time. The public API SHOULD NOT be considered stable.

1. https://semver.org/#semantic-versioning-specification-semver

Re: Why I’m Leaving Elm

#437

Post by palerdot »

yhoiseth wrote: post #436
palerdot wrote: post #430

Earlier quoted context omitted.

> the language is done, you can expect no breaking changes Well ... I don't use Elm in production. But, I'm sure there are people out there who got gaslighted because of this ill-conceived move, and they can better explain about 'production readiness' story that was weaved around Elm. > Hence the fact that it is v0.19 I also don't understand how can a minor version 0.18 -> 0.19 completly break backwards compatibility…

It's in line with semantic versioning, point 4 [1]: > Major version zero (0.y.z) is for initial development. Anything MAY change at any time. The public API SHOULD NOT be considered stable. 1. https://semver.org/#semantic-versioning-specification-semver

> Major version zero (0.y.z) is for initial development

> Anything MAY change at any time.

Thank you for clarification. So, now it begs the question how did Elm team persuaded people to try out their language in production if it is still in initial development and anything MAY change at any time ...

Re: Why I’m Leaving Elm

#438

Post by orestarod »

nathanasmith wrote: post #425
hitekker wrote: post #423

Earlier quoted context omitted.

I think the idea that most people are nice to some people, and not nice to others is a generally accepted premise.

>I think the idea that most people are nice to some people, and not nice to others is a generally accepted premise. Nothing I said implied I disagreed with that "premise" and it seems bizarre how what I did say could somehow lead to your non sequitur of an answer. At any rate, what should have been obvious I was taking exception to was the idea that "plenty of people are overly polite because it inflates their ego to…

Like you said, anyone's motivation for their actions can be questioned. Everyone's motives are questionable. I don't think an article is needed to argue about that. I, personally, am kind to many people just because it is troublesome not to be, or to extract specific behaviors as a return. I managed to get a driving license without bribing (bribing for that is standard practice here), because I was so overly polite and non aggressive during training that my instructor genuinely believed I was one of the few pure souls left on this planet. The instructor then managed to persuade the examiner of my driving test that the reason I was not paying was because I was naive and really thought I could drive making zero mistakes, not because I was trying to get away with it ( if you don't bribe, a single tiny mistake is enough to get cut, and you can't really avoid it if the examiner wishes, also the examiner and the instructor share the bribe). That saved me about 150 euros. That's politeness ft or you.

Re: Why I’m Leaving Elm

#439

Post by ybit »

https://github.com/dmjio/miso

Miso was written exactly for Haskell enthusiasts who want the simplicity of an Elm interface without sacrificing too much performance. The benefits I’d say are thus:

• Type sharing (A lot of web dev becomes boilerplate -- serializing and transferring state is a large part of the work of web dev. Type sharing ensures correct-by-construction serialization between server / client amidst any changes to your business logic data types, allows you to focus on your apps core offerings as opposed to minutia).

• Rich ecosystem (the Haskell ecosystem has many great libraries that compile w/o any problems on the frontend).

• Concurrency (Programming with threads and synchronization primitives is now first class in the browser)

• Extensibility. (Compared to Elm’s ports feature, the GHCJS FFI is a much simpler way to interface with third-party libs. Also, Haskell supports typeclasses, and Generic programming, a rich lens library, etc.)

• Community involvement (You’ll be working directly at the intersection of a lot of interesting developments in GHC, specifically around cross compilation, syntax, lenses. Any new advancements to GHC has an impact on your frontend code. Also, many PhDs use, love and contribute to Miso. These people tend to be very smart, empathetic and intellectually curious as opposed to dogmatic and contentious that can be found in the software engineering industry at large today).

• Nix, a one-tool-to-rule them all for dev, build, and deploy. While not easy, deterministic builds are the future and help one to sleep at night (I’ve found). It can be used solely for personal dev, or for an entire organization, and anything in between.

• Virtual DOM. (If your Haskell web framework does not handle the tedious task of DOM manipulation for you, you have been failed as a library consumer IMO. Miso has a very well-tested, simple recursive micro virtual DOM diffing library that can exist standalone and can detect regressions in performance via a benchmark suite).

• Simplicity. (Unlike many other ivory tower libraries in Haskell, Miso maintains a simple interface. Many different common abstractions were explored in the early stages of development (free monads, FRP, etc.) and found lacking, unnecessary or replaceable by a simpler solution without sacrificing features. Miso does not attempt to hide behind complex type-level abstractions and blame end-users for their lack of understanding. As opposed to a top-down approach that shoe-horns an abstraction into an environment where it does not belong, Miso takes a bottom-up approach to fully understand its environment, the browser, it’s APIs, the DOM and its short-comings and provide a simple commonly-used abstraction to the end-user that can scale to large applications. This also makes it easier for newcomers to Haskell to get up and running quickly).

• Industry adoption. (Several companies are using miso in production for various things in their company, from full product to internal tools / data visualization).

• Isomorphic. Due to the rose tree structure of both the DOM and HTML, pre-rendering increases load-time and overall UX along with correct SEO.

Re: Why I’m Leaving Elm

#440

Post by ybit »

https://github.com/dmjio/miso

"""

Miso was written exactly for Haskell enthusiasts who want the simplicity of an Elm interface without sacrificing too much performance. The benefits I’d say are thus:

• Type sharing. A lot of web dev becomes boilerplate -- serializing and transferring state is a large part of the work of web dev. Type sharing ensures correct-by-construction serialization between server / client amidst any changes to your business logic data types, allows you to focus on your apps core offerings as opposed to minutia.

• Rich ecosystem. The Haskell ecosystem has many great libraries that compile w/o any problems on the frontend.

• Concurrency. Programming with threads and synchronization primitives is now first class in the browser.

• Extensibility. Compared to Elm’s ports feature, the GHCJS FFI is a much simpler way to interface with third-party libs. Also, Haskell supports typeclasses, and Generic programming, a rich lens library, etc.

• Community involvement. You’ll be working directly at the intersection of a lot of interesting developments in GHC, specifically around cross compilation, syntax, lenses. Any new advancements to GHC has an impact on your frontend code. Also, many PhDs use, love and contribute to Miso. These people tend to be very smart, empathetic and intellectually curious as opposed to dogmatic and contentious that can be found in the software engineering industry at large today.

• Nix, a one-tool-to-rule them all for dev, build, and deploy. While not easy, deterministic builds are the future and help one to sleep at night (I’ve found). It can be used solely for personal dev, or for an entire organization, and anything in between.

• Virtual DOM. If your Haskell web framework does not handle the tedious task of DOM manipulation for you, you have been failed as a library consumer IMO. Miso has a very well-tested, simple recursive micro virtual DOM diffing library that can exist standalone and can detect regressions in performance via a benchmark suite.

• Simplicity. Unlike many other ivory tower libraries in Haskell, Miso maintains a simple interface. Many different common abstractions were explored in the early stages of development (free monads, FRP, etc.) and found lacking, unnecessary or replaceable by a simpler solution without sacrificing features. Miso does not attempt to hide behind complex type-level abstractions and blame end-users for their lack of understanding. As opposed to a top-down approach that shoe-horns an abstraction into an environment where it does not belong, Miso takes a bottom-up approach to fully understand its environment, the browser, it’s APIs, the DOM and its short-comings and provide a simple commonly-used abstraction to the end-user that can scale to large applications. This also makes it easier for newcomers to Haskell to get up and running quickly.

• Industry adoption. Several companies are using miso in production for various things in their company, from full product to internal tools / data visualization.

• Isomorphic. Due to the rose tree structure of both the DOM and HTML, pre-rendering increases load-time and overall UX along with correct SEO.

"""

^ from the author of Miso

Post reply on HN