
Elm for the Front End, Right Now - listrophy
http://bendyworks.com/blog/elm-frontend-right-now-updated-for-0-18
======
kcarnold
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
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
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
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.

------
kinkdr
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
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
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
> 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"?

~~~
conistonwater
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#%28p...](https://docs.racket-lang.org/guide/syntax-
overview.html#%28part._.Identifiers%29))

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
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.

~~~
conistonwater
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.

~~~
kbp
It's definitely a matter of taste, but I feel like settling for "similar
except different somehow" is the same thing as "couldn't think of a better
name". I would much prefer f-strict because then I don't need to be familiar
with the punctuation conventions of the codebase to know how it's different
from f, it's right there in English.

Edit: Plus, then you don't have to wonder if that particular function follows
that naming convention; prime meaning strict isn't nearly as universally
followed as ? or ! in Scheme, for instance.

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

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

~~~
agumonkey
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
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
Wow, couldn't be more wrong. It's indeed C family (BCPL, B). Thanks a lot for
the note.

~~~
mikekchar
Well, I wouldn't be so hard on yourself. IIRC (and I hope someone corrects me
if I'm wrong), algol introduced block scoping. Whether you use BEGIN/END or
{/} I think is a pretty minor point.

C has braces to introduce a new scope. The irony is that JS (until recently)
didn't have block scope. It just has braces :-).

Now this is where it gets screwy. You are supposed to (but don't have to
usually) add a semi-colon on the end of each statement in Javascript.

a = 52;

This has a semi colon because it is a statement. There is another construct
called an expression. An expression is anything that can evaluate to a value.
An statement can be an expression (the statement "a = 52;" is an example of
that because it also evaluates to 52 and is thus an expression). But there are
expressions that are not statements. Here is an example of an expression

(5 * 27)

It evaluates to a value, but doesn't do anything so it is not a statement.
Usually in computer languages, if "statements" are actually expressions. So
you can say

if (1>0) {"Yay"} else {"Boo"}

evaluates to a value ("Yay" in this case), but doesn't do anything in and of
itself. The blocks in the braces may contain statements, but the if is an
expression, not a statement. Note the lack of semi-colon. Again, presumably
because it is an expression, not a statement.

You can try the above in Node and it will indeed return the value "Yay".

a = if(1>0) {"Yay"} else {"Nay"};

In this case the variable a should be assigned the value "Yay", because the if
expression evaluates to a "Yay". For some strange reason (that I don't
understand), Javascript (or at least Node, when I tried it) does not accept
that. It gives you a syntax error. You can not use if "statements" as
expressions in Javascript (which sucks quite a bit).

All of this to say that Javascript appears broken to me, no matter what
geneology you assign to it :-D. I personally really like programming in JS (or
actually CS), but it is a beast unto itself, I think.

I'd welcome comments illuminating this issue if I've made a mistake with the
above! As I said, it's easy to do.

~~~
fnovd
>You can not use if "statements" as expressions in Javascript (which sucks
quite a bit).

It does indeed, and it leads to some ugly code:

a = function() { if(1>0) { return "Yay" } else { return "Nay" } }()

~~~
ziad-saab
You can also write:

a = 1 > 0 ? "Yay" : "Nay"

------
leeoniya
in case anyone's wondering, it performs about the same as 0.17:

[https://rawgit.com/krausest/js-framework-
benchmark/master/we...](https://rawgit.com/krausest/js-framework-
benchmark/master/webdriver-ts/table.html)

~~~
leshow
interesting that Elm's own benchmarks has it handily beating the frameworks it
performs worse than in these.

~~~
maxthegeek1
It looks like the elm implementation isn't using "lazy"

[https://github.com/krausest/js-framework-
benchmark/blob/mast...](https://github.com/krausest/js-framework-
benchmark/blob/master/elm-v0.18.0/src/Main.elm)

[http://package.elm-lang.org/packages/elm-
lang/html/2.0.0/Htm...](http://package.elm-lang.org/packages/elm-
lang/html/2.0.0/Html-Lazy)

------
mullsork
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
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
why not flowtype/typescript+js es6+react+redux/mobx?

currently a pretty nice reactive mobx-state-tree is on the frontpage of hn.

~~~
ggregoire
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
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.

