9 ms·

Faithful Elm and the Amazing Router

138 points by amitaibu 10y ago

dzdt 10y ago
For anyone confused like I was, the "Elm" here is a newish in-browser functional language [1], not an old and venerable unix email client [2]. [1] http://elm-lang.org http://elm-lang.org [2] https://en.m.wikipedia.org/wiki/Elm_(email_client) https://en.m.wikipedia.org/wiki/Elm_(email_client)
- drinchev 10y ago
  Wow that's why it sounded so familiar the first time I heard about elm-lang. Thanks!
- dice 10y ago
  With the addition of "amazing router" in the title I was expecting some modern iteration of the 500 mile email [1] story. [1] http://www.ibiblio.org/harris/500milemail.html http://www.ibiblio.org/harris/500milemail.html
agrafix 10y ago
Elm's pretty okay, but beware that every update currently has broken all code written for an older compiler version...
- piotrkubisa 10y ago
  That's true, but after coming from Laravel / PHP stack I don't take it as huge disadvantage as it was in Laravel. First, because each new breaking feature comes with a dozen of articles covering changes and how-to. Secondly, I am person who likes discovering, learning, playing with all these new features, I don't complain to learn something new. And last argument is that each new version comes is way more developer-friendly than previous release.
- k__ 10y ago
  But if Elm really doesn't have any runtime errors, this shouldn't be too much of an issue I guess...
- embwbam 10y ago
  It hasn't been bad updating a codebase to keep up because of the type checker. It usually takes 30 minutes to an hour for a medium-sized project.
- aarpmcgee 10y ago
  The type system also makes the upgrade process a whole lot easier.
deathtrader666 10y ago
So now I think I should be swapping out Ember for Elm from my PEEP stack (PostgreSQL + Elm + Elixir + Phoenix).
not-much-io 10y ago
I've gotten into elm recently coming from Clojurescript and reagent (re-frame to be exact). I didn't think I needed types, until I tried Elm, now I am seriously having an identity crisis.. All my backend Python code is also riddled with type hints to help out with the cognitive load. Elm - Simple, friendly, helpful Just wish Elm was more mature, but loving it anyway!
- supster 10y ago
  It would be really cool to have an Elm type language on the backend. Elm feels like a lighter, friendlier version of Haskell.
  - clarus 10y ago
    You can get a "kind of Elm" experience on the backend with Flow and JavaScript / NodeJs. The type system of Flow is not as strict as Elm, but you have the main parts (including disjoint unions) and can use existing JavaScript code. With React and Redux you also get a similar framework for the frontend.
  - kawera 10y ago
    Elixir seems a good candidate.
    - nilkn 10y ago
      I'm not sure. I do think Elixir is a great language given its goals, but it's very dynamic, whereas Elm is strongly statically typed.
      - kawera 10y ago
        You are right about the type system but still, Elixir is a lighter, friendlier functional programming language compared to haskel or erlang. Not having previous FP experience, I'm having a good time learning Elixir + Elm.
      - rdtsc 10y ago
lolive 10y ago
I wonder about the ecosystem of any advanced language running on a JS engine. Basically, two things may happen in the future: - all the libs existing in JS are recoded by dedicated fanatics in the advanced language. Then you have a versatile all-purpose development ecosystem with this language. or - you rely upon the existing JS ecosystem and libs, and eventually spend your time struggling with the impedance mismatch between JS and your advanced langage. Did you feel something like that with Purescript, Elm, etc?
- somedudethere 10y ago
  I think one of the primary benefits to ELM, etc is the typechecking, which you lose if you use FFI to call outside JS. Once you dont need jquery and you actually have a standard library, 2 of the largest requirements to the existing ecosystem (JQuery and Underscore.js) are no longer needed. Elm looks to handle much of he DOM and events so I doubt you would need React.js or Angular, which just leaves your datastore. (to better put it, much of the packages in Javascript are there because the language itself is insufficient to describe DOM interactions. Elm was created explicitly for the web thus removes the need for many packages)
  - lolive 10y ago
    The other issue is the untyped nature of JSON. Interacting with JSON from Elm does require a lot of Encoder/Decoder. May be JSON/LD could be a nice improvement for that, but it will require a significant effort to be broadly adopted.
- mbrock 10y ago
  I haven't used Elm, but generally I think it shouldn't be that scary to use an "advanced language" if it has an even remotely decent FFI. It might seem like horror to have to interface to external dependencies, but if the libraries you want to access aren't extremely complex then interfacing with them probably isn't going to be such a huge problem. In some cases you might want to use the advanced language for some things but keep the outer layer of the app in JavaScript. At a previous workplace we had a particularly tricky parsing module written in Fay (Haskell subset compiling to JS).

138 points by amitaibu 10y ago

dzdt 10y ago

For anyone confused like I was, the "Elm" here is a newish in-browser functional language [1], not an old and venerable unix email client [2]. [1] http://elm-lang.org http://elm-lang.org [2] https://en.m.wikipedia.org/wiki/Elm_(email_client) https://en.m.wikipedia.org/wiki/Elm_(email_client)

drinchev 10y ago
Wow that's why it sounded so familiar the first time I heard about elm-lang. Thanks!
dice 10y ago
With the addition of "amazing router" in the title I was expecting some modern iteration of the 500 mile email [1] story. [1] http://www.ibiblio.org/harris/500milemail.html http://www.ibiblio.org/harris/500milemail.html

agrafix 10y ago

Elm's pretty okay, but beware that every update currently has broken all code written for an older compiler version...

piotrkubisa 10y ago
That's true, but after coming from Laravel / PHP stack I don't take it as huge disadvantage as it was in Laravel. First, because each new breaking feature comes with a dozen of articles covering changes and how-to. Secondly, I am person who likes discovering, learning, playing with all these new features, I don't complain to learn something new. And last argument is that each new version comes is way more developer-friendly than previous release.
k__ 10y ago
But if Elm really doesn't have any runtime errors, this shouldn't be too much of an issue I guess...
embwbam 10y ago
It hasn't been bad updating a codebase to keep up because of the type checker. It usually takes 30 minutes to an hour for a medium-sized project.
aarpmcgee 10y ago
The type system also makes the upgrade process a whole lot easier.

deathtrader666 10y ago

So now I think I should be swapping out Ember for Elm from my PEEP stack (PostgreSQL + Elm + Elixir + Phoenix).

not-much-io 10y ago

I've gotten into elm recently coming from Clojurescript and reagent (re-frame to be exact). I didn't think I needed types, until I tried Elm, now I am seriously having an identity crisis.. All my backend Python code is also riddled with type hints to help out with the cognitive load. Elm - Simple, friendly, helpful Just wish Elm was more mature, but loving it anyway!

supster 10y ago
It would be really cool to have an Elm type language on the backend. Elm feels like a lighter, friendlier version of Haskell.
- clarus 10y ago
  You can get a "kind of Elm" experience on the backend with Flow and JavaScript / NodeJs. The type system of Flow is not as strict as Elm, but you have the main parts (including disjoint unions) and can use existing JavaScript code. With React and Redux you also get a similar framework for the frontend.
- kawera 10y ago
  Elixir seems a good candidate.
  - nilkn 10y ago
    I'm not sure. I do think Elixir is a great language given its goals, but it's very dynamic, whereas Elm is strongly statically typed.
    - kawera 10y ago
      You are right about the type system but still, Elixir is a lighter, friendlier functional programming language compared to haskel or erlang. Not having previous FP experience, I'm having a good time learning Elixir + Elm.
    - rdtsc 10y ago

lolive 10y ago

I wonder about the ecosystem of any advanced language running on a JS engine. Basically, two things may happen in the future: - all the libs existing in JS are recoded by dedicated fanatics in the advanced language. Then you have a versatile all-purpose development ecosystem with this language. or - you rely upon the existing JS ecosystem and libs, and eventually spend your time struggling with the impedance mismatch between JS and your advanced langage. Did you feel something like that with Purescript, Elm, etc?

somedudethere 10y ago
I think one of the primary benefits to ELM, etc is the typechecking, which you lose if you use FFI to call outside JS. Once you dont need jquery and you actually have a standard library, 2 of the largest requirements to the existing ecosystem (JQuery and Underscore.js) are no longer needed. Elm looks to handle much of he DOM and events so I doubt you would need React.js or Angular, which just leaves your datastore. (to better put it, much of the packages in Javascript are there because the language itself is insufficient to describe DOM interactions. Elm was created explicitly for the web thus removes the need for many packages)
- lolive 10y ago
  The other issue is the untyped nature of JSON. Interacting with JSON from Elm does require a lot of Encoder/Decoder. May be JSON/LD could be a nice improvement for that, but it will require a significant effort to be broadly adopted.
mbrock 10y ago
I haven't used Elm, but generally I think it shouldn't be that scary to use an "advanced language" if it has an even remotely decent FFI. It might seem like horror to have to interface to external dependencies, but if the libraries you want to access aren't extremely complex then interfacing with them probably isn't going to be such a huge problem. In some cases you might want to use the advanced language for some things but keep the outer layer of the app in JavaScript. At a previous workplace we had a particularly tricky parsing module written in Fay (Haskell subset compiling to JS).