odoyle-rules
electric
odoyle-rules | electric | |
---|---|---|
10 | 24 | |
517 | 1,638 | |
- | 2.0% | |
6.2 | 9.2 | |
7 months ago | 10 days ago | |
Clojure | Clojure | |
The Unlicense | Eclipse Public License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
odoyle-rules
-
Use of Posh for frontend development?
If you're going down this route I'd second the recommendation for O'Doyle Rules. (Haven't used it since I switched away from SPAs altogether, but when I was investigating stuff in that space, O'Doyle appeared to be taking the "correct approach" from what I could tell.)
-
[Blog] The Web Before Teatime
That's what this tiny library does https://github.com/oakes/odoyle-rules
- [ANN] odoyle-rules 1.0.0
-
Ideas for DataScript 2
Reactive updates is the big one, in my opinion. DataScript is a triumph and arguably is the reason why so many note-taking tools (Roam, Athens, Logseq, etc) are written in Clojure. But there are so many cases where it would be nice to react when some set of entities is changed.
I think what we need is to figure out how to combine DataScript with a rules engine. I'm wrote a rules engine and made a writeup that compares the two together: "Using O'Doyle Rules as a poor man's DataScript" https://github.com/oakes/odoyle-rules/blob/master/bench-src/...
Subscribing to individual entities is nice but with a rules engine you have so much more fine-grained control over your reactions. And with the RETE algorithm this can be done efficiently. Most libraries in this space just ignore it and make their own ad-hoc solution -- an informally-specified, bug-ridden, slow implementation of half of a rules engine.
- UIs Are Streaming Dags
-
Datalog for HTTP APIs
Odoyle-rules lets you write rules (forwards chaining) engine that you can run on client and server. There are a couple ways you can twist that idea to achieve a more unified system.
-
Next Web
I suspect it'd be too much of a mismatch to be useful, but i haven't thought about it enough. I think a more promising idea is to try implementing a database with o'doyle. I wrote about my first attempt here: Using O'Doyle Rules as a poor man's DataScript Right now it would be too inefficient for large data sets because it has to constantly rebuild its index but i think with some small changes i could improve that and basically turn o'doyle into a tool for creating databases that come with reactivity for free.
-
O'Doyle Rules - a Clojure rules engine for the best of us
No doubt there's a runtime cost in joining the facts together, so naturally a system that lumps facts together into records (like clara) will have to do fewer joins, and should be faster. I figured out that i could at least deduplicate my joins with derived facts as i explained here, which ended up being a really big perf boost. But there's still a tradeoff, and one where almost everyone should favor flexibility, i think.
electric
-
LiveView Is Best with Svelte
The cleanest way to handle the backend and frontend charade I've seen until now is using https://github.com/hyperfiddle/electric which is a clojure DSL on top of react
-
Imba – The friendly full-stack language
Opa was ahead of its time by at least 10 years. Have you seen Electric Clojure [0]?
[0] https://github.com/hyperfiddle/electric
- Htmx is part of the GitHub Accelerator
- London Clojurians talk: Electric Clojure — compiler managed datasync for rich web apps
-
Should all Clojure functions be polymorphic by default?
Scala's ZIO/ZLayer is a great implementation of this idea where the monadic types are visible to userland DSL. Electric Clojure (which I lead) is a Clojure implementation of similar ideas (specialized to web development) where the types are concealed, "just write Clojure". In practice with Electric, we are building really complex/dynamic abstractions (think pure functional app-builder and highly concurrent UI) and we haven't even felt a need to implement multimethods yet. https://github.com/hyperfiddle/electric
- Isomorphic Development
- Humble Chronicles: Managing State with Signals
-
Use of Posh for frontend development?
I'd expect your auth stuff to mostly just work with some minor jiggling of the middlewares. We have a few out of the box approaches to routing, the tutorials app uses hyperfiddle.router which is an experimental composable router (may be a bit hard to use), the easiest starting point would be a simple goog.history integration. Someone posted a retit integration in the slack iirc. And you can of course roll your own.
-
lumberdev/tesserae: A Clojure spreadsheet and more!
Built with Electric Clojure and Missionary! https://github.com/hyperfiddle/electric
What are some alternatives?
pararules - A Nim rules engine
fulcro - A library for development of single-page full-stack web applications in clj/cljs
paranim_examples
hoplon - Simple and powerful tool for building web apps out of highly composable elements in ClojureScript.
asami - A flexible graph store, written in Clojure
posh - A luxuriously simple and powerful way to make front-ends with DataScript and Reagent in Clojure.
helix - A simple, easy to use library for React development in ClojureScript.
spork - Spoon's Operations Research Kit
subscriptions - A subscriptions library over a source of data (forked + extracted from re-frame)
missionary - A functional effect and streaming system for Clojure/Script
Scoop - A command-line installer for Windows.