Richard, Thank you for taking the time to write this considerate answer.
I apologize for the post I wrote yesterday. I was in a very very dark place after a night plagued by insomnia at the end of an extremely stressful week where I could not get anything done. Fear is the path to the dark side... and I think I let fear take over. Anyway, it is fascinating to see that such a seemingly simple topic has the brightest minds in the world still looking for an answer. I did not knew that the situation is this complicated. On Sun, Jul 10, 2016 at 8:54 PM, Richard Feldman < [email protected]> wrote: > > >> Regarding the user form, you said that what I asked is trivial in Elm. >> Do you have some kind of sample code that you can share or, if you would >> be so kind, could you post some sample repository that does that? >> > I would *LOVE* to be proven wrong about that. I would love to see some >> simple Elm code that outputs a form that looks like it came from 2016 and >> go "oops, my bad, sorry for wasting everyone's time". >> > > Sure - I even wrote a blog post > <http://tech.noredink.com/post/129641182738/building-a-live-validated-signup-form-in-elm> > about > it. :) > > That post includes examples in the form of SignupForm.elm > <https://gist.github.com/rtfeldman/ba60ad491cc6b58fe2cc4ca78f5a4580> and the > styles that go with it > <https://gist.github.com/rtfeldman/4ec263490ba9a1618b59#file-example-html-L7-L16>. > I > didn't bother inline the styles into Elm, but obviously that's a copy/paste > and find/replace job. > > All of Graphics.Input was dropped > > > Ah, I did not know that! My mistake. You're right, Janis. > > Regarding elm-mdl. I am well aware of the release of 6.0.0. I was not >> arguing that people are not still fighting. >> What I said was that "*they were explicitly or implicitly dismissed"*. >> > If you want me to be more explicit, I was thinking about the discussions >> around boilerplate that prompted elm-parts, the difficulties around >> geometry that prompted debois/elm-dom. >> > > Facebook released React with a built-in, dead-easy way to do reusable > stateful components: each component has its own local mutable state. > > However, they at Facebook weren't satisfied with how this UX scaled, so > they also released Flux as a more scalable way to manage state. > > Many people weren't happy with Flux, though, so they started looking > elsewhere, for example to ClojureScript, leading to Omniscient.js > <https://github.com/omniscientjs/omniscient> based on David Nolen's > cursor-based state management model for Om <https://github.com/omcljs/om>. > > David Nolen himself ended up moving away from that with Om Next > <https://github.com/omcljs/om/wiki/Quick-Start-(om.next)>, which > abandoned cursors in favor of a custom state management system based on > Relay, Falcor, and Datomic. Obviously not everyone agrees with him; > Omniscient.js is still under active development. Its last commit is 2 days > ago. > > Others looked to Elm, like Dan Abramov, who created Redux > <https://github.com/reactjs/redux>. It's very popular in the React world, > although since Facebook hired Dan, he's been working on ways to make React > not need it anymore. That seems likely to result in the release of a new > way to do things <https://xkcd.com/927/>, whenever whatever it is gets > released. > > Others thought Redux was too heavyweight and trying to do too much at > once, which has led to Choo <https://github.com/yoshuawuyts/choo#concepts>, > a self-described > <https://github.com/yoshuawuyts/choo#hey-doesnt-this-look-a-lot-like-elm> > adaptation of Elm 0.17's architecture in JS. > > I've spent hours discussing these things with Jafar Husain at Netflix, who > thinks Observables are the answer. See for example rx-react > <https://github.com/fdecampredon/rx-react> or Andre Staltz's popular > Cycle.js <http://cycle.js.org/>. > > This is to say nothing of how Angular manages state. Or Ember. Or Aurelia. > Or Vue. > > My point is this: > > *Every single community that's involved in making browser-based UIs is > flooded with conflicting viewpoints on how reusable stateful components > should be done.* > > There is not some glaringly obvious answer that will make everyone happy. > It does not exist. > > History strongly suggests that in this area,* making one group of people > happy makes others unhappy.* > > I was on a Skype call several months ago where Søren and Evan had an > extended discussion about his experiences developing elm-mdl. The fact that > Evan did not end up doing things the way you think he should is not a > reflection of Evan being dismissive of Søren's experience, it's that *reusable > stateful components are a minefield of tradeoffs*. > > Personally I think when one finds oneself in a minefield, it is wise to > tread carefully. :) > >> -- > You received this message because you are subscribed to the Google Groups > "Elm Discuss" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- There is NO FATE, we are the creators. blog: http://damoc.ro/ -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
