Silkenweb Example: Hackernews Clone

Elm for the Front End, Right Now

101 points by listrophy 8 years ago | 77 comments

kcarnold 8 years ago
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?
- bbcbasic 8 years ago
  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.
  - boubiyeah 8 years ago
    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.
    - bbcbasic 8 years ago
      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.
- fbonetti 8 years ago
  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.
  - boubiyeah 8 years ago
    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.
- boubiyeah 8 years ago
  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?
- jgalt212 8 years ago
  Is the virtual/real DOM chasm difficult to traverse in vue.js?
kinkdr 8 years ago
I wish they would stop making changes just for the shake of change. E.g. Up until 0.17 most code examples where using the prime ' character.
With 0.18, Evan decided that using prime is bad taste, so he decided to break any code that uses it.
Sure, it is not a big change, but it means they are not respecting user's time and it is a sign of things to come.
Sorry for the rant.
Edit: I hope my reply doesn't get misunderstood. I love Elm and use it in all my side projects. I think it made wonders for introducing new people to the ML world.
Edit2: Sorry, didn't meant to make so much fuss about it. It is indeed a small thing.
- vimota 8 years ago
  Just a reminder that 'elm-upgrade' [0] should handle this automatically.
  [0] https://github.com/avh4/elm-upgrade#elm-upgrade
- listrophy 8 years ago
  I agree... I wish we still had the prime character. But since Elm isn't at 1.x status yet, that earns me an "irritated smirk" rather than a table-flip. :)
  - kinkdr 8 years ago
    Yes, I am not saying it is a big thing. It's a small thing in itself, but breaking backwards compatibility for no good reason is huge red flag for the future.
    - thatswrong0 8 years ago
      > breaking backwards compatibility for no good reason
      I'd say reducing weird syntax is a perfectly good reason. How is doing this while offering an easy migration solution in an early stage language a "huge red flag"?
    - dismantlethesun 8 years ago
      Before you reach a 1.0, you should be able to break backward compatibility for any and no reason.
      Most likely the reason is that you want to make something that you yourself are proud of or at least satisfied with.
      Unless you're being paid for the project, satisfying your psychological goals should be the prime point of pre-version 1.0 software.
    - eastWestMath 8 years ago
      It's not at 1.0, there's no promise about preserving backwards compatibility at this point.
- Latty 8 years ago
  I actually think that's a terrible idea. `0.x`v versions are precisely the time to try and get this stuff in, before you end up locked into it forever.
nmdanny 8 years ago
I think that Elm is a fundamentally good language, being catered towards JS developers will hopefully attract more of them to FP development. However, I feel that the language is too restricted compare to other FP languages (Haskell, Purescript, even Scala), as a result you often need to write too much boilerplate and the Elm architecture doesn't seem to fit nicely for all kinds of components.
Which is why for now I'm looking into Purescript and GHCJS which support features such as Rank N types, generics, typeclasses, functional dependencies/type families. Even though I don't use many of those features directly, I do benefit from libraries that depend on them.
rdtsc 8 years ago
Speaking of Elm I liked this video from Erlang Factory about using Phoenix and Elm together. They both have a functional flavors so I think it might appeal to same people:
https://www.youtube.com/watch?v=XJ9ckqCMiKk
The first half is about Phoenix, the second about Elm. I don't know much about front-end stuff but I did like the Elm bit as an intro, especially the debugging and nice error messages part.
ggregoire 8 years ago
From what languages is Elm inspired? I've a Java/C#/PHP/JS background and I feel really uncomfortable with Elm syntax.
- agumonkey 8 years ago
  Completely logical. Java, C, PHP are said to be algol descendants. In two words: curly braces. JS wasn't supposed to but ended up curly because social trends are that strong. Now imagine JS function being the only thing you use, then that language users and designers evolving a syntax for typed js-like functions, rince repeat, you get ML, Haskell, Elm.
  In time your brain realigns, depending on how much you appreciate the functional style or not.
  - striking 8 years ago
    Not quite. ALGOL doesn't have curly braces, just BEGIN and END blocks.
```
  BEGIN
  FILE F (KIND=REMOTE);
  EBCDIC ARRAY E [0:11];
  REPLACE E BY "HELLO WORLD!";
  WHILE TRUE DO
    BEGIN
    WRITE (F, *, E);
    END;
  END.
```
    I've heard it said that the languages you mentioned are inspired by C's syntax.
    - agumonkey 8 years ago
      Wow, couldn't be more wrong. It's indeed C family (BCPL, B). Thanks a lot for the note.
- redtuesday 8 years ago
  Because I really like syntax like Haskell (the type signature is much clearer especially in generic code compared to Java or Scala etc. for example), I'm curious, what is so uncomfortable about the syntax?
  - skybrian 8 years ago
    The lack of parentheses around function calls makes it hard for people not familiar with ML-style languages to tell where the function calls are and what the arguments are to each function call.
    There is a wide variety of syntax among mainstream languages, but basic function calls are pretty much all the same.
    Take a look at Reason [1] for an example of how a functional language (OCaml in this case) can be made more familiar.
    [1] https://facebook.github.io/reason/
    - eastWestMath 8 years ago
      Or maybe people could just become familiar with ML-style languages? The basic syntax shouldn't take more than an hour or two to pick up.
    - ungzd 8 years ago
      Ruby has optional parentheses around function parameters (usually it's recommended to avoid parentheses if possible). Shells have no parentheses around command arguments. These languages are mainstream and no one complains about this.
    - kazinator 8 years ago
      Of course, if we adjust "mainstream" so that it refers to that set of languages which have pass-by-value, strictly evaluated arguments, with no implicit currying, then your point is nearly self-evident. :)
    - redtuesday 8 years ago
      Yes, I agree, that took me also some time to get used to when I dabbled with Haskell and I looked at more complex programs.
- salimmadjd 8 years ago
  when I spoke with Evan (you can usually meet him at the Elm SF meetup) I believe he said Elm was inspired more by OCaml than Haskell. But since many people might have heard of Haskell more than OCaml, Haskell is a better general answer.
  - kinkdr 8 years ago
    The syntax is closer to Haskell than Ocaml.
    Foe example types in Ocaml usually start with lower letter.
    Also Elm has "Maybe", just like Haskell, instead of "option" of Ocaml.
    Also in Elm, like in Haskell you would write "List Sometype", while in Ocaml it is "sometype list".
    - masklinn 8 years ago
      Yeah the syntax is clearly Haskell, the semantics are more ML-ish.
- botexpert 8 years ago
  Haskell, ML langs.
- bbcbasic 8 years ago
  Haskell but is very reminiscent of F# with the >> amd |> operators (which I prefer to . amd $). Although you could name them that in Haskell too.
- jmcdiesel 8 years ago
  Yeah, it seems like a step back in readability... It's not at all intuitive and once I figure out what its doing, I can't find a reason for it.. Lisps are hard to read, but there are at least a few reasons for the syntax (not that i like them) ... This just seems... weird and unusual for no reason...
  - cnp 8 years ago
    Have you spent much time with it? Like all things, you need to learn before you understand, and then it becomes clear.
    - Latty 8 years ago
      I've written a fair amount of Elm, and I still find it awkward. One issue is that I feel like I end up having to go back and add in brackets more than I would with the C-style syntax. I'm not sure if that's just the way I think thanks to being used to that, or an inherent problem.
      The main issue really is that I think it's harder to read, as it's less clear what is being used where. The explicitness of the C-style makes it easier to see what goes where.
    - jmcdiesel 8 years ago
      Thats kinda the point... with the vast array of languages out there, that are performant and powerful and very well established, why should anyone suffer through the learning curve? what value does the language offer to make that worth the effort?
- notduncansmith 8 years ago
  One thing that can help with the discomfort is thinking about it as patterns. The = operator isn't for assignment, it's an assertion of equality. Reading the docs carefully helps immerse you in the syntax as well.
- kinkdr 8 years ago
  Haskell
- q3r3qr3q 8 years ago
  Yikes, you should branch out more.
leeoniya 8 years ago
in case anyone's wondering, it performs about the same as 0.17:
https://rawgit.com/krausest/js-framework-benchmark/master/we...
- leshow 8 years ago
  interesting that Elm's own benchmarks has it handily beating the frameworks it performs worse than in these.
  - maxthegeek1 8 years ago
    It looks like the elm implementation isn't using "lazy"
    https://github.com/krausest/js-framework-benchmark/blob/mast...
    http://package.elm-lang.org/packages/elm-lang/html/2.0.0/Htm...
mullsork 8 years ago
I remember evaluating Elm and ClojueScript as an alternative to ES6 about a year and a half ago. Eventually I had to decide against both as we absolutely needed to render parts of our page server side (Google saying they'll index SPAs is a joke.)
If I'm not mistaken this wasn't possible in Elm back then, and felt uncomfortable or even hard in ClojureScript. Has that changed?
To be fair if I started a new project like the one I'm working at now I'd much rather use server + template for most pages and add interactivity through JS once it boots up.
- susi22 8 years ago
  In clojurescript we have RUM (another lib on top of react) where you can render your HMTL on the server (without using node, just on the JVM). It's also blazing fast and works very well.
botexpert 8 years ago
why not flowtype/typescript+js es6+react+redux/mobx?
currently a pretty nice reactive mobx-state-tree is on the frontpage of hn.
- ggregoire 8 years ago
  I'm quite sure it's exactly for that reason, not having to choose between
  - Flow vs Typescript
  - ES5 vs Babel
  - React vs Angular vs Vue vs jQuery
  - Webpack vs Rollup
  - Redux vs Flux vs Mobx vs React states
  etc...
  Plus, probably lots of dev prefer Elm's syntax and design.
  - davidbanham 8 years ago
    This is exactly the reason I'm interested in Elm. My team has gone from React to React + Flux to React + Redux to React + Redux + Immutable to React + Redux + Flow in the last 2 years. That's a _lot_ of change, and we're not even talking about the build tool side of things with Browserify, Babel, Webpack etc.
    In Elm I can see the same kind of framework simplicity that attracts me to Go.
  - sgslo 8 years ago
    Parent is absolutely correct.
    I can either work on Elm and deal with breaking changes like variable declarations (as noted above), or work on my React/Redux app, where I'm halfway refactoring from ReactRouter v3 -> v4 and Redux Form v4 -> v6, both of which are painful upgrades. Which would you rather deal with?
- q3r3qr3q 8 years ago
  Typescript has types, but it's the same terrible language underneath.