[HN Gopher] Learning Elm by porting a medium-sized web frontend ...
___________________________________________________________________
Learning Elm by porting a medium-sized web frontend from React
(2019)
Author : Tomte
Score : 90 points
Date : 2024-02-28 10:55 UTC (1 days ago)
(HTM) web link (benhoyt.com)
(TXT) w3m dump (benhoyt.com)
| jrvarela56 wrote:
| I tried Elm in ~2018 and it was delightful. Ended up checking it
| out bc it was mentioned as 'prior art' in Redux's website. Didn't
| end up adopting bc everyone around me thought I was crazy to use
| something so niche.
|
| It's the kind of thing that even if you don't end up using, you
| come out with lessons that make you a better programmer. Some
| that I remember:
|
| - The compiler was fast, it made me aware that you could have an
| iterative workflow like most dynamic languages but driven by
| types
|
| - The language/framework constructs (views, updates, etc) made it
| clear what kind of functionality had to live where so it makes me
| aware to define roles/arch in React apps that are 'just
| components'
|
| - Error messages are just awesome, it was the clearest I had seen
| at that point and made me realize other languages just haven't
| paid enough attention to make them more usable
| ilikeorangutans wrote:
| Agree on all points. It's delightful to compile your app and...
| it just works. No nulls.
|
| I still use it for personal projects where 8 can but Elm is
| showing its age. Newer JavaScript APIs are not well supported
| and ports, while I understand why they exist, can be painful to
| use.
|
| But I'd still recommend it. Way more fun than any other fronted
| framework library I've used and the functional nature was a fun
| challenge for me.
| hombre_fatal wrote:
| I still use Elm for personal projects as well. It's nice to
| come back to an old project and become immediately productive
| not just because of the type system but because all Elm apps
| work the same.
|
| Coming back to an old React app is usually a pain because
| everything changes between projects, even the state
| management architecture.
| _raul wrote:
| Exactly the same delightful experience here. Sadly it's only
| become an even harder sell since then.
| cyberpunk wrote:
| Every single place I've worked that adopted it has like one
| or two elm repos left where no one has had the time to
| rewrite it into ts yet, and there's maybe one developer who
| still understands it.
|
| I've not seen anyone picking it for new dev in... a really
| long time.
|
| Shame, really.
| boxed wrote:
| I use it at work. I tried to write Vue once and just hated
| it with a passion, so rewrote that part in Elm and was much
| happier.
| busfahrer wrote:
| > It's the kind of thing that even if you don't end up using,
| you come out with lessons that make you a better programmer.
|
| Sort of a modern front-end developer's version of reading SICP
| even if you're not going to end up coding in Lisp, but because
| it makes you a better programmer, as you say. Interesting take!
| naltroc wrote:
| elm is a lovely lang. it would be nice to have modern APIs on it.
|
| here's the project for new eyes:
|
| https://github.com/elm/core
|
| https://elm-lang.org/
| datadeft wrote:
| The website tells the full story:
|
| https://elm-lang.org/ (c) 2012-2021 Evan Czaplicki
| roebk wrote:
| What story does that tell?
|
| React's would say 2022 -
| https://github.com/facebook/react/releases
|
| There's engineering effort happening behind the scenes on both
| projects, the releases have slowed, and big changes are coming
| to both Elm and React.
| zanellato19 wrote:
| Elm seems pretty much dead to me, tbh, which has prevented me
| from even trying it for the last few years and I know I'm not
| the only one.
| throwaway2847 wrote:
| There was a major loss of confidence and enthusiasm due to
| things like this. Very much not a project to build a
| business on
|
| https://dev.to/kspeakman/elm-019-broke-us--khn
| boxed wrote:
| Honestly it's better now that it's dead. The 0.18->0.19
| transition was a big disaster. Imagine if we got one of
| those ever year for the last five years! I think that's
| what would have happened if Evan had continued to be able
| to produce new versions.
|
| Dead means it's super stable. Stable is good.
| pyrale wrote:
| I believe the important part is not the date so much as the
| copyright.
|
| Basically, if you build on Elm, you're living inside Evan's
| personal project.
|
| There are upsides (Evan did a great job designing the
| language) and downsides (Evan's goal isn't being a
| maintainer, and he locked the ecosystem in such a way that
| many things can't be done without him).
| datadeft wrote:
| He stopped caring in 2021
| jcuenod wrote:
| And for those who are interested, Evan (creator of Elm) gave a
| great Strange Loop '23 talk that hints at where he imagines
| things going, if he could figure out how to get the economics to
| work.
|
| https://www.youtube.com/watch?v=XZ3w_jec1v8
| ddellacosta wrote:
| I wouldn't bother with Elm. Among other things:
| https://www.reddit.com/r/programming/comments/fxvlow/why_im_...
|
| PureScript (https://www.purescript.org) on the other hand is very
| nice.
| wryoak wrote:
| PureScript made some ergonomically painful decisions (I value
| the logic behind their implementation of tuples but not having
| to use them in such a way), but I think the biggest point
| against it is how Haskell is moving into that space via JS and
| WASM compiler targets and bringing along its broader user base
| and library support
| ddellacosta wrote:
| Yeah the way tuples work in PS is kinda painful, but there
| are some affordances for tuple-like pattern matching that
| smooth over some of that pain.
|
| On the other hand, I feel like PureScript's records that
| utilize row polymorphism are such a game changer that it's
| hard for me not to get frustrated with Haskell records when I
| go back. And while I love where Haskell is going with WASM
| and JS support, I think it'll be a little while before that
| is viable for real-world projects.
| whosthatguy wrote:
| > Haskell is moving into that space via JS and WASM compiler
| targets and bringing along its broader user base and library
| support
|
| This has been an initiative for longer than PureScript has
| existed. I wouldn't expect it to replace PureScript any time
| soon to be honest.
| josephcsible wrote:
| For anyone new to Elm, remember that as of version 0.19, unless
| your project is one of the Elm core team's pet projects, you'll
| have a severely restricted feature set available. See
| https://news.ycombinator.com/item?id=22821447,
| https://news.ycombinator.com/item?id=17842400, and
| https://news.ycombinator.com/item?id=16510267 for details.
| hombre_fatal wrote:
| Jeez, at some point you folks who don't like Elm's decisions
| have to leave the theater so the rest of us can enjoy the show.
|
| If you think a cult of personality is bad, you aren't
| appreciating how much worse is, to the rest of us, the cult of
| anti-cheerleaders on every post that mentions Elm.
|
| For years now any time someone wants to read about Elm, they
| have to hear from the same few HNers who don't even use it yet
| refuse to let it go.
|
| It's like every time Dune plays in the movie theater, the same
| crowd comes in to explain how shit it is, how different it is
| from the book, in fact check out this ancient blog post about
| how bad it is, and there's no way yall in the audience will
| enjoy it so don't even try! The director sucks too, just look
| what he did! He fkin did that! It's actually impossible to
| enjoy the movie once you know all the facts. And the guy who
| made the movie didn't listen to my meticulous feedback and it
| hurt me cuz boy do I have opinions about how a Dune movie
| should be made, believe you me.
|
| Meanwhile we just want to watch the dang movie.
| matsemann wrote:
| I'm quite curious what Elm triggers so in people, that they
| years later actively hunts down discussions about it to
| interject their negativity.
| esmevane wrote:
| I think maybe you ought to think about inverting your
| stance on this, because it's not necessarily virtuous to
| imagine that everyone repeating the same warning, over and
| over again, is due to some mysterious, inexplicable
| negativity. And it's not great to imagine that they don't
| know what they're talking about, or that they're just
| trying to scare people off with senseless FUD. Or that they
| didn't actually run into the problems they say they did. Or
| that they don't know the root cause.
|
| Maybe a better question to be curious about is this: What
| can Elm do about the (self-evident in these comments, IMO)
| fact that a bunch of devs who really like it, feel like
| it's a bad choice? And, what SHOULD Elm do about that?
|
| If a bunch of people think it's a tool foreboding enough to
| warn others off of it, and in the same thread some of those
| same people are saying they really liked that tool and wish
| they didn't have to do that, what benefit are you really
| getting from just dismissing their feedback?
|
| Outspoken feedback is rare, just calling it negativity and
| paying it no mind rhymes a lot with the way Elm, writ
| large, has behaved. It's not indicative of a tool or
| ecosystem that wants to foster growth or continue
| development. That's part of the problem.
| matsemann wrote:
| I disagree. I don't care what elm maintainers should or
| shouldn't do. It's not my problem, so that's not a
| question I want to ask.
|
| I'm curious about why the same few, a vocal minority,
| spams every thread about elm with the same blog post. If
| you think we're dismissive, it's more because we don't
| want the discussion to be derailed for the umpteenth
| time.
| bigDinosaur wrote:
| People who make commercial decisions based on the support
| and development a language receives do indeed care. If
| you are making decisions with commercial or practical
| relevance you should care and not caring is negligence if
| you decide to use the product. Many people got burnt by
| the abandonment of Elm development (and yes, it has
| essentially been abandoned despite what the Elm community
| will say).
| SantalBlush wrote:
| I think it's a bit disingenuous to pretend the goal of
| many of these critics is to _improve_ Elm. They are
| clearly through with the language--as shown in their
| comments--and that is fine. But they 're acting like they
| got dumped five years ago and still aren't over it.
| esmevane wrote:
| Why would they not be over it, then? It's clearly made an
| impression.
| ddellacosta wrote:
| This and the responses that are piling on with the same
| sentiment are offbase.
|
| I am not seeking out opportunities to badmouth Elm. But as I
| am someone who is interested in FP and frontend tech in
| general, when I see an Elm story on the frontpage I click on
| it to see what folks are saying. And when I see exclusively
| glowing and positive statements (which was the case when I
| first posted) then I feel like I have an obligation to point
| out that there are some big issues with how Elm is
| maintained, because this is the sort of thing that _I_ would
| want to know before I spent a bunch of time digging into it.
|
| If you want to watch the dang movie go ahead. But anyone
| asserting that those of us posting negative things about Elm
| are acting cult-like (seriously?) is being disingenuous.
| Considering the audience, there are good reasons to highlight
| the--IMHO major--problems with how the Elm project is run,
| and not mentioning them is irresponsible.
| ISV_Damocles wrote:
| The year in this link is very important. In the following year,
| the Elm team decided to not pay attention to the maxim "perfect
| is the enemy of good" and crippled their FFI story, making it
| impossible to actually use the language in production[1].
|
| I would recommend to steer clear of a language that makes these
| sorts of decisions -- that certain features are off-limits to the
| regular developer because they can't be trusted to use them
| correctly -- because if you find yourself in a situation where
| you _need_ that to solve your problem, you 're trapped. I
| included Go in the set of languages I would recommend steering
| clear of for years, due to their decision to allow their own
| `map` type be a generic[2] type but no user-defined types could
| be[3], leading to ridiculously over-verbose codebases, but they
| have finally corrected course there.
|
| If you're looking for something kinda like Elm but not likely to
| break your own work in the future, I'd recommend checking out
| ReasonML[4] instead.
|
| [1]: https://lukeplant.me.uk/blog/posts/why-im-leaving-elm/ [2]:
| https://go.dev/blog/maps [3]:
| https://go.dev/doc/faq#beginning_generics [4]:
| https://reasonml.github.io/
| ambrozk wrote:
| It's incredible that on just about _every_ piece I 've ever
| read about Elm since they made that decision, this has been the
| first, second, and third comment. Wanting to try Elm for
| myself, I disregarded this advice, and.... immediately ran into
| the exact same problem! I've never seen such a promising
| project so conclusively killed by pure developer pigheadedness.
| And, amazingly, they've never backed down at all. They don't
| seem to mind that they maimed themselves.
| pavlov wrote:
| A purity pledge is very typical of cults. It's both a filter
| and an enforcement mechanism.
|
| This may not apply to Elm. But I imagine it can feel easier
| and more rewarding to manage a community that's more like a
| cult than a typical free-for-all open source project.
| truculent wrote:
| I think it's probably harder and less rewarding to manage a
| community where you're constantly taking flak for a
| technical decision people don't like (and which those
| people generally don't engage with the pros and cons of
| said decision!)
| savanaly wrote:
| Out of curiosity, what did you try to do that you hit that
| issue right away? I've been writing Elm apps as side projects
| for years, and never even come close to the kernel thing
| being a problem. My apps are mostly graphically undemanding
| games and helper tools. What are the types of applications
| where this becomes an issue right away?
| matsemann wrote:
| Most likely they didn't understand Ports and immediately
| wanted to reach for kernel stuff.
| lolc wrote:
| In my case, it was a regex supplied by the user. Elm 0.18
| had no support for constructing a regex at run-time. So I
| made a package that wraps native RegExp. When 0.19 was
| released, I couldn't upgrade because of those 5 lines. The
| regex package eventually got regex.fromstring(). So I
| could've upgraded. But at the time I was bumping against
| limits accessing Intl and I really hated the prospect of
| begging some maintainer for access to a browser api.
|
| Elm was the most fun I ever had developing a browser app.
| Then they decided I shouldn't be allowed to develop a
| ShootMyFoot module, and it stopped being fun overnight.
| savanaly wrote:
| Yeah, I really feel this a good way to divide developers
| into two types. There are those like me, to whom the
| philosophy of discourage foot guns systematically sounds
| kind of brilliant. To put it in flattering terms, it's
| pay a short term cost for the long term and hard-to-
| perceive but very real benefits (making certain
| categories of errors completely extinct). To put the
| other side in flattering terms: they're not letting the
| perfect be the enemy of the good, and never compromising
| on their vision because the tech is holding them back. I
| think the latter is definitely dominant in the
| discipline. I'm glad that at least Elm carries the torch
| for the former though.
| ordinaryradical wrote:
| Reason is a lovely, OCaml-esque language in the same functional
| vein, but I would say Gren feels like a great spiritual
| successor to Elm.
|
| https://gren-lang.org/
| josephcsible wrote:
| Gren is a fork, not a spiritual successor. And not only did
| it not fix that problem, it made it worse:
| https://news.ycombinator.com/item?id=36275171
| matsemann wrote:
| Perhaps because it's not the big problem a few people make
| it out to be..
| ordinaryradical wrote:
| Yeah, I just read this further down in this topic. Really
| bummed about it, Elm always seemed so promising, and I
| thought a healthy fork was what was needed.
|
| I just don't understand the reasoning for this choice.
| terminatornet wrote:
| along those lines, Zokka is a fork of elm that appears to be
| mostly dedicated towards bug fixes that Evan (the creator of
| elm) refuses to acknowledge or merge.
|
| https://github.com/Zokka-Dev/zokka-compiler
|
| edit: there's also Roc, https://www.roc-lang.org/, a language
| started by Richard Feldman who I believe was a former elm
| core team member. I think Roc aims to accomplish different
| things than elm, but definitely feels like a spiritual
| successor
| josephcsible wrote:
| The commitment to bidirectional compatibility means that
| Zokka can't fix the problem that GGP was talking about.
| matsemann wrote:
| > _making it impossible to actually use the language in
| production_
|
| Just FUD. I've been on a big team writing a webapp used by
| hundreds of thousands each day. While it's not necessarily my
| own first choice, it was great and the least error prone piece
| of software I've written in my career.
| ISV_Damocles wrote:
| It is impossible if you're being responsible. You don't
| choose a technology that could potentially block you from
| solving problems in the future unless it brings a huge value
| to you.
|
| Elm's value proposition is _mostly_ being a functional
| language with an opinionated MVU library baked in, so you can
| reproduce that value with a better functional language and
| selecting a similar MVU library in that other language, which
| means it should never actually cross the value bar above the
| risk it brings if you need a browser feature it doesn 't
| support and actively prevents you from accessing.
| matsemann wrote:
| Now you're moving the goalpost. You said it was impossible
| to use in production. Which is clearly wrong.
| ISV_Damocles wrote:
| I am just clarifying why I consider it impossible.
|
| Production is not some place you're supposed to cowboy
| code, but instead have a reasonable expectation that you
| will be able to continue supporting it for as many years
| as it operates, and it's impossible for anyone to
| _responsibly_ use technology with _known_ limitations
| that have bitten other real engineering teams that they
| can find zero workarounds for.
|
| If you don't consider that an impossibility for a
| production environment, then I certainly wouldn't want to
| work with you on a team with production responsibilities.
| matsemann wrote:
| Ah, ad hominem. By not agreeing with you, you're
| basically saying I suck as a dev. Classy.
|
| If that's the level of discussion you want, I'll pass.
| And perhaps you should reflect on if you yourself is a
| great team member, if this is how you conduct technical
| discussions with your colleagues..
| ISV_Damocles wrote:
| You keep throwing out debate terminology as if that's
| helping your argument.
|
| You'll note that I didn't get immediately riled up on you
| calling my original post "FUD" instead of asking why I
| said what I said. And then when I tried to clarify to you
| how I consider usage of Elm in production impossible, you
| again attack me directly instead of trying to discuss
| anything.
|
| So, perhaps you should reflect if you're a great team
| member if you consider your opening statement to me to be
| a "technical discussion" at all? I was just trying to
| respond reasonably for third parties who are reading
| this, because I consider you a troll.
| baobabKoodaa wrote:
| I've also had the pleasure of maintaining an Elm codebase. It
| was filled to the brim with state update bugs. You could
| never trust what you saw in your browser. Nobody in the team
| understood how the codebase worked. I spent days implementing
| some extremely simple changes, which barely worked (to the
| same standard as the rest of the codebase). Never again.
| matsemann wrote:
| I don't blame a Rust-codebase for being bad just because I
| don't know Rust.
| baobabKoodaa wrote:
| So, your positive anecdote was somehow valuable for the
| discussion, but my negative anecdote had absolutely no
| value? That's how anecdotes work?
| troupo wrote:
| ReasonML crippled themselves, too, by splitting the already
| tiny community between Reason and ReScript
|
| Here's a good (neutral!) write-up: https://ersin-
| akinci.medium.com/confused-about-rescript-resc...
| klabb3 wrote:
| > I would recommend steering clear of [Go] for years, due to
| their decision to allow their own `map` type be a generic[2]
| type but no user-defined types could be[3]
|
| I think this is very, very different. First because Go didn't
| have a cultish purist aversion to generics, banning people,
| going after them even outside of community spaces. But on a
| technical side, maps (and slices and channels) were not gated
| to be used by std, they were publically available to anyone.
| Not having generalized a feature is not the same as banning it.
| There was not even Go syntax to express it. Same as arrays in
| C, no?
|
| That said, I'm not challenging the recommendation to stay away
| or not - generics was (and still is, may I add!) quite a pain
| point with the language. I'm personally quite invested for
| other reasons (concurrency, networking, std lib), but people
| come to different conclusions naturally.
| huy-nguyen wrote:
| If you're a front-end developer, you should checkout
| ReScript[1], supposedly a JS-oriented successor of ReasonML and
| developed by the ReasonML team.
|
| [1] https://rescript-lang.org/
| kriiuuu wrote:
| If you want to try TEA, but not Elm I reccomend Scala.js with
| Tyrian[1]. Scala.js is a wonderful, mature project and Tyrian
| gives you the elm architecture in a very pragmatic way.
|
| [1]: https://tyrian.indigoengine.io/
| lf-non wrote:
| Are you actually using this in a non-trivial application?
|
| The recurring complain I hear about scala are the bad compile
| times. I haven't used the language much, so not sure if this
| only applies to libraries that heavily use compile time
| metaprogramming.
|
| But I really love that with modern tooling we can get a sub-
| second editor->browser feedback loop even for a three year
| old medium-large project on modern hardware. This was
| primarily one of the reasons I avoided Kotlin+Gradle JS
| target because among other issues the feedback loop was 2-3x
| slower.
| kriiuuu wrote:
| I have a medium sized project with it and the initial
| compile can be slow, however every recompile usually has
| the page updated as I switch from my editor to it. Not as
| fast as TS, but worth it for the much better programming
| language. Tyrian also makes it trivial to set up hot-reload
| with preserved state.
| hombre_fatal wrote:
| I have to agree that this is FUD. So, it's impossible to use
| the language in production because FFI is async (ports)? lol,
| come on guys.
| z5h wrote:
| "making it impossible to actually use the language in
| production"
|
| Absolutely false.
| ISV_Damocles wrote:
| Please refer to my comment here:
| https://news.ycombinator.com/item?id=39551017
| marc136 wrote:
| If time is important to you, please correct your statement.
|
| > The year in this link is very important. In the following
| year, the Elm team decided to [...]
|
| The blog post was released a year _after_ the official release
| of Elm 0.19 where the access to native code was further
| restricted in the official compiler.
|
| It was not something that happened without ample prior notice,
| see for instance a post [1] by the Elm language creator in
| March 2018 in which he explains his reasoning for the upcoming
| change. Or another in March 2017 where he announced that
| intended change [2]. Even in 2015 he actively discouraged
| people to rely on these undocumented features and other hacks
| [3].
|
| I also was not happy with that choice and felt the pain of
| something being taken away that was possible before, but that
| didn't stop me from using Elm at work nor from using it for
| fun.
|
| So far I haven't found an alternative that I liked better, so I
| will stick to it.
|
| [1]: https://discourse.elm-lang.org/t/native-code-in-0-19/826
| [2]: https://groups.google.com/g/elm-
| dev/c/bAHD_8PbgKE/m/X-z67wTd... [3]:
| https://groups.google.com/g/elm-dev/c/1JW6wknkDIo/m/H9ZnS71B...
| boxed wrote:
| I use Elm and am quite happy with it, despite the project being
| dead (and Evans horrible cult of personality).
|
| I am also keeping on eye on Gren as a replacement: https://gren-
| lang.org/
| josephcsible wrote:
| Gren took the worst thing about Elm and made it even worse:
| https://news.ycombinator.com/item?id=36275171
| ordinaryradical wrote:
| Oof, why do this? What is the reasoning?
| boxed wrote:
| https://news.ycombinator.com/item?id=36278320
|
| Gren is very open to contributions. This can radically
| change how this enforcement impacts users in practice. It's
| too early to say really.
| devX3 wrote:
| Haven't heard from this language since 2016 where a coworker
| tried this out but then gave up on it.
___________________________________________________________________
(page generated 2024-02-29 23:02 UTC)