elm-html: the future or a stopgap?

[Eric West]

I've been a bit confused on what I've read about elm-html so I thought I'd ask here in a straightforward way: Is elm-html the expected way to make rich web apps using elm for the foreseeable future or is it a stopgap until there are more complex UI widgets in libraries created from the basic Elm.Graphics types?  I'm currently planning a web app I intend to build in Elm from scratch, one which will grow fairly sophisticated over time, and I'd like to build it "the right way", even if this slows me down. This is a personal project which is going to take a long time anyways, so I'm in no hurry.  

Thanks a lot,

Eric

[Evan Czaplicki]

Sorry for the delay, I think the answer is "both" but the key concern is timing.

My emphasis will be on elm-html as a way to get a foothold among people who like to make stuff. It's the quickest way to bring the whole power of the browser's renderer to Elm, and the quickest way to get Elm to end users. So I'd say go for elm-html right now.

Long term, I hope to arrive at something superior to elm-html, but I don't know how long that term is. I don't think Elements are there yet. There are questions like "how do a do a custom dropdown?" that we just have not gotten to yet. I don't know what we'll need to do to close that gap, but it's certainly a goal. When I get a chance, I'm going to add a function (Html.fromElement : Element -> Html) which is easy and means you can use Elements as much as possible / reasonable. I hope that'll let us write more and more in Elements as that API gets more robust.

Does that sort of help clarify?

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

[Eric West]

Excellent answer. Thanks a lot for it. Definitely clears up the confusion I had.

[Sean Corfield]

I recently had to build a fairly complex piece of UI for an existing app and after quite a bit of experimentation decided to settle on a pair of HTML5 "sliders" (input type="range") as the best UX.

I initially thought I might build it in Elm but couldn't see how to - easily - manage such things in "standard" Elm, so I did it in raw JS/HTML. It wasn't horrible but it wasn't very pleasant either. However, I'd like to take another run at it in Elm and after looking through the libraries available, it seems like my only option right now is elm-html since that seems to be the only way to get a raw input type="range" into the DOM. Reading through the archives tho' it seems that integrating elm-html with signals is a little awkward, so I wanted to resurrect this thread from October and get a sense of where Elm is going, as regards to generating and reacting to HTML inputs that are not just text, keyboard, or mouse events?

In my case, I would need:

* an easy way to render arbitrary input elements from a set of attributes (which might change in response to signals and therefore trigger re-rendering) - elm-html seems to support that

* an easy way to extract all the "input events" from those live input elements as a signal - sounds like this is tricky with elm-html?

* mix fine-grained input elements with "regular" Elm elements - it's not clear to me whether this is possible / advisable with elm-html

On the latter point, the TodoMVC example of elm-html seems to be "all HTML" rather than using elm-html just for things that are hard to render / control with plain ol' Elm. Is that just because of the way the example is constructed or are there issues trying to mix'n'match?

The Graphics.Input module is very limited in terms of the controls you can create. Graphics.Input.Field is also fairly limited - and supports only three types of text inputs.

What is the current state-of-the-art on HTML inputs in Elm, and what if any future plans are there?

Sean

[Jeff Smits]

On Wed, Jan 21, 2015 at 9:03 PM, Sean Corfield <se...@corfield.org> wrote:

I recently had to build a fairly complex piece of UI for an existing app and after quite a bit of experimentation decided to settle on a pair of HTML5 "sliders" (input type="range") as the best UX.

I initially thought I might build it in Elm but couldn't see how to - easily - manage such things in "standard" Elm, so I did it in raw JS/HTML. It wasn't horrible but it wasn't very pleasant either. However, I'd like to take another run at it in Elm and after looking through the libraries available, it seems like my only option right now is elm-html since that seems to be the only way to get a raw input type="range" into the DOM. Reading through the archives tho' it seems that integrating elm-html with signals is a little awkward, so I wanted to resurrect this thread from October and get a sense of where Elm is going, as regards to generating and reacting to HTML inputs that are not just text, keyboard, or mouse events?

In my case, I would need:

* an easy way to render arbitrary input elements from a set of attributes (which might change in response to signals and therefore trigger re-rendering) - elm-html seems to support that

 

Yes, elm-html should support all that. 

 

* an easy way to extract all the "input events" from those live input elements as a signal - sounds like this is tricky with elm-html?

 

I think it's actually done pretty well. Have you worked with 0.12 Inputs or 0.14 Channels before? (they're almost the same thing) The Channels of 0.14 work equally well with Html.Events and Graphics.Input. 

 

* mix fine-grained input elements with "regular" Elm elements - it's not clear to me whether this is possible / advisable with elm-html

I have yet to hear of any downsides of using Html.toElement, which allows you to mix it up. 

 

On the latter point, the TodoMVC example of elm-html seems to be "all HTML" rather than using elm-html just for things that are hard to render / control with plain ol' Elm. Is that just because of the way the example is constructed or are there issues trying to mix'n'match?

The Graphics.Input module is very limited in terms of the controls you can create. Graphics.Input.Field is also fairly limited - and supports only three types of text inputs.

What is the current state-of-the-art on HTML inputs in Elm, and what if any future plans are there?

Sean

On Tuesday, October 28, 2014 at 1:21:41 PM UTC-7, Evan wrote:

Sorry for the delay, I think the answer is "both" but the key concern is timing.

My emphasis will be on elm-html as a way to get a foothold among people who like to make stuff. It's the quickest way to bring the whole power of the browser's renderer to Elm, and the quickest way to get Elm to end users. So I'd say go for elm-html right now.

Long term, I hope to arrive at something superior to elm-html, but I don't know how long that term is. I don't think Elements are there yet. There are questions like "how do a do a custom dropdown?" that we just have not gotten to yet. I don't know what we'll need to do to close that gap, but it's certainly a goal. When I get a chance, I'm going to add a function (Html.fromElement : Element -> Html) which is easy and means you can use Elements as much as possible / reasonable. I hope that'll let us write more and more in Elements as that API gets more robust.

 

--

[Evan Czaplicki]

Sean, I think the stuff you need to do should be quite nice in Elm at this point! As an example, both the drop down and text field on this page are done with elm-html and everything else is done with Elements. That uses the Html.toElement that Jeff linked to.

This tutorial has some minimal examples of using elm-html to do some basic interactions, but the idea generalizes to any kind of inputs you want to use.

Does that help? Is there more info we can give? (I want you to use Elm!)

[Rehno Lindeque]

* an easy way to extract all the "input events" from those live input elements as a signal - sounds like this is tricky with elm-html?

Unfortunately it's not ready to be used (not complete + we're planning to make a pretty sweeping change to the api so that argument lists seem less obscure), but elm-html-shorthand has a couple of wrappers for input elements that might be worth looking at the source code: inputs deal with both continuously updating inputs or discrete ones where that update when the enter key is hit and also parsing numeric inputs. There are also buttons, but no range element yet: please feel free to PR.

(Just to reiterate: All the signatures for this are likely change soon, so don't depend on this for anything big just yet)

[Joe Fiorini]

I used elm-html exclusively (no use of Graphics.Element anywhere) to build Flittal, a flow charting tool (code at https://github.com/joefiorini/flittal). Although the API is a little awkward (having to hand in empty lists all over the place) it is low-level enough that I was able to do 95% of what I can do in plain HTML. The way Html types nest makes building an elm app feel like building a React app. The only limitations I've come across so far are:

1. Lack of support for data-* attributes (annoying, but been able to work around)

2. Hard to support stateful event workflows (eg. HTML5 drag/drop events) - able to work around with ports

3. Can't call functions that don't return anything (ie. preventDefault, which isn't a problem often, but was in one case for me. I got around it with a Native module)

Hope this helps. I'd be happy to chat about my experiences so far in more detail if you'd like.

- Joe

[Evan Czaplicki]

Very cool Joe, this is really useful feedback! Would you mind breaking this out into a separate discussion of how to improve elm-html?

I think 1 is easy to support. It's unclear to me exactly what's rough with #2. And I'd be curious to hear your specific use case on #3 because it may be relevant to promise stuff.

--

[Laszlo Pandy]

What do you use data-* attributes for? I never had to use them in my html.

On Thu, Jan 22, 2015 at 4:00 PM, Joe Fiorini <j...@joefiorini.com> wrote:

--

[Sean Corfield]

On Jan 22, 2015, at 2:36 AM, Evan Czaplicki <eva...@gmail.com> wrote:

As an example, both the drop down and text field on this page are done with elm-html and everything else is done with Elements. That uses the Html.toElement that Jeff linked to.

That’s a big help, thank you. It seems Html.toElement requires x/y sizes? You can’t convert an Html to an Element and have it just take up the size it needs?

This tutorial has some minimal examples of using elm-html to do some basic interactions, but the idea generalizes to any kind of inputs you want to use.

That’s also very helpful. I’d read it before but it hadn’t "connected" to what I was trying to do. I have about half of the problem sketched out in the try Elm window so that’s really helping.

Does that help? Is there more info we can give? (I want you to use Elm!)

:) So do I!

Right now it’s looking like the Elm version will be substantially longer than the native JS version but it will be much cleaner and less error prone.

I’m working on a bunch of stuff right now to make a case for FRP over "raw JS" at work because I don’t want us to end up with a massive pile of unmaintainable JS spaghetti, so this is a proving ground for Elm, with many more "mini-projects" to come. I want it to be Elm or ClojureScript/Reagent (a React.js wrapper), so I’m building a number of small things in both.

Sean Corfield -- (904) 302-SEAN

An Architect's View -- http://corfield.org/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)