> If Elm provides an official way to use TEA in order to implement Custom 
> Elements *the discussions around Components will go away.*

 For example, if elm-html library would be supplemented by an elm-ui 
> library that is just as easy to use as elm-html but it is as extensive as 
> Semantic UI and just as customizable (themes) *the discussion around 
> small stateful components might just go away. *

Respectfully, the discussions around components keep happening because 
people start them. Asking "how do I have stateful components with 
closure/nesting" falls prey to the XY problem, and also misses a lot of the 
philosophy of language design that Evan has talked about, most recently in 
his elm-conf keynote <https://www.youtube.com/watch?v=DSjbTC-hvqQ>. To 
paraphrase, Elm is a young language and we're more concerned with doing 
things right for the future than making a good language today. Another key 
quote from his status updates: *choose not to block*. Going around and 
demanding new language features that fit your style of code is not helpful.

And by the XY problem, once again I ask that if the fundamental concern is 
the statefulness of HTML tags like dropdowns, let's address that in another 
thread. Getting HTML to do everything it can do when managed by JS is a web 
platform concern. Let's come up with specific examples of things we can't 
do (not just can't do easily, can't do at all) with HTML inputs.

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 elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to