core.async VS elm-ui

Hey, how you doing? This article was written right after I had to painstakingly read the clojure.core.async source code in order to finish a task. So, I hope I save you from the same fate as I had 😄.

It was created by Rich Hickey: https://github.com/clojure/core.async/commit/47b1d24c0291050a1188dbeee2fc9227f694eb3c don't think he's disavowed it lol.

Some time ago we developed some helpers using the capturing notifications strategy to test asynchronous ClojureScript code that was using core.async channels. Have a look at, for instance, the expect-async-message assertion helper in which we use core.async/alts! and core.async/timeout to implement this behaviour. The core.async/alts! function selects the first channel that responds. If that channel is the one the test code was observing we assert that the received message is what we expected. If the channel that responds first is the one generated by core.async/timeout we fail the test. We mentioned these async-test-tools in previous post: Testing Om components with cljs-react-test.

Hi there I'm using Clojure almost a year. I've played with both Manifold and core.async a bit but I'm not %100 sure when to use core.async over Manifold or vice versa.

If you're not familiar with lisps in general, it might be hard to grok the differences between lisp-macros (as used in Clojure) and "normal" macros you see in other languages.

But, if you are familiar already, and just wanna see examples of neat macros that makes the API nicer than what a function could provide, here are a few:

- https://github.com/clojure/core.async/blob/master/examples/w...

- https://github.com/weavejester/compojure

- https://github.com/ptaoussanis/timbre

- https://github.com/krisajenkins/yesql

https://github.com/clojure/core.async

> and with a very poor tooling (lack of IDE's)

Lisps have fantastic support in Emacs and VSCode and are in general simple enough languages that often the heavyweight of an IDE is not needed. But if you want IDEs there are:

If you don't want to block the current thread, you can do the looking/waiting on another thread via thread or in a go using alts! .

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!