Clojurians Log v2
hyperfiddle
@dustingetz I am eagerly following your updates on reddit. Simple front-end crud developer here, and relative Clojure noob. But I am exited about the model. One concern. I have been using Hoplon http://hoplon.io/ , as it is small and arguably simpler than react.js bindings and skews closer to the general js-interop world. Your post mentions Hyperfiddle extension with Reagent, etc. I hope extending it with Hoplon as well might be trivial, and was wondering if you might be able to confirm this. Here are a few other links on Hoplon, if you are unfamiliar.
it is probably trivial. i'm in the middle of clean installing my macbook so i can't send you the entry point snippet you want to see. you'd lose out on free server side rendering and stuff,you'd need to implement integrations for that. should be trivial or at least straightforward
Hoplon is basically cljs functions as HTML nodes, Reactiveness through browser events and Javelin dataflow. It is server agnostic
hoplon is really cool; we went with react as a default for ecosystem reasons more than anything else
Cool! Just wanted some peace of mind that I could eventually take up Hyperfiddle and keep going with my Hoplon cljs brower-fu
Totally understant. React cljs stuff is definitely popular and well supported.
Thx for the quick response and consideration. Will be happy to beta test when the dust clears! 🙂
react has some super serious perf issues as well that have been quite painful for us and delayed our launch by quite some time. it's all sorted now, but hoplon potentially can help a lot with that
thanks for the ping!
The Hoplon guys are trying to clean up the documentation and address lingering performance concerns. This is new
Here's some quotes from the Hoplon Slack thread from the other day that may shed light on the contrast:
"I always ask people what does the structure of your application look like in memory? In the browser it’s the same as the structure of your HTML, so your code should look like your HTML, Hoplon is the only thing that does this IMO"
"I personally feel those libraries add bloat and additional layers of complexity which are not needed in most applications. I think the buzz around those libraries makes people overlook solutions which are simpler and designed in cljs.
"Hoplon is simple and powerful, but doesn't have a marketing juggernaut behind it. If anything, you might get tripped up by the eagerness of javelin cell evaluation but: javelin is technically not hoplon. It's pretty easy to work around eager evaluation thrashing the CPU using standard techniques like throttle/debounce, etc."
"The only problem with Hoplon - there are like 20 people total actively using it, but it’s small enough to actually read and understand the source code. Try that with React…"
"Simplicity is a great virtue but it requires hard work to achieve it and education to appreciate it. And to make matters worse: complexity sells better." - dijkstra
"I use my own non-ReactJS library and along with the common wisdom on React having superior performance being wrong the common wisdom on the CLJS frameworks wrapping ReactJS somehow becoming necessary when apps get “huge/complex” is also mistaken. In both cases it is just the opposite, because ReactJS is not at all reactive: it fakes it by re-running everything in a dumb fashion vs. having “point” information as to what property depends on what other properties (aka being truly reactive). So it reprocesses excessively (not a problem for trivial components, big problem once we scale because now we have to keep track of dependencies so we can tell React our vdom does not need to recalculate). Getting back to the elaborate frameworks wrapping React, again those again do not scale because we have to hand wire everything for the frameworks to follow."
Yeah, it's actually my understanding that Hoplon will be a lot faster than React (maybe not today, but the architecture fundamentals)
One thing Hyperfiddle does, is it evaluates the UI tree in the JVM in order to figure out data dependencies efficiently. You have to run the UI to know what data it depends on. Since React/Reagent components are mostly just functions, this isn't hard. But you end up wanting a "virtual dom" for your data dependencies, so the data dependency computation can just diff-since-last-time just like React, rather than re-evaluate the entire tree on the JVM
So Hoplon is probably the path forward for that - a reactive model that works for data structures, not coupled to the idea of dom
I misspoke a bit, its not just diffing, it's also reactions
on a big ol super nested hash map
Interesting. Hoplon uses Javelin https://github.com/hoplon/javelin for the reactive data dependency graph. It's by the same authors, but split into it's own library for composition's sake. Each node on the graph only recalculates when one of it's dependencies changes, so data-flows will propagate discretely, rather than the whole graph recalculating. So there is no diffing. I think under the hood there is a lot of (add-watch), triggered by (swap!) or (reset!) Javelin is officially .cljs only, but there are experimental .clj versions out there looking for a use case. This might be one.
Like you said, not coupled to the dom
yeah, that's exactly what hyperfiddle would need. it would need to be cljc since all of hf runs simultaneously in node/browser/jvm for perf reasons
probably a year out from something like that, but will eventually be very important. right now we can solve this problem with fat aws hardware