Hi all,
going to try using elm-mdc for a project of mine, I discovered that aforemny is developing material-components-web-elm.
For which of them I should go?
Which of the two could go with elm-ui, too?
1 Like
Slightly different use cases I think. I prefer elm-mdc, as I can rely on Elm to remove unused code. For mcw-elm you pull in a lot of JavaScript. elm-mdc also demonstrates how you can build custom components on top of Material Design. mcw-elm won’t help, and you probably will want to do that in Typescript, defeating the purpose of using Elm.
On the other hand, mcw-elm is the actual JavaScript, so in cases elm-mdc hasn’t faithfully ported the functionality, mcw-elm would follow the reference implementation 100%.
2 Likes
Thanks for the response.
Do you know if elm-mdc could be used with elm-ui? Maybe to layout the widgets in some way in the page.
I don’t know how well that works, parts of it will, but Material Components has its own LayoutGrid, which you probably want to use in preference. So yes, you can use them together, but probably it’ll be elm-ui wrapped in elm-mdc components.
Maybe Orasund/elm-ui-widgets fits your purpose. Its a collection of ui widgets with a material design theme. Currently, it still lacks a lot of widgets you might expect from material design. I intend to add more as time goes on. But as a plus side it is meant to be used with elm-ui
Okay, I will give a try with elm-mdc. Actually it has a grid layout which could fit my needs.
As somebody who built and launched a production elm app using elm-mdc, I’m at the moment ripping it out to go with my own UI solution based on web components/custom elements not unlike material-components-web-elm and I would 100% switch to the new web components based system that aforemny is building. There is a reason he’s doing that.
Each component from elm-mdc is constructed using it’s own internal TEA with messages and state and it becomes a massive burden to to have to support them. In my opinion it will make your views unnecessarily complex.
I’m all on board the web component/custom element train for UI widgets as another commentator pointed out you are leaving the “safe” world of elm by using javascript in the widgets. This is a tradeoff I think is fine, I need Elm’s safety for the internal state of my app, when it comes to UI widgets I’m less concerned because they aren’t doing anything complicated, it’s basically just some wrapped html inputs most of the time.
At some point I independently reached the conclusion that I would leave elm-mdc for a web component based solution and I started building my own web components based on google’s web components for material design. Then I discovered that aforemny was already doing it and I checked it’s implementation and he’s doing it the right way if that means anything.
Eventually though I decided to get away from a platform UI and so I’m building my own custom elements (again use webcomponents) and I’m very happy to simplify all my views by removing elm-mdc (which also I’m grateful to aforemny for building it helped me get a version 1 out the door).
Those are good points. It makes more difficult to make a choice now 
Before searching for an elm UI ready solution, I have thought to build my own Web Components but reading around I had the impression that using Web Components was not the best way with Elm.
Now I can reconsider them, instead.
I have to say that my project is quite simple in the UI interactions but each page can contain
not a very small number of components.
I think web components + Elm is great so long as you understand that Elm Virtual dom is always the single source of truth and that you limit web components to simple UI elements at the leaf node level of your view. You can’t wrap an entire view in web components (I tried and if you screw this up it will be easily evident) but even with these limitations you can still make great use of web components and for me it’s a great solution because now I can easily use any JS UI components without having to go through ports.
I swear it never crossed my mind to use a Web Component to implement an entire view
Well, now you push all that state into web components. I don’t see any difference. And you need to get that state in and out. With elm-mdc the state is in your model, and the interaction between your components gets much cleaner.
But regardless, I’m using elm-mdc for the extremely nice UI, and the extremely detailed implementation of Material Design. All these custom components are years behind, and will never catch up to responsiveness and mobile features that Google’s Material Design for the Web has. Most Material Design components are cheap knockoffs, where they implement bits that sort of work, but on detailed examination don’t come close to the Material Design requirements, and professional UI people expect on a mobile.
2 Likes
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.