uhtml VS re-frame

I have to say that I am an extremist minimalist, so I use a nano-framework I developed for the frontend, with uhtml (https://github.com/WebReflection/uhtml) and some JavaScript libraries to help.

One of the main decisions I had to make early on was template handling, there are many approaches out there and of course, with React being the king, I first tried implementing a VirtualDOM complete with JSX support and whatnot... well that didn't really worked for what I was trying to achieve, so I moved into Tagged Template Literals (through µhtml) and tried to stick to standards as much as possible by building on top of the Custom Elements API.

FAST rendering thanks to µhtml

Challenge: With declarative rendering, oftentimes entire DOM trees are re-painted because of simple prop or state changes that could have been handled faster by imperative DOM manipulation. I wanted a framework that, like Lit, only updated content or attributes that had changed instead of re-painting entire DOM elements and trees. Solution: I chose µhtml for the default templating system because it accomplishes this goal and other advanced templating features in a tiny bundle size. To make rendering even faster and smoother, I throttled uhtml's rendering using requestAnimationFrame.

> There are lighter-weight shadow dom frameworks out there (than Vue/React/Angular) so why would you want to write one yourself?

You can even avoid a shadow DOM entirely:

https://github.com/WebReflection/domdiff

https://github.com/WebReflection/uhtml

My next goal would be to discard snabbdom (and virtualdom) and use custom elements. For that I'm evaluating a library like https://github.com/WebReflection/uhtml and all it's ecosystem of utility

Yep ditched React since 2015, it's still the same mess today. They all not trying to encourage interoperability, and comes with their own build .. seriously? Frontend should be just libs! Use https://github.com/WebReflection/uhtml or lit-html where things should be highly dynamic.

If it's for getting into job market, go for React. If it's for learning declarative ui, build cool stuff real quick without tooling, go with lit-html or bravely go with https://github.com/WebReflection/uhtml (it's more simple than anything else, yet powerful)

A tiny dom lib like https://github.com/WebReflection/uhtml is more than enough for very complicated UI, with understanding how events work, will be able to implement very thin state management on top. With game programming styled manual render() call here and there as needed, pretty neat.

This article always reminds me of this excerpt from re-frame’s docs [0]:

> Now, you think and design abstractly for a living, and that repetition will feel uncomfortable. It will call to you like a Siren: "refaaaaactoooor meeeee". "Maaaake it DRYYYY". So here's my tip: tie yourself to the mast and sail on. That repetition is good. It is serving a purpose. Just sail on.

[0]: https://github.com/day8/re-frame/blob/master/docs/correcting...

* Single-Page App: shadow-cljs for the build concerns (https://github.com/thheller/shadow-cljs), Reagent with Re-frame for complex/large app (https://reagent-project.github.io and https://github.com/day8/re-frame). Even if we now prefer using HTMX (https://htmx.org) and server-side rendering (Hiccup way of manipulating HTML is just amazing, https://github.com/weavejester/hiccup).

Big and/or complete projects that use re-frame The main list: https://github.com/day8/re-frame/blob/master/docs/External-Resources.md

Reflet is a set of tools for building Re-frame + React based web apps with graph and non-graph data models. This includes:

https://github.com/day8/re-frame

Notably the author of re-frame has been weary of hooks.

I think that’s for a good reason. The approach in re frame feels like the best way to manage state so far for a react based app. Everything that changes state flows through an event. State can only be observed through subscriptions. Side effects are isolated to their own type of event. Debugging and testing are so straight forward with these concepts.

Redux got close but it has two problems in my mind. Like hooks, it encapsulates for no good reason. Put the state in one thing that you can observe holistically before and after pure events. It also has too much boiler plate.

The cljs stack I hear about a lot (and use) is ShadowCLJS with reagent (https://reagent-project.github.io/) and re-frame (https://day8.github.io/re-frame/). ShadowCLJS is more of a build tool, but is really well documented and easy to use. Reagent is basically react but a simpler API, and re-frame is a layer on top of that provides data subscriptions and event-handlers to manage app state. It's overkill for some apps but I find it's actually super easy to work with and not as much complexity as I thought.

For backend there is luminus (https://luminusweb.com/) or Kit (https://kit-clj.github.io/). They are basically project templates that wire together a ton of popular solutions for various things - database access, migrations, security, html templating, etc. Also includes frontend frameworks like re-frame if you want.

Reflet aims to be a natural progression on top of Re-frame to support complex, data driven requirements. In that sense, it is both easy to learn, but powerful. You could say it's sort of like Re-frame++ (or Fulcro for Re-frame). Its main design goals are:

At my current client we're working on having a frontend architecture for writing SPAs in JavaScript similar to re-frame's one: an event-driven bus with effects and coeffects for state management[1] (commands) and subscriptions using reselect's selectors (queries).

Some of us had worked with effects and coeffects before while developing SPAs with re-frame and had experienced how good it is. After working with re-frame, when you come to horizon, you realize how a good architecture can make a dramatic difference in clarity, testability, understandability and easiness of change.

https://youtu.be/geeK1-jjlhY (talk about an initial prototype with re-frame and the decision to do a rewrite in Clojure)