1. 18
  1. 2

    No separation of style, logic and content? Yikes. There ought to be a better way to do styling in pure Elm. If you can do so, introductory tutorials should show the right way. Duplication of RGB values is just wrong.

    1. 5

      Putting them in different files doesn’t actually make them separate. Messing with layout inevitably involves changing both the html and the css, and it’s common that changing one accidentally breaks the other.

      elm-ui at least tries to separate the layout of each component, so that changes to one component don’t magically break other distant components. And once things are represented in simple functions and data-structures we can use all our existing wisdom about how to organize and abstract things.

      1. 4

        I’m planning to talk about organising things in a subsequent post. I wanted to keep things simple to begin with.

        However, keeping layout, visual styling and other view code together is actually one of the main ideas of elm-ui, and I believe it’s a good idea. There’s a similar idea in React I believe.

        There’s more benefit in keeping all of the view code together than in maintaining separation. It’s easier to write and to modify if all the code is in one place.

        However, you would normally end up extracting things like a colour palette (as you point out) and groups of common styles into modules to avoid duplication.

        1. 1

          Elm traditionally follows MVU (Model View Update). However for such a brief example, showing the correct way of doing things I suspect would be cumbersome.

          I agree re duplication of RGB though, there’s no reason why they couldn’t have made a named variable for the color.

        2. 1

          I’ve used elm-ui a bit and it’s not bad, but it can become quite leaky, and when that happens, you pray that those htmlAttributes work (and they usually do).

          What downsides have you found with elm-ui?

          1. 1

            You’re right, it’s still very much an evolving project, and not everything is possible to do without workarounds. Fortunately, there is the escape hatch of html/htmlAttribute. I haven’t really run into problems myself because I haven’t had to build really complicated UIs with it; I’m not sure what the story is with animation, for example.

          2. 1

            If I understand properly, elm-ui is a set of primitive components that exposes different properties than HTML/CSS (and allows you to dive into it if needed).

            Forgive me if I’m short sighted, but is this different than say a library of UI components like https://ant.design for example (assuming you stick the their lower level components)? Or even Bootstrap itself, if we abstract the difference in the API.

            Maybe the text just won’t align vertically (…) effect at all.

            At one point, for elm-ui to be a general UI solution it needs to expose a significant set of CSS capabilities, so the question ends up being, is it feasible to expose a better CSS API than CSS itself, while not being restricted to a narrow set of UI?

            The latter goal is a completely justifiable scope as well, just curious about elm-ui’s positioning in the market.

            1. 1

              The short answer is: yes, it’s absolutely feasible.

              The longer version requires a couple of caveats. I don’t think that elm-ui is particularly focused on document layout. Instead, it’s primarily for dynamic application UIs, so its goal isn’t to be a 100% replacement. I’m not sure that rich document layout capabilities and rich application UI capabilities should be provided by the same library/framework, or indeed whether it’s even possible. Certainly, the HTML/CSS/JavaScript triumvirate isn’t a convincing example.

              This brings me to the reasons why I think a better API is possible:

              • elm-ui isn’t trying to be some sort of backward compatible addition, instead it’s starting from scratch. I think that’s the most obvious scenario for achieving a better API, and there are plenty of examples of this sort of successful replacement. Simply by virtue of starting with an existing solution (HTML/CSS/JavaScript) to learn from, a blank slate for a new UI language, and a current set of use cases to consider all together, elm-ui is in a great position to provide a better solution.
              • As a corollary, HTML/CSS/JavaScript accreted over decades through a wide range of influences, so almost by definition it cannot be a good API (hell, it’s three separate languages). I’m not sure that any API can survive the sort of transformation that’s occurred on the web.
              • elm-ui implicitly claims that it is possible to express all of the aspects of a UI using a single language instead of three languages. That is certainly a massive improvement in usability from a programmer’s point of view. It is possible that it will and so far I think it’s true. But of course, it will be challenging to maintain a clear API as more functionality is added and it’s put to new uses.