On Tue, Sep 20, 2016 at 4:29 AM, Ian Mackenzie <ian.e.macken...@gmail.com>
wrote:

> Peter, you may be interested in (and I'd appreciate your feedback on) a
> little library I've been working on for composable input widgets:
> https://github.com/kintail/input-widget
>

I took a superficial look at the library and it looks very interesting.
I need to play with it a little bit in order to give a proper feedback but
I wanted to say that this looks similar to an idea I had (around
serializing internal messages and internal state) only that it looks much
much better.
I'll get back with more feedback.


On Tue, Sep 20, 2016 at 5:39 AM, Richard Feldman <
richard.t.feld...@gmail.com> wrote:

> If these components are implemented in C++ and wrapped by the virtual-dom,
>>> we are lucky, we can use them. If they are not, we are out of luck.
>>>
>>
>  Or you can define a Web Component
> <https://developer.mozilla.org/en-US/docs/Web/Web_Components> like
> <myRadioButton> and then call node "myRadioButton" to create one. No C++
> involved.
>
> What's wrong with that?
>
> Nothing.
If Elm provides an official way to use TEA in order to implement Custom
Elements the discussions around Components will go away.
If someone comes and says "What if I have many small components that are
unavoidably stateful" the answer would be, "just use
elm-lang/custom-element"

I would also like to add that actual Custom Elements aren't even truly
needed here.
If an hypothetical elm-lang/custom-element library would create just
regular virtual-dom elements the issue would still be solved.


On Tue, Sep 20, 2016 at 5:47 AM, Nick H <falling.maso...@gmail.com> wrote:

> Peter, I also think the pain that you are feeling has a lot to do with the
> fact that there simply aren't very many UI libraries for Elm. Elm-mdl is
> the only one I ever hear anybody talk about. You are asking for an
> officially-sanctioned alternative to elm-mdl, but why does there need to be
> one?
>

Just to clarify a little bit, I was asking for an officially sanctioned
alternative to the approach elm-mdl took, not of the actual library.

The need for something like this stems from the fact that if we want to
promote elm to be an alternative to current front-end technologies, you
have to cater to beginners. They too should be able to create great
webpages.
The only way a beginner can create something nice looking and modern is to
rest on the work done by others. To use "components" that others have
implemented and optimized.

For example, I can take something like
http://www.creative-tim.com/live/paper-kit-pro
and with very little knowledge produce something that looks nice.

This would be close to impossible for a beginner with minimal CSS knowledge
working directly with elm-html and some external CSS tool or maybe elm-css.

There is also the "constrains liberate" idea. If the beginner has a great
library, they can stay within that library and be free from the hustle of
choosing which UI library to choose.
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.
elm-mdl might get reimplemented as just another theme of that elm-ui OR
they might use elm-ui as an example and do a similar implementation
(assuming that elm-ui does not rest itself on some Native code).





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

Reply via email to