elm-ui VS elm-format

It's been a few years, but last time I built a non-trivial Elm app, I used elm-ui. Otherwise, I've used either vanilla CSS with the Meyer reset (am I dating myself?) or SCSS.

"clean" means you are used to it. ELM is a totally new language (not like JS and TS) based on a paradigm (functional programming) that you are probably not used to. And it is based on the ML type system (different from what you are used to). So it is a lot of new things at once. "Reinventing the wheel" is an unfortunate side-effect of using a different way to do things. Some things can be copied verbatim, some are totally different. Check out "elm-ui" (https://package.elm-lang.org/packages/mdgriffith/elm-ui/latest/) for a very different and refreshing view in UI code in ELM (that will appeal to the mostly-backend developers in your workplace).

I use Elm for my project. Once you accept thinking the way it wants you to, it's a delight to develop front-end with it.

Side advantage, Elm-UI frees you from CSS: https://package.elm-lang.org/packages/mdgriffith/elm-ui/late... it's like Tailwind but deeply intertwined with the language.

https://elm-lang.org

The last advice I could give is to try elm-ui (https://github.com/mdgriffith/elm-ui) for your user interface. It's amazing how great that is compared to traditional ways of building a frontend layout.

The library elm-ui makes it easy to create a nice user interface. I am unaware of anything similar for Rust+WASM, so I would have been forced to deal with HTML and CSS.

There are several things named elm-ui. It's the author of a different library than what is usually understood when someone refers to elm-ui (which is https://package.elm-lang.org/packages/mdgriffith/elm-ui/late...)

Foregoing CSS all together by using a different approach to UI construction (elm-ui)

Right now I'm just using the built in from the UI library I used for the sake of ease as I didn't find a perfect solution and it seemed good enough for now: Github Link to source, which it looks like would classify your laptop as a tablet, whoops!

Keep in mind for the pipes, many in Elm, whether they’re using elm-format or not, will break the pipes to a different line in case there are many of them. For some, they find this more readable (I’m in that group). Let’s show an example of that using the same pattern to design a Paginator, the row of numbered buttons that allow you to move between pages of data.

9ᵗʰ - Aaron VonderHaar releases a new version of elm-format.

Unlike Javascript, Elm has an official Style Guide for how Elm code should be structured. In addition, some formatting is built into the language itself, such as requiring indents of four spaces. This removes a major point of contention within teams. In addition, the community has put together a wonderful tool called elm-format. Similar to Prettier, this utility can be used to ensure that all Elm code matches the official style guide. Unlike Prettier, there is no custom configuration, meaning once again that your team can focus on writing code instead of what kind of quotes to use.

Regarding user experience and tooling, I'd suggest you use an editor that is compatible with the elm language server: https://github.com/elm-tooling/elm-language-server VSCode is a good default choice. You'll also be interested in other toolings. elm-json (https://github.com/zwilias/elm-json) is great to simply install and uninstall dependencies. elm-format (https://github.com/avh4/elm-format) is a must since most active people in the community use it, and simply viewing your code being moved around on save is a good sign that you wrote something with a good syntax.

Take for example the debate about 2 vs 4 spaces. People often (but not always) have very strong opinions about this, yet it is clear that this formatting choice will probably not be the dominant factor in the success of a project. A quick google search also reveals no scientific research in this field. Concerning surveys, I found this interesting (from a survey on 2 vs 4 spaces in elm-format) as one datapoint: