Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

New Adventures for Elm

elm-lang.org

Post reply on HN
Print view View original

31–40 of 95 posts

Re: New Adventures for Elm

#31

Post by [deleted] »

Touche wrote: post #27
charlysisto wrote: post #23

Here's the path I've been following : (ruby)rjs -> prototype -> jquery -> backbone -> angular -> react -> flux -> redux -> elm... But I'm just a backend guy happy with Ror, just waiting to go on the frontline... with the proper weapons! My feeling about elm is that it's more than the new kid on the js block. It's closure without parens, it's Haskell without academy, it's Redux without facebook, it's duck-typing witho…

That's a lot of churn. You should stop and ask yourself if it's worth being on the cutting edge all of the time. Are you making better projects as a result of dropping "old" tech the moment something shinier comes around? Everything has tradeoffs. Elm has no server side rendering, for example.

[deleted]

Re: New Adventures for Elm

#32

Post by ghuntley »

dominotw wrote: post #7
Drup wrote: post #5

Earlier quoted context omitted.

ple-ase. Not everyone spends its time buzzing. The amount of people using Elm right now is a drop in the bucket compared to the amount of people using OCaml (and F#, in more recent years). Elm is a fun new language, it has cool features and its take on FRP is interesting, but I would really like its author to stop speaking like he invented fire. I would take js_of_ocaml + FRP over Elm any time, just for the size of t…

F# is commonly used on the frontend?

For C# (and also to a lesser extent F#) check out the ReactiveUI framework which is a FRP framework for Xamarin (iOS and Android), Universal Windows Platform, Windows Phone 8.x, Windows Forms and Windows Presentation Framework.

ReactiveUI is inspired by functional reactive programming and is the father of the ReactiveCocoa (Cocoa/Swift) framework. Rather than using mutable variables which are replaced and modified in-place, ReactiveUI offers "event streams", represented by the IObserver and IObserverable types, that send values over time.

https://github.com/reactiveui/ReactiveUI http://reactiveui.net/

Re: New Adventures for Elm

#33

Post by thinkpad20 »

Drup wrote: post #16
CodyReichert wrote: post #6

Earlier quoted context omitted.

> ... and the overall expressiveness of the language. We're looking at the same Elm, right?

Yes we are. You have to look at what you are competing against. OCaml has a much better module system (and a richer type system altogether). Purescript/Haskell got typeclasses and HKT, among lots of things. As I said, Elm is cute and interesting, but it's type system is less expressive than other languages and lacks features that I consider essential. Sure, it's better than javascript, but why not opt for the other t…

> Elm is cute and interesting, but it's type system is less expressive than other languages and lacks features that I consider essential.

I'd recommend watching this talk: [0]. Evan talks a lot about the decisions that went into the language, such as not having type classes or other advanced features. He makes a strong case for Elm not as a language-to-rule-them-all, but as a tool for the average programmer, who is more interested in building things than in learning about theory. The myriad language features in Haskell, OCaml, etc. are wonderful to those who understand them, but have not proven to be particularly effective at attracting those who aren't already interested in the languages. In that talk, he really made a strong case as to why Elm is valuable and relevant, even for someone such as myself, a functional programming nerd who loves learning about type theory, abstract algebra, and similar things.

Also, I really don't think it's fair to say "The amount of people using Elm right now is a drop in the bucket compared to the amount of people using OCaml (and F#, in more recent years)." OCaml has been around for almost 20 years now, and F# for more than 10. Both have the backing of very large development teams.

[0]: https://www.youtube.com/watch?v=oYk8CKH7OhE

Re: New Adventures for Elm

#34

Post by ghuntley »

For those just getting started in FRP or whom may have not seen the presentations at StangeLoop:

- https://www.youtube.com/watch?v=Agu6jipKfYw - Controlling Time and Space: understanding the many formulations of FRP by Evan Czaplicki (Elm language designer/Prezi)

- https://www.youtube.com/watch?v=1XNATGjqM6U - FRP In Practice: Taking a look at Reactive[UI/Cocoa] by Paul Betts (Slack/GitHub)

- https://www.youtube.com/watch?v=HPyKHxy7X0w&t=18 - ReactiveUI - It's pretty neat by Brendan Forster (GitHub)

Re: New Adventures for Elm

#35

Post by cnp »

charlysisto wrote: post #23

Here's the path I've been following : (ruby)rjs -> prototype -> jquery -> backbone -> angular -> react -> flux -> redux -> elm... But I'm just a backend guy happy with Ror, just waiting to go on the frontline... with the proper weapons! My feeling about elm is that it's more than the new kid on the js block. It's closure without parens, it's Haskell without academy, it's Redux without facebook, it's duck-typing witho…

You can skip all of that and just use https://github.com/gaearon/react-transform-boilerplate as your sole dev environment. You don't need all of that other stuff, especially for prototyping. This is an instant win if your familiar with React (its just JavaScript)

Re: New Adventures for Elm

#36

Post by dominotw »

charlysisto wrote: post #23

Here's the path I've been following : (ruby)rjs -> prototype -> jquery -> backbone -> angular -> react -> flux -> redux -> elm... But I'm just a backend guy happy with Ror, just waiting to go on the frontline... with the proper weapons! My feeling about elm is that it's more than the new kid on the js block. It's closure without parens, it's Haskell without academy, it's Redux without facebook, it's duck-typing witho…

From my limited experience playing with Elm

Pros:

- All the Joys of functional programming .

- Once you satisfy the compiler you can be fairly sure that code will just work.

- FRP saves you from callback hell.

- Fairly easy Javascript Integration via Ports( also see con on this)

- Time traveling debugger ( see con about this)

- Active mailing list.

- Automatic package versioning which more or less works for the most part

- Pure render function ( popularized by ReactJS), makes writing/debugging UI's trivial and painless.

- "Concurrent" FRP

Cons:

- Javascript integration is very and tedious. You have to declare all your ports in main which breaks abstractions. There is "secret" way of integration via Native modules but this will break if compiler changes ( which does quite often ).

- Debugger/reactor won't work if you have ports, basically all non trivial apps.

- All the ui components have to be reimplemented since stuff like jqueryui/webcomponents don't work ( react suffers from this also)

- No support for isomorphic apps, its a client side only tech.

- Can't do code splitting. Compiler generates one big blob of js.

- Constantly changing terminology ( eg: mailbox)

- IDE's/code editors are on the same level as dynamic languages i.e no code completion, refactoring ect.

Re: New Adventures for Elm

#37

Post by agrafix »

jey wrote: post #30

I've been looking at the options for pure-functional languages targeting JS, and it seems that PureScript is superior to Elm from a technical perspective for full-stack webdev. PureScript takes the approach of providing a full Haskell-like language that is "native" to the JS world. It has the features and type system of Haskell, but atop a cleaned up version of Javascript's semantics (e.g. strict evaluation, not lazy…

I'm currently moving from Elm to PureScript. Here's why (from "strong" to "weak"):

- Currently Elm has a sad story addressing integration with "native" javascript libraries and Elm is too opinioated in some cases, e.g. you can only use either the built-in 'Elements' or virtual-dom Elements to render frontend. This makes it hard to build modular components (see https://groups.google.com/forum/#!topic/elm-discuss/65tiRM7S... for example)

- While the simple type system in Elm (e.g. no type classes, no monads, ...) makes beautiful error messages possible, it really limits the abstractions that I am used to coming from Haskell

- Elm/Elm-make does not generate modules that conform to a "standard" js module system - thus it will not integrate well with other js tools

- Elm syntax is lacking 'where' clauses, which results in constant reindentation of code

Don't get me wrong - I liked Elm a lot; but it just does not seem mature enough to use in production - but it looks like a great language to start learning FP.

Re: New Adventures for Elm

#38

Post by pierrebeaucamp »

jey wrote: post #30

I've been looking at the options for pure-functional languages targeting JS, and it seems that PureScript is superior to Elm from a technical perspective for full-stack webdev. PureScript takes the approach of providing a full Haskell-like language that is "native" to the JS world. It has the features and type system of Haskell, but atop a cleaned up version of Javascript's semantics (e.g. strict evaluation, not lazy…

Out of PureScript, Elm, Haste and GHCJS, I like PureScript the most. What sold me on this language was the JS output after compilation - PureScript doesn't translate a huge runtime to JS (like the other options), it will only include the code which is actually needed.

Another advantage of PureScript: The foreign function interface is ridiculously easy to use.

Re: New Adventures for Elm

#39

Post by pka »

jey wrote: post #30

I've been looking at the options for pure-functional languages targeting JS, and it seems that PureScript is superior to Elm from a technical perspective for full-stack webdev. PureScript takes the approach of providing a full Haskell-like language that is "native" to the JS world. It has the features and type system of Haskell, but atop a cleaned up version of Javascript's semantics (e.g. strict evaluation, not lazy…

I moved from Elm to PureScript 1 month ago, and I don't regret it. Here's my earlier explanation why [0].

[0] https://news.ycombinator.com/item?id=10727009

Re: New Adventures for Elm

#40

Post by open-source-ux »

My comment is off-topic and likely to annoy people here, but I'll say it anyway: that entire page appears to have been generated in Javascript. If you view source, there is no HTML at all. What would a user with a screen reader hear if he or she were to visit that page?

If the page had been written in plain HTML and CSS, it might be about 10-15k in size. At the moment, written in Javascript, it's over 300K in page weight. So both inaccessible and bloated in page weight. This is really bad practice.

Post reply on HN