Live data from Hacker News

The Elm Architecture

github.com

11–20 of 38 posts

Re: The Elm Architecture

#12

So out of all the compile-to-javascript languages out there, elm is easily my favorite, despite not being usable outside the browser. This article is one illustration why it is so attractive: app architecture that is blindingly simple (its all just state machines under the cover, which is exactly what a UI is). Now all we need is an elm that compiles to native code that somehow can do what React Native is doing for t…

I haven't tried Elm yet but my favourite thus far is ClojureScript. Last I used it the workflow had a few rough edges but once I discovered you didn't HAVE to create closure(the google closure stuff) mappings it became easier to get the feet wet.

I should take Elm for a drive.

Re: The Elm Architecture

#13

So out of all the compile-to-javascript languages out there, elm is easily my favorite, despite not being usable outside the browser. This article is one illustration why it is so attractive: app architecture that is blindingly simple (its all just state machines under the cover, which is exactly what a UI is). Now all we need is an elm that compiles to native code that somehow can do what React Native is doing for t…

I, too, really love Elm, and have worked on some tooling for getting it running on the server. (Self promotion ahead). I wrote an NPM module for compiling and loading Elm[1], and also put together a more comprehensive project for scaffolding an Express application to communicate between Elm in the browser and Elm on the server, via ports (this is the first time I announce it anywhere, since I want to have some full examples before anything "official", but it is usable today).

1. https://www.npmjs.com/package/elm-loader

2. https://www.npmjs.com/package/elm-expressway

Re: The Elm Architecture

#14
post #4

Earlier quoted context omitted.

Haskell with an FRP library may work for what you want to do. Reactive-banana looks good, though I haven't used it.

I'll echo this. Elm was a bit of a gateway drug for me getting into Haskell. Haskell itself has a lot of very powerful tools.

This post builds the intuition for something like the Netwire library

http://blog.jle.im/entry/effectful-recursive-real-world-auto...

Re: The Elm Architecture

#15
post #13

So out of all the compile-to-javascript languages out there, elm is easily my favorite, despite not being usable outside the browser. This article is one illustration why it is so attractive: app architecture that is blindingly simple (its all just state machines under the cover, which is exactly what a UI is). Now all we need is an elm that compiles to native code that somehow can do what React Native is doing for t…

I, too, really love Elm, and have worked on some tooling for getting it running on the server. (Self promotion ahead). I wrote an NPM module for compiling and loading Elm[1], and also put together a more comprehensive project for scaffolding an Express application to communicate between Elm in the browser and Elm on the server, via ports (this is the first time I announce it anywhere, since I want to have some full e…

Interesting. So basically Reactive Haskell right inside the NodeJS.

Did you able to run any performance test yet? I'm interested to learn more about this.

Re: The Elm Architecture

#16
post #4

So out of all the compile-to-javascript languages out there, elm is easily my favorite, despite not being usable outside the browser. This article is one illustration why it is so attractive: app architecture that is blindingly simple (its all just state machines under the cover, which is exactly what a UI is). Now all we need is an elm that compiles to native code that somehow can do what React Native is doing for t…

Haskell with an FRP library may work for what you want to do. Reactive-banana looks good, though I haven't used it.

The trouble though comes about once you have to start working with a UI library. It's a mess and a half unless you use C++. I'd like to try using Elm, or Purescript for UI work using atom-shell or nw.js. That opens almost the same can of worms (how easy it might be to 'bind' your engine to your UI/view). I've written a non-trivial application using QtWebkit entirely for the UI and it was a very agreeable experience. The engine of this app was C++ but it got my gears turning.

Re: The Elm Architecture

#17
post #3

My experience with Elm was that it's very elegant and fun to work with if you are building a purely clientside application, but once you need communication with server the APIs are not very well developed and it becomes a major headache. Note that none of the examples in this page (or in any Elm tutorial I found) flesh out interaction with a backend.

Promises are going to solve this problem in an elegant way, expect it in next major release.

That said, I've release a client/server game (online sailing regattas) in Elm & Play/Scala with websockets, and current API was enough for me: https://github.com/etaque/tacks

Re: The Elm Architecture

#18
post #16
post #4

Earlier quoted context omitted.

Haskell with an FRP library may work for what you want to do. Reactive-banana looks good, though I haven't used it.

The trouble though comes about once you have to start working with a UI library. It's a mess and a half unless you use C++. I'd like to try using Elm, or Purescript for UI work using atom-shell or nw.js. That opens almost the same can of worms (how easy it might be to 'bind' your engine to your UI/view). I've written a non-trivial application using QtWebkit entirely for the UI and it was a very agreeable experience.…

Actually that I my opinion from any web based UI, a mess of JavaScript/CSS trickery and HTML.

Native UI development feels so much more advanced and user friendly.

Saying this as a UX developer since the mid-90's.

Re: The Elm Architecture

#19
post #3

My experience with Elm was that it's very elegant and fun to work with if you are building a purely clientside application, but once you need communication with server the APIs are not very well developed and it becomes a major headache. Note that none of the examples in this page (or in any Elm tutorial I found) flesh out interaction with a backend.

It this problem bad enough that you would consider it to be a deal breaker? Can't one shell out to JS for the pain points?

Re: The Elm Architecture

#20
It all looks great, but I wonder what happens when my model is actually a large database (or, for example, a large map), and the visual components are each observing changes in this database (or map). Would the database be one big signal? Or would the database be a large collection of signals? How would one model this (efficiently) in elm?
Post reply on HN