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

Making Elm faster and friendlier in 0.16

elm-lang.org

Post reply on HN
Print view View original

21–30 of 92 posts

Re: Making Elm faster and friendlier in 0.16

#21

Post by jdudek »

Apanatshka wrote: post #19
boubiyeah wrote: post #14

I find the Elm language quite fun and I think it has potential. However, I'm absolutely not convinced about "the Elm architecture" for anything but the simplest UIs. Is pure functional reactive programming suitable for ambitious UIs ? I do not think so. React has its own set of flaws but at least I believe it nailed the state problem: Encourage the minimization of local state but still make it easy to have some when…

I think there simply needs to be more exploration in the area. I only know of one person who tried something truly different than the Elm Architecture who wrote about it on the mailing list. Anyone interested and with time to spend should just try different things, be critical of their attempt's ease of use and ease of abuse and see what works. I think eventually there might be a performance problem with scaling, and…

Do you happen to remember what was the idea of that approach alternative to Elm Architecture?

Re: Making Elm faster and friendlier in 0.16

#22

Post by tlarkworthy »

boubiyeah wrote: post #14

I find the Elm language quite fun and I think it has potential. However, I'm absolutely not convinced about "the Elm architecture" for anything but the simplest UIs. Is pure functional reactive programming suitable for ambitious UIs ? I do not think so. React has its own set of flaws but at least I believe it nailed the state problem: Encourage the minimization of local state but still make it easy to have some when…

I have been studying this, Elm explicitly forbids "signals of signals". This basically bans dynamic mutation of the dataflow graph and makes dynamic Gui's very difficult. The solution is not to enable signals of signals, because they are a source of problems. The solution would be to hoist all the functions up one level and operate on a dataflow graph comprised of transformations of signal transforms. This will kill many of the nice properties of Elm (hot code replacement), but the cost of the current system is that its unusable for application context switches and dynamic GUIs. In the literature the high level style of FRP is called AFRP (arrowized FRP).

I am currently prototyping AFRP ideas in Typescript and RxJS, although its very early days and basically not usable ATM. https://github.com/tomlarkworthy/animaxe (a better typed version is in a branch and not compiling ATM)

Re: Making Elm faster and friendlier in 0.16

#23

Post by rtfeldman »

boubiyeah wrote: post #14

I find the Elm language quite fun and I think it has potential. However, I'm absolutely not convinced about "the Elm architecture" for anything but the simplest UIs. Is pure functional reactive programming suitable for ambitious UIs ? I do not think so. React has its own set of flaws but at least I believe it nailed the state problem: Encourage the minimization of local state but still make it easy to have some when…

Local component state is the new two-way data binding.

Three years ago, two-way data binding was the gold standard for niceness. Then React came out, and there was buzz around unidirectional data flow, and a lot of (understandable!) skepticism came with it.

If you listen to people who have spent a lot of time with two-way data binding and unidirectional data flow, what you hear are a lot of unidirectional data flow converts and not a lot of people saying "yeah it wasn't awesome so I went back to two-way data binding."

We're watching the same thing play out with local component state versus a single state atom architectures like The Elm Architecture, Redux, etc. As with the React transition, there is understandable skepticism around new things claiming to be nice, but the writing is on the wall.

If you listen to people who have spent a lot of time with both systems, what you hear are a lot of single state atom converts and not a lot of people saying "yeah it wasn't awesome so I went back to local component state."

Re: Making Elm faster and friendlier in 0.16

#24

Post by rtfeldman »

methehack wrote: post #11

I'm trying to decide between Elm and React/Reflux for the js part of a side project. I'm concerned about learning curve and awkwardness of adoption if the project ever turns into something someone else is coding on. I know they are very different technologies, but I think others must be choosing between them. Any thoughts from those who have tried both?

I gave a talk going through this very conundrum. :)

https://www.youtube.com/watch?v=FV0DXNB94NE

Re: Making Elm faster and friendlier in 0.16

#25

Post by Apanatshka »

jdudek wrote: post #21
Apanatshka wrote: post #19

Earlier quoted context omitted.

I think there simply needs to be more exploration in the area. I only know of one person who tried something truly different than the Elm Architecture who wrote about it on the mailing list. Anyone interested and with time to spend should just try different things, be critical of their attempt's ease of use and ease of abuse and see what works. I think eventually there might be a performance problem with scaling, and…

Do you happen to remember what was the idea of that approach alternative to Elm Architecture?

I'm not sure if it was [0] or [1]..

[0]: https://groups.google.com/d/topic/elm-discuss/NJCZFIYxshE/di...

[1]: https://groups.google.com/d/topic/elm-discuss/ZJ6lkfPimW8/di...

Re: Making Elm faster and friendlier in 0.16

#26

Post by rtfeldman »

tlarkworthy wrote: post #22
boubiyeah wrote: post #14

I find the Elm language quite fun and I think it has potential. However, I'm absolutely not convinced about "the Elm architecture" for anything but the simplest UIs. Is pure functional reactive programming suitable for ambitious UIs ? I do not think so. React has its own set of flaws but at least I believe it nailed the state problem: Encourage the minimization of local state but still make it easy to have some when…

I have been studying this, Elm explicitly forbids "signals of signals". This basically bans dynamic mutation of the dataflow graph and makes dynamic Gui's very difficult. The solution is not to enable signals of signals, because they are a source of problems. The solution would be to hoist all the functions up one level and operate on a dataflow graph comprised of transformations of signal transforms. This will kill…

What do you mean by "dynamic GUI"? As opposed to what other kind of GUI?

Re: Making Elm faster and friendlier in 0.16

#27

Post by jwmerrill »

boubiyeah wrote: post #14

I find the Elm language quite fun and I think it has potential. However, I'm absolutely not convinced about "the Elm architecture" for anything but the simplest UIs. Is pure functional reactive programming suitable for ambitious UIs ? I do not think so. React has its own set of flaws but at least I believe it nailed the state problem: Encourage the minimization of local state but still make it easy to have some when…

> There are all sorts of transient states that a parent's component shouldn't have to care about.

The problem with this way of thinking is that there are invariably things that you initially believe will be of no concern to the parent that later become concerns of the parent. It's tempting at that point to graft on some event system so the parent can watch the things that it now cares about, and then maybe you add some hooks to allow the parent to preempt or change certain behaviors. This evolution requires careful thinking every time, and it's easy to make mistakes.

The great thing about the elm architecture is that from the very beginning, it gives the parent all the hooks it will ever need to observe and modify the behavior of children. In the beginning, when the parent doesn't care, it just passes the actions up and passes the model back down without having to look at them. That might feel a little bit boilerplate-y at the beginning when you don't need it, but it's the same everywhere, so it isn't difficult at all. And once you've done this, evolution of the components requires much less thinking about architecture, and leaves much less room for mistakes.

Re: Making Elm faster and friendlier in 0.16

#28

Post by boubiyeah »

rtfeldman wrote: post #23
boubiyeah wrote: post #14

I find the Elm language quite fun and I think it has potential. However, I'm absolutely not convinced about "the Elm architecture" for anything but the simplest UIs. Is pure functional reactive programming suitable for ambitious UIs ? I do not think so. React has its own set of flaws but at least I believe it nailed the state problem: Encourage the minimization of local state but still make it easy to have some when…

Local component state is the new two-way data binding. Three years ago, two-way data binding was the gold standard for niceness. Then React came out, and there was buzz around unidirectional data flow, and a lot of (understandable!) skepticism came with it. If you listen to people who have spent a lot of time with two-way data binding and unidirectional data flow, what you hear are a lot of unidirectional data flow c…

Don't know, I never liked two-way bindings :) Adobe Flex added those at some point but it was a complete downgrade from the simpler one way bindings + events.

A central state atom has pros (debug tooling and the fabled undo for free being the main ones?) and cons. The cons affects me more than the pros. Clojure's Om and React+redux maintain a central atom but still allow for local state in a pinch.

I appreciate your comment but I wish it was a bit more constructive; Why do you think a central state atom is so much better ? How can one write ready-to-use smart components with central state ? (e.g ReactTransitionGroup)

Re: Making Elm faster and friendlier in 0.16

#29

Post by garyclarke27 »

If Elm had a dedicated library for io with Postgres functions (stored procedures) would then become very attractive to my company, for a very ambitious project we are developing. we store all state and logic inside db safely firewalled by stored procs, so i'm looking for UI focused language/ toolset that is productive, functional and produces atractive ultra reliable, performant html js. I don't feel good about the Sencha tools, my team currently uses, so I'm looking around for alternatives. ur/web looks very interesting aswell but the limited adoption with only 1 albeit genius developer, is a bit offputing

Re: Making Elm faster and friendlier in 0.16

#30

Post by rtfeldman »

boubiyeah wrote: post #28
rtfeldman wrote: post #23

Earlier quoted context omitted.

Local component state is the new two-way data binding. Three years ago, two-way data binding was the gold standard for niceness. Then React came out, and there was buzz around unidirectional data flow, and a lot of (understandable!) skepticism came with it. If you listen to people who have spent a lot of time with two-way data binding and unidirectional data flow, what you hear are a lot of unidirectional data flow c…

Don't know, I never liked two-way bindings :) Adobe Flex added those at some point but it was a complete downgrade from the simpler one way bindings + events. A central state atom has pros (debug tooling and the fabled undo for free being the main ones?) and cons. The cons affects me more than the pros. Clojure's Om and React+redux maintain a central atom but still allow for local state in a pinch. I appreciate your…

Here's a long-form answer to both questions. :)

https://www.safaribooksonline.com/blog/2015/10/29/react-loca...

Post reply on HN