dom-expressions
odoyle-rules
dom-expressions | odoyle-rules | |
---|---|---|
9 | 10 | |
828 | 514 | |
- | - | |
9.2 | 6.2 | |
11 days ago | 7 months ago | |
JavaScript | Clojure | |
MIT License | The Unlicense |
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.
dom-expressions
-
Resources for understanding the Solid compiler
The template core, which is in https://github.com/ryansolid/dom-expressions/tree/main/packages/dom-expressions This template core manages the DOM and SSR-related APIs that is usually hidden from the user. This core is also "cloned" into the SolidJS repo via Rollup.
-
The creator of Webpack introduces Turbopack, a Rust-based successor that's 700x faster
Revised my comment. However, I'm required to use Babel for: https://github.com/ryansolid/dom-expressions/tree/main/packages/babel-plugin-jsx-dom-expressions and a couple other small plugins.
-
Voby: Simplifications Over Solid - No Babel, No Compiler
Solid's transform seems fairly time consuming and difficult to maintain to me, though maybe it isn't, I'm not familiar with that code or with writing Babel transforms in general, you decide.
-
Exploring Frontend Frameworks' Internals – Part 1: The basic structure of Frontend frameworks + Vue 3’s reactivity
vuerx-jsx is using Vue's reactivity system (@vue/reactivity) with Solid's DOM renderer. Both offer blazingly fast performance, (much) faster than their original usage.
-
Show HN: I made React with a faster Virtual DOM
Solid is great, you can also use it with hyper dom expressions: https://github.com/ryansolid/dom-expressions
- UIs Are Streaming Dags
- How to Rapidly Improve at Any Programming Language
- A few reasons why I love Solid.js
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.
What are some alternatives?
solid-start - SolidStart, the Solid app framework
pararules - A Nim rules engine
solidjs - A tiny (200 bytes) connector for Storeon and Solid.js
paranim_examples
solid-styled-jsx - A Styled JSX wrapper for Solid
asami - A flexible graph store, written in Clojure
Stacktribution - A tiny webapp to generate proper attribution to a Stack Overflow's answer.
posh - A luxuriously simple and powerful way to make front-ends with DataScript and Reagent in Clojure.
solid-styled-components - A 1kb Styled Components library for Solid
spork - Spoon's Operations Research Kit
open_safety - An application to assist with securing script execution
missionary - A functional effect and streaming system for Clojure/Script