Graphics vs Html

[Trevor Rothaus]

What are the pros and cons of using the Html packages vs the Graphics packages?

I remember seeing a few people posting that switching from Graphics to Html was painful.

I also believe I saw that the Html toElement and fromElement can be expensive operations.

Maybe they're not directly comparable? What are the different use cases for using Graphics and for using Html?

[Hassan Hayat]

From having tried both packages quite a bit, the differences are quite big. They really serve different purposes.

Graphics: 

Pros: 

1. Easy and declarative
2. Allows you to draw free form graphics
3. Allows you to mix containers, text, and free form graphics seemlessly
4. Amazing for learning functional programming and Elm

Cons: 

1. Very limited access to what the DOM can offer in terms of APIs and CSS
2. No support for accessibility 
3. Old API in much need of revamp. Many lessons have been acquired in the making of applications (see, the Elm Architecture) which haven't fully been fed back to the Graphics API.
4. Performance is not ideal

Html: 

Pros: 

1. Can fully author Html or Svg (and thus have access to all the Html + CSS goodness)
2. Full support for accessibility via WAI-ARIA
3. Nicely supports the use of inline styles and thus allows to author entire applications that only require very minimal use of stylesheets (you might need a reset and a few classes to use CSS properties that are vendor-prefixed)
4. Performant (thanks to Virtual Dom and the ability and Html.Lazy)
5. Has informed the Elm Architecture, as such, it is made for making websites and applications.

Cons: 

1. It's just Html/Svg. The library does not save you from the awkwardness of Html/Svg. 
2. No access to 2D canvas APIs, so no free form elements. There is a big need for a solid library/update of Graphics.Collage on this front. 
3. Simple tasks get repetitive. (every node takes two lists, the second of which takes elements that take two lists, etc... this can get repetitive, but, again, that's html.)

As for when to use which. Use elm-html if you want to make a website or a web application. Use Graphics if you want to learn Elm, if you want to make a game, or if you want to make a small website/project. 

The transition from Graphics to elm-html doesn't have to be so painful. It so happens that with elm-html, the view functions tend to be much longer, but that is entirely due to actual Html and CSS. There are many facilities to make this less painful, like the Elm Architecture, or the use of inline styles. 

[Trevor Rothaus]

Thanks for the in-depth reply, I really appreciate the detail.

I started transitioning from Graphics to Html and noticed a few things.

One you mentioned, was that every node takes two lists, a list of attributes and a list of html elements.

- Would it be better to update the html library so that attributes are applied to html elements? It looks like it can't be done at the moment though: https://groups.google.com/d/msg/elm-discuss/KHoBr1me8_4/o-hDUUtmBuMJ.

It would be nice to be able to do something like this though:

customHeader = h1 [ text "Some Header" ]
     |> attribues customAttributes

It also seems that the ease of use that the Graphics library has can be implemented as functions in Html.

- I don't see a reason why we couldn't define an Html.flow function that mirrored the functionality of the one Graphics library.

- I think it would also be helpful to have functions such as Html.widthOf (not sure if this one is possible currently)

Adding layout and position functions like flow, could possibly make it easier for users, who may not have a lot of css knowledge, to create websites.

Adding helper functions like widthOf would be helpful in easily extending the functionality of the html library (for example, it could be used to create the flow function)

[John Askew]

For layout stuff, you might want to take a look at the flex-html package