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

Reply via email to