27 ms·

Elm for the Front End, Right Now

101 points by listrophy 10y ago

kinkdr 10y 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.
- listrophy 10y 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 10y 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 10y 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"?
      - kinkdr 10y ago
        > early stage language I keep hearing this excuse, and to be honest I don't like it. On one hand we want to expand the usage of Elm, and have Elm be taken seriously, on the other hand when we feel like we use the "early stage" language excuse. > I'd say reducing weird syntax is a perfectly good reason I disagree with you on this, prohibiting the users from using the prime character has nothing to do with the language's syntax.
        thatswrong0 10y ago
        > On one hand we want to expand the usage of Elm, and have Elm be taken seriously, on the other hand when we feel like we use the "early stage" language excuse. If I didn't know what changes we're referring to, it would sound like there was some critical change to the core functionality of the language. Instead, they're removing one weird bit of syntax. It's not an excuse that it's an early stage language - it's acknowledging reality. And an upside to that reality is that making these types of changes won't upset nearly as many people as it would if it were a more mature language. > I disagree with you on this, for me it is very worrying. You're not explaining why. Here (https://github.com/elm-lang/elm-plans/issues/4 https://github.com/elm-lang/elm-plans/issues/4) are three good arguments for removing it: 1. It confuses newbies. 2. It's an easy character to miss. 3. It's easy to migrate away from it. What are your arguments for keeping it besides the fact it's already there?
        kinkdr 10y ago
        > it would sound like there was some critical change to the core functionality of the language No, I acknowledged early on, and many times, that it is a very minor thing. My only concern is that it is worrying for the future. (Using the word huge in the "huge red flag" was an exaggeration. I shouldn't have done so). > 1. It confuses newbies. Remove it from core language then. Having the prime character in my code, doesn't confuse anyone but me. Is a language that allows Unicode characters for variable names confusing for newbies? > 2. It's an easy character to miss. Again, it is in my code. > 3. It's easy to migrate away from it. That's not an argument for removing something. Again, my point is that is has to do with personal taste, yet Evan decided to force it to anybody who uses the language. He could have very easily enforce it to core packages, and nobody would complain. But forcing it on my code, is worrying.
        matt4077 10y ago
        > Remove it from core language then. Having the prime character in my code, doesn't confuse anyone but me. Until you take your personal style to Github, or coworkers... Evan is doing a pretty good job at managing Elm – in fact I don't know any other language except maybe Swift where the rollout is planned to such a depth.
      - conistonwater 10y ago
        A prime as an identifier constituent is not "weird syntax". The ancient C tradition of only allowing [_[:alnum:]] characters in identifiers is pretty pointless anyway. I really wish more languages would allow question marks and exclamation marks (and everything else), the way Lisp and Scheme do (e.g., https://docs.racket-lang.org/guide/syntax-overview.html#%28part._.Identifiers%29 https://docs.racket-lang.org/guide/syntax-overview.html#%28p...) There's a very good example in C++ of how this causes problems, where vector::clear and vector::empty are much too easy to confuse (which one of them deletes all elements, and which one of them checks if a vector is empty?). Replacing them with clear! and empty? (or is it clear? and empty!) would be a huge improvement. Whenever a language moves away from arbitrary legacy restrictions, that's a good thing.
        kbp 10y ago
        The problem is that prime (as it's used, anyway) doesn't carry any meaning the way ? and ! (as they are used) do in Scheme, it's just used for "I couldn't bother to think of another name". Enabling clearer names is great, but the language allowing primes in names was accomplishing the opposite of that.
        masklinn 10y ago
        In Haskell it's sometimes (often?) used for strict versions of functions e.g. foldl and foldl'.
        conistonwater 10y ago
        I think that's a coding style decision, and shouldn't be part of language specification. I certainly don't feel about primes the way you do: having a function f and a function f' usually means they are sort of similar with some specific difference between them, definitely not "couldn't think of a better name". E.g., in haskell a prime often denotes a strict function, it's a better convention than having f and f_strict. Plus, how are you going to decide which unicode symbols should not be allowed? It can get a little random.
        10y ago
    - eastWestMath 10y ago
      It's not at 1.0, there's no promise about preserving backwards compatibility at this point.
      - kinkdr 10y ago
        See my reply to the other thread. 1. If it is not ready for prime time, maybe we should stop promoting it? 2. React was 0.14 up to a year or so ago. The number doesn't mean anything.
        eastWestMath 10y ago
        People are excited by it, and managed to deal with prime-ageddon without any major headaches (it's like basic regex search and there's even an update tool, come on).
        matt4077 10y ago
        > prime time Apparently, prime time came and went :) > If it is not ready for prime time, maybe we should stop promoting it? It's about as ready as the impression it makes: yes, you can use it for project. But you may need half an hour every few months to update.
        kinkdr 10y ago
        > Apparently, prime time came and went :) :D. Pun was not intended!
    - dismantlethesun 10y 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.
- vimota 10y ago
  Just a reminder that 'elm-upgrade' [0] should handle this automatically. [0] https://github.com/avh4/elm-upgrade#elm-upgrade https://github.com/avh4/elm-upgrade#elm-upgrade
- Latty 10y 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.
ggregoire 10y ago
From what languages is Elm inspired? I've a Java/C#/PHP/JS background and I feel really uncomfortable with Elm syntax.
- botexpert 10y ago
  Haskell, ML langs.
- kinkdr 10y ago
  Haskell
- jmcdiesel 10y 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 10y ago
    Have you spent much time with it? Like all things, you need to learn before you understand, and then it becomes clear.
    - Latty 10y 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 10y 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?
leeoniya 10y ago
in case anyone's wondering, it performs about the same as 0.17: https://rawgit.com/krausest/js-framework-benchmark/master/webdriver-ts/table.html https://rawgit.com/krausest/js-framework-benchmark/master/we...
- leshow 10y ago
  interesting that Elm's own benchmarks has it handily beating the frameworks it performs worse than in these.
  - maxthegeek1 10y ago
    It looks like the elm implementation isn't using "lazy" https://github.com/krausest/js-framework-benchmark/blob/master/elm-v0.18.0/src/Main.elm https://github.com/krausest/js-framework-benchmark/blob/mast... http://package.elm-lang.org/packages/elm-lang/html/2.0.0/Html-Lazy http://package.elm-lang.org/packages/elm-lang/html/2.0.0/Htm...
botexpert 10y 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 10y 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.
  - sgslo 10y 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?
  - davidbanham 10y 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.
- q3r3qr3q 10y ago
  Typescript has types, but it's the same terrible language underneath.
rdtsc 10y 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 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.
kcarnold 10y 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 10y 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 10y 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 10y 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.
nmdanny 10y 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.
mullsork 10y 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 10y 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.

101 points by listrophy 10y 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.

listrophy 10y 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 10y 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 10y 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"?
    - kinkdr 10y ago
      > early stage language I keep hearing this excuse, and to be honest I don't like it. On one hand we want to expand the usage of Elm, and have Elm be taken seriously, on the other hand when we feel like we use the "early stage" language excuse. > I'd say reducing weird syntax is a perfectly good reason I disagree with you on this, prohibiting the users from using the prime character has nothing to do with the language's syntax.
      - thatswrong0 10y ago
        > On one hand we want to expand the usage of Elm, and have Elm be taken seriously, on the other hand when we feel like we use the "early stage" language excuse. If I didn't know what changes we're referring to, it would sound like there was some critical change to the core functionality of the language. Instead, they're removing one weird bit of syntax. It's not an excuse that it's an early stage language - it's acknowledging reality. And an upside to that reality is that making these types of changes won't upset nearly as many people as it would if it were a more mature language. > I disagree with you on this, for me it is very worrying. You're not explaining why. Here (https://github.com/elm-lang/elm-plans/issues/4 https://github.com/elm-lang/elm-plans/issues/4) are three good arguments for removing it: 1. It confuses newbies. 2. It's an easy character to miss. 3. It's easy to migrate away from it. What are your arguments for keeping it besides the fact it's already there?
        kinkdr 10y ago
        > it would sound like there was some critical change to the core functionality of the language No, I acknowledged early on, and many times, that it is a very minor thing. My only concern is that it is worrying for the future. (Using the word huge in the "huge red flag" was an exaggeration. I shouldn't have done so). > 1. It confuses newbies. Remove it from core language then. Having the prime character in my code, doesn't confuse anyone but me. Is a language that allows Unicode characters for variable names confusing for newbies? > 2. It's an easy character to miss. Again, it is in my code. > 3. It's easy to migrate away from it. That's not an argument for removing something. Again, my point is that is has to do with personal taste, yet Evan decided to force it to anybody who uses the language. He could have very easily enforce it to core packages, and nobody would complain. But forcing it on my code, is worrying.
        matt4077 10y ago
        > Remove it from core language then. Having the prime character in my code, doesn't confuse anyone but me. Until you take your personal style to Github, or coworkers... Evan is doing a pretty good job at managing Elm – in fact I don't know any other language except maybe Swift where the rollout is planned to such a depth.
    - conistonwater 10y ago
      A prime as an identifier constituent is not "weird syntax". The ancient C tradition of only allowing [_[:alnum:]] characters in identifiers is pretty pointless anyway. I really wish more languages would allow question marks and exclamation marks (and everything else), the way Lisp and Scheme do (e.g., https://docs.racket-lang.org/guide/syntax-overview.html#%28part._.Identifiers%29 https://docs.racket-lang.org/guide/syntax-overview.html#%28p...) There's a very good example in C++ of how this causes problems, where vector::clear and vector::empty are much too easy to confuse (which one of them deletes all elements, and which one of them checks if a vector is empty?). Replacing them with clear! and empty? (or is it clear? and empty!) would be a huge improvement. Whenever a language moves away from arbitrary legacy restrictions, that's a good thing.
      - kbp 10y ago
        The problem is that prime (as it's used, anyway) doesn't carry any meaning the way ? and ! (as they are used) do in Scheme, it's just used for "I couldn't bother to think of another name". Enabling clearer names is great, but the language allowing primes in names was accomplishing the opposite of that.
        masklinn 10y ago
        In Haskell it's sometimes (often?) used for strict versions of functions e.g. foldl and foldl'.
        conistonwater 10y ago
        I think that's a coding style decision, and shouldn't be part of language specification. I certainly don't feel about primes the way you do: having a function f and a function f' usually means they are sort of similar with some specific difference between them, definitely not "couldn't think of a better name". E.g., in haskell a prime often denotes a strict function, it's a better convention than having f and f_strict. Plus, how are you going to decide which unicode symbols should not be allowed? It can get a little random.
        10y ago
  - eastWestMath 10y ago
    It's not at 1.0, there's no promise about preserving backwards compatibility at this point.
    - kinkdr 10y ago
      See my reply to the other thread. 1. If it is not ready for prime time, maybe we should stop promoting it? 2. React was 0.14 up to a year or so ago. The number doesn't mean anything.
      - eastWestMath 10y ago
        People are excited by it, and managed to deal with prime-ageddon without any major headaches (it's like basic regex search and there's even an update tool, come on).
      - matt4077 10y ago
        > prime time Apparently, prime time came and went :) > If it is not ready for prime time, maybe we should stop promoting it? It's about as ready as the impression it makes: yes, you can use it for project. But you may need half an hour every few months to update.
        kinkdr 10y ago
        > Apparently, prime time came and went :) :D. Pun was not intended!
  - dismantlethesun 10y 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.
vimota 10y ago
Just a reminder that 'elm-upgrade' [0] should handle this automatically. [0] https://github.com/avh4/elm-upgrade#elm-upgrade https://github.com/avh4/elm-upgrade#elm-upgrade
Latty 10y 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.

ggregoire 10y ago

From what languages is Elm inspired? I've a Java/C#/PHP/JS background and I feel really uncomfortable with Elm syntax.

botexpert 10y ago
Haskell, ML langs.
kinkdr 10y ago
Haskell
jmcdiesel 10y 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 10y ago
  Have you spent much time with it? Like all things, you need to learn before you understand, and then it becomes clear.
  - Latty 10y 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 10y 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?

leeoniya 10y ago

in case anyone's wondering, it performs about the same as 0.17: https://rawgit.com/krausest/js-framework-benchmark/master/webdriver-ts/table.html https://rawgit.com/krausest/js-framework-benchmark/master/we...

leshow 10y ago
interesting that Elm's own benchmarks has it handily beating the frameworks it performs worse than in these.
- maxthegeek1 10y ago
  It looks like the elm implementation isn't using "lazy" https://github.com/krausest/js-framework-benchmark/blob/master/elm-v0.18.0/src/Main.elm https://github.com/krausest/js-framework-benchmark/blob/mast... http://package.elm-lang.org/packages/elm-lang/html/2.0.0/Html-Lazy http://package.elm-lang.org/packages/elm-lang/html/2.0.0/Htm...

botexpert 10y 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 10y 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.
- sgslo 10y 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?
- davidbanham 10y 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.
q3r3qr3q 10y ago
Typescript has types, but it's the same terrible language underneath.

rdtsc 10y 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 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.

kcarnold 10y 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 10y 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 10y 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 10y 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.

nmdanny 10y 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.

mullsork 10y 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 10y 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.