Things I know
- reagent // This is just a wrapper around react.js
- re-frame
- Fulcro // It seems similar to re-frame with EQL.
- Hoplon (unmaintained)
- …
Things I know
Also, if you mean frontend web frameworks:
Why did you move away from clojurescript? I want to use clojurescript. I don’t see a significantly better langauge for web UI programming than clojurescript.
I also found
which looks like a promising platform-agnostic UI framework. I think I can mix it with react.js wrappers and reactive programming libraries like javelin.
Because he created Calcit, maybe?
JavaScript world is moving towards ES Modules and switching to Vite/wmr for speed, while ClojureScript is always trapped by JVM and Google Closure Compiler. That made ClojureScript too heavy for me.
I want to have higher order functions, immutable data by default, macros, polymorphism(some…), js interop, combined with ES Modules and fast startup time, I found calcit-js already enough for my usages.
ClojureScript is still cool in many ways. I’m struggling to copy several nice features of ClojureScript to calcit-js.
Dumdom is worth checking out:
GitHub - vitejs/vite: Next generation frontend tooling. It's fast! and GitHub - maxtaco/mwr: A script to release an npm repo and do all of the steps. don’t make javascript fast.
ES modules don’t necessarily make javascript fast.
I meant GitHub - preactjs/wmr: 👩🚀 The tiny all-in-one development tool for modern web apps.</titl , there was a typo in my previous reply.
noop. Vite and wmr are definitely JavaScript optimizer. However it always costs to bundle code before actually running it. What Vite and wmr did is, now you don’t have to spend so much CPU time on bundling.
updated:
some numbers of migrating one of my largest app migrated from shadow-cljs to calcit-js + webpack/vite. Building time on GitHub Actions.
shadow-cljs Merge pull request #1 from calcit-lang/fix-single-file · calcit-lang/editor@51e3757 · GitHub
client.js
and server.js
[:client] Build completed. (151 files, 110 compiled, 0 warnings, 26.88s)
page.js
and render index.html
, later removed/simplified in calcit-js version[:page] Build completed. (137 files, 136 compiled, 0 warnings, 9.62s)
calcit-js code starting running, but with a lot of runtime errors · calcit-lang/editor@1606791 · GitHub
took 393.734ms
Done in 0.85s.
took 509.138ms
Done in 0.97s.
index.html
and client.js
with ViteDone in 7.44s.
server.js
with Webpackwebpack 5.43.0 compiled successfully in 1323 ms
Done in 2.01s.
not a really fair comparison since calcit-js version dropped sepal and replaced some other libs with simpler solutions, but to me, it’s a lot faster.(could also be factors like shadow-cljs trying to check and even fetch packages during running…)
also some other examples of changes in building cost:
Among others approaches and frameworks, I would suggest estimating a server-side rendering approach via reagent (server) + htmx. https://htmx.org
I thought figwheel made it cheap to test clojurescript code during development. I was talking about runtime execution speed. I didn’t think about compilation/bundling speed.
no doubt that it’s fast in incremental compilation and js runtime after ClojureScript spent years on optimizing.
Reagent (perhaps with re-frame) is still a great, battle-tested, popular choice, likely the most popular one.
Depending on your needs, it might be worth experimenting with more simple and purposefully limited tools such as Helix (a minimal wrapper of modern React) or dumdom (thanks for the link, @greinseth !) or even more server-side solutions such as htmx or https://github.com/alekcz/pcp.
As the author of the Minimalist Fulcro Tutorial, I would argue that summarizing it like “re-frame with EQL” doesn’t fully capture its essence. Like re-frame it does manage state, so much is true, and unlike re-frame, it focuses on a graph API (via EQL) instead of REST. However it must also be noted that, contrary to re-frame, it is a full-stack solution (co-evolved with Pathom for the server-side), and a key design principle is the locality of decision (regarding data to fetch, routing, etc.) so that you do not need to hunt through a number of files and places when implementing a change - most often it is one edit on the frontend, possibly one on the backend. And it is batteries-included, with built-in, well integrated solutions for common needs of all non-trivial apps such as data loading (which might sound scary to DIY folks but is, in my experience, a delight and a considerable productivity boost). Also, somewhat uniquely, it has been designed with focus on “sustainable development” (i.e. doing everything possible so that the cost of development/maintenance does not skyrocket as the app’s size and age grow). Finally, there are goodies such as the Fulcro Rapid Application Development “addon”.
In Want more from your frontend framework! Re-thinking web dev experience (also as a video) I argue why a full-stack, batteries included framework that handles all the common needs (data loading, error handling, “loading…” indicator) is a better choice than starting from a slimmer solution and reinventing everything yourself, in a more laborious way. The article / talk is still a great demonstration of the value of something like Fulcro for any complex application, so perhaps check it out.
Have you tried hooking up re-frame or fulcro with javelin?
Javelin? What is it?
Ah, you mean https://github.com/hoplon/javelin I’m not sure it would be compatible with Fulcro and its state management. It’s think that the two for best different kinds of applications…
I think UIX is really good frontend framework which still under the radar.
This topic was automatically closed 182 days after the last reply. New replies are no longer allowed.