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

31–40 of 92 posts

Re: Making Elm faster and friendlier in 0.16

#31

Post by boubiyeah »

jmite wrote: post #17
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…

It seems to work for NoRedInk and CircuitHub...

It is also possible to write the most complex app ever using just vanilla Javascript/JQuery too, but it's not viable or fun to maintain.

The elm language brings a lot of value compared to the very unsafe javascript; I'm only questioning the validity (or immaturity) of the component architecture.

Re: Making Elm faster and friendlier in 0.16

#32

Post by ablesearcher »

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…

@rtfeldman -- I think your response is a bit disingenuous since only yesterday you wrote, in response to a question about cursor state, this:

"I wouldn't maintain cursor state in the model; I'd just implement the port like this: http://stackoverflow.com/a/14508837/2334666

In other words, you never use the value attribute on the input; rather, you give it a unique key and don't touch it directly. Whenever you want to change its value, just send the desired new value to that port and let the JS snippet do the "stash cursor position, set the new value, restore cursor position" bit.

If you need to do this for multiple elements, send a DOM query string to the port and call document.querySelectorAll (or the like) with it to apply the logic to the correct element."

(See https://groups.google.com/forum/#!topic/elm-discuss/I2JleY8b...)

Clearly, you don't even believe that all component local state belongs in the atom. And kicking the issue to JS-land is just hiding the problem.

Almost everything should be unidirectional, but @boubiyeah has a valid point. Not everything belongs in a single state atom. (I say this having written a 4000 LOC Elm app, which I'm porting Clojurescript/Re-frame due to precisely this issue.) Even Haskell uses mutable references for this stuff.

Re: Making Elm faster and friendlier in 0.16

#33

Post by boubiyeah »

jwmerrill wrote: post #27
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 so…

I think that's a fair point. To be honest, I'm more concerned about the real limitations of the paradigm (the nice-to-have features I will have to pass because the architecture is a bit too closed)

Re: Making Elm faster and friendlier in 0.16

#34

Post by bribri »

Has anyone tried Reflex? Really interesting concept in Haskell + GHCJS https://github.com/ryantrinkle/try-reflex

I liked Elm but I felt the language was a bit limited coming from Haskell, ex no type classes so you have List.map, Signal.map, Set.map, etc

Overall Elm is great in terms of tooling, setup, error messages, performance, js interop though

Re: Making Elm faster and friendlier in 0.16

#35

Post by boubiyeah »

rtfeldman wrote: post #30
boubiyeah wrote: post #28

Earlier quoted context omitted.

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

Fine article... But all that it tells me from my experience is that it's a good thing to put 80-90% of the app state in a central atom :p A good practice or rule of thumb is just that, it shouldn't always be the only way to do things.

Re: Making Elm faster and friendlier in 0.16

#36

Post by nwienert »

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…

Actually, you do see a lot of questions and problems with the single state atom. In fact, I'd argue it's inherently a side step towards a future that has the best of both worlds: encapsulated state within components, but backed by some global state store invisibly.

This is exactly what Relay is by the way. You component asks for state, and gets it from a server. The fact that it comes through props is actually just a downgrade because it means you must now treat it as some special thing, and not variables.

In the ideal world, we can write simple components that fetch state from wherever (remote, local, global). They store that state into themselves, and it "just works". They can write back that state just like how they write variables. And all of this "local" state would really be backed into a global state store invisibly.

Local state - Pros: easy to reason about, easy to use. Cons: trapped in one place, inflexible.

Global state - Pros: can be backed in various ways, easier to share. Cons: Hard to use, harder to reason about.

Local state backed to global store - Has all the pros and none of the cons. Unfortunately doesn't exist yet today.

Re: Making Elm faster and friendlier in 0.16

#37

Post by ryanflorence »

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…

I went back to component state.

Re: Making Elm faster and friendlier in 0.16

#38

Post by ablesearcher »

bribri wrote: post #34

Has anyone tried Reflex? Really interesting concept in Haskell + GHCJS https://github.com/ryantrinkle/try-reflex I liked Elm but I felt the language was a bit limited coming from Haskell, ex no type classes so you have List.map, Signal.map, Set.map, etc Overall Elm is great in terms of tooling, setup, error messages, performance, js interop though

Reflex is great (and its author is a genius) but it's not really useful yet for non-desktop apps. Because Reflex + GHCJS is impossibly slow on mobile.

As an experiment, try using chrome (iOS) or android to load this:

obsidian.systems/reflex-nyhug/

or this:

https://obsidian.systems/

They're both reflex apps.

GHCJS is bees-knees. But unfortunately, minimizing-code-size/mobile-performance has not been a priority. (It's understandable, as Luite can't do everything himself.) (Aside: the best solution I've seen -- in terms of generated code size -- in GHCJS-land right now is: https://hackage.haskell.org/package/react-flux. Anecdotal, though. YMMV.)

I can't wait for GHCJS to be ready for prime time. I wish all these alt-JS-haskellish language authors (of Purescript, Elm, Roy, etc.) would just work on making GHCJS better.

It's a bummer that Clojure and Scala are much newer than Haskell and yet they both have a mature, production-ready JS compiler. The statically typed ML-family is too small for multiple JS compilers. The entire community needs to pick one and let the others die. Otherwise, we end up with several half-baked solutions and not a single industrial-strength one.

Re: Making Elm faster and friendlier in 0.16

#39

Post by vilterp »

ablesearcher wrote: post #32
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…

@rtfeldman -- I think your response is a bit disingenuous since only yesterday you wrote, in response to a question about cursor state, this: "I wouldn't maintain cursor state in the model; I'd just implement the port like this: http://stackoverflow.com/a/14508837/2334666 In other words, you never use the value attribute on the input; rather, you give it a unique key and don't touch it directly. Whenever you want to…

Maybe the answer is for elm-html to put a cursor-state attribute on textual input elements, and have event handlers for selection change? Then you can have the cursor state in your atom if you need it without ports....

Re: Making Elm faster and friendlier in 0.16

#40

Post by purescript »

ablesearcher wrote: post #38
bribri wrote: post #34

Has anyone tried Reflex? Really interesting concept in Haskell + GHCJS https://github.com/ryantrinkle/try-reflex I liked Elm but I felt the language was a bit limited coming from Haskell, ex no type classes so you have List.map, Signal.map, Set.map, etc Overall Elm is great in terms of tooling, setup, error messages, performance, js interop though

Reflex is great (and its author is a genius) but it's not really useful yet for non-desktop apps. Because Reflex + GHCJS is impossibly slow on mobile. As an experiment, try using chrome (iOS) or android to load this: obsidian.systems/reflex-nyhug/ or this: https://obsidian.systems/ They're both reflex apps. GHCJS is bees-knees. But unfortunately, minimizing-code-size/mobile-performance has not been a priority. (It's…

> I wish all these alt-JS-haskellish language authors (of PureScript, Elm, Roy, etc.) would just work on making GHCJS better.

All three of those have very different goals and trade-offs from GHCJS.

I agree that it would be nice to share more work/knowledge though. One of the nice things about AltJS is that several languages can coexist in the same codebase.

Post reply on HN