Congrats brother!! Anyone can use it without much knowledge?
Show HN: Aberdeen – An elegant approach to reactive UIs
111–120 of 138 posts
Re: Show HN: Aberdeen – An elegant approach to reactive UIs
#112It looks influenced by JQuery
Re: Show HN: Aberdeen – An elegant approach to reactive UIs
#113Earlier quoted context omitted.
I just read the signals proposal and was not impressed. There is a lot group thought in JavaScript, in Java too but more in JavaScript, around standardizing convenience based upon knowingly bad decisions from convenience abstractions. Managing and updating the DOM is stupid simple and that simplicity has nothing to do with state, which a fully separate yet equally simplistic concern. That is something UI frameworks m…
examples?
Examples of what? Do you mean examples of not using React?
Re: Show HN: Aberdeen – An elegant approach to reactive UIs
#114Congratulations on the launch!
Have you considered any sort of templating like htm or JSX? Because it's a bit harder to read and I believe to work in a team it would be much simpler if there was a template syntax.
Re: Show HN: Aberdeen – An elegant approach to reactive UIs
#115this is pretty cool actually. i remember 10 years ago when I used react but in coffeescript and without the ugly jsx and just renamed the "createComponent" function to "h". this kinda feels like that but upgraded with the signals state
Re: Show HN: Aberdeen – An elegant approach to reactive UIs
#116Congrats for reaching 1.0! Nice little library, but as it's signals based, it would be nice to make it compatible with the signals proposal ( https://github.com/tc39/proposal-signals ) At the same time for me, while it's super nice, in my opinion it just doesn't differentiate enough from other signals based frameworks to get mass adopted / make CRUD apps that much easier to make. The problem with remote server/databa…
> Nice little library, but as it's signals based
How do you reach that conclusion? There is nothing mentioning signals in the docs anywhere.
Re: Show HN: Aberdeen – An elegant approach to reactive UIs
#117Congrats for reaching 1.0! Nice little library, but as it's signals based, it would be nice to make it compatible with the signals proposal ( https://github.com/tc39/proposal-signals ) At the same time for me, while it's super nice, in my opinion it just doesn't differentiate enough from other signals based frameworks to get mass adopted / make CRUD apps that much easier to make. The problem with remote server/databa…
> Nice little library, but as it's signals based, it would be nice to make it compatible with the signals proposal ( https://github.com/tc39/proposal-signals ) Based on the current proposals, it seems that a signal can only contain a single atomic value, for which changes can be tracked. Aberdeen's `proxy` can efficiently wrap complex data structures (objects within arrays within objects, etc), tracking changes on th…
Aberdeen's proxy is essentially an object of nested signals. In general:
proxy({
name: "Foo",
email: "bar",
});
new Signal({
name: new Signal("Foo"),
email: new Signal("bar"),
});
Aberdeen looks like it's taking Vue's approach of making the proxy/automatically nested case the default, which is typically more convenient as nested reactivity is the thing that makes signals really sing. But it's still just signals, and the same behaviour can always be replicated using manually nested atomic signals.
EDIT: I've just realised you're OP, so you probably know more about your reactivity system than I do! But at least the way you're describing it, it sounds like it's working the same way as signals do, just with an emphasis on the nested signal case by default.
Re: Show HN: Aberdeen – An elegant approach to reactive UIs
#118Congrats for reaching 1.0! Nice little library, but as it's signals based, it would be nice to make it compatible with the signals proposal ( https://github.com/tc39/proposal-signals ) At the same time for me, while it's super nice, in my opinion it just doesn't differentiate enough from other signals based frameworks to get mass adopted / make CRUD apps that much easier to make. The problem with remote server/databa…
> Nice little library, but as it's signals based How do you reach that conclusion? There is nothing mentioning signals in the docs anywhere.
The proxy object is a fairly classic way of doing signals (see Vue, SolidJS), and the whole thing about functions rerunning whenever data that was accessed inside that function changes is pretty much the definition of signals.
It looks like the author is trying to avoid making direct comparisons with signals and existing signal frameworks, which makes sense - depending on your target audience, it can be a bit "inside baseball" - but it's definitely using some sort of signals-like mechanism under the hood.
Re: Show HN: Aberdeen – An elegant approach to reactive UIs
#119Congrats on making it to V1! Though not immediately obvious, there's a lot of parallels to be drawn between this and solid.js (proxy is a sort of `signal` right?, no virtual dom) - I'd be curious what you'd say are the primary benefits of this library over something like Solid.js? I gotta turn a little negative here... Off the bat, regarding the first point in the "Why use Aberdeen?" section, I have a few nit-picks:…
Thanks! Yes, there's some similarity to Solid.js, but also two big differences: 1. A Solid.js signal contains a single atomic value that can be subscribed to, while an Aberdeen proxy can wrap around a complex object (containing arrays containing objects, etc), and subscribe to only the primitive values that were read. 2. If I understand correctly, Solid.js can only redraw entire components (which may not be great at…
Hello, congrats on the release of your framework! I myself also wrote a reactive library for my own projects long ago when jquery was still widely used.
Anyways, these days I moved from React to Solid.js so I know a bit how Solid works.
1. Solid.js also has "stores" and "createMutable" which allow deep tracking of objects and are also built on Proxy objects. Signals are great for single values, but Solid stores and createMutable are for more complex data.
2. Solid.js doesn't redraw entire components. (It's not like React.) It is fine grained and only updates the minimal exact DOM nodes required. This is why it is so fast and topped benchmarks when it first came out. https://dev.to/ryansolid/introducing-the-solidjs-ui-library-...
I found https://blog.theodo.com/2023/07/solidjs-beginner-virtual-dom... which might be a good intro explanation to it.
> Yeah, until you want to add some loops and conditionals in there. That's what regular programming languages are really good at. But it's a trade-off for sure.
Solid's and and tags are actually quite nice and very easy to parse visually.
Regarding the "gaslighting" comments, I kind of feel the same way as the grandparent. No offense meant and I support everyone coding new open source frameworks, but it does kind of feel like that.
I suggest doing a deep dive into Solid and even checking Ryan's blog https://dev.to/ryansolid or YouTube channel. There are a ton of concepts and good ideas to learn. He and tanstack are like at the forefront of web dev today.
Re: Show HN: Aberdeen – An elegant approach to reactive UIs
#120Congrats on making it to V1! Though not immediately obvious, there's a lot of parallels to be drawn between this and solid.js (proxy is a sort of `signal` right?, no virtual dom) - I'd be curious what you'd say are the primary benefits of this library over something like Solid.js? I gotta turn a little negative here... Off the bat, regarding the first point in the "Why use Aberdeen?" section, I have a few nit-picks:…
Thanks! Yes, there's some similarity to Solid.js, but also two big differences: 1. A Solid.js signal contains a single atomic value that can be subscribed to, while an Aberdeen proxy can wrap around a complex object (containing arrays containing objects, etc), and subscribe to only the primitive values that were read. 2. If I understand correctly, Solid.js can only redraw entire components (which may not be great at…
Re 1, SolidJS also has a `createStore` primitive which works the same as your $proxy. That said, based on your other comment that I relied to, it sounds like your internal signals implementation is based on the nested, mutable object case, which is fascinating - I believe most other signals implementations go the other way round, starting with atomic signals and then nesting them to create fine-grained reactivity.
Re 2, no SolidJS works basically the same as this. For example, in SolidJS,
my name is {name()}
const el = _render("...");
const textNode = el.children[1];
createEffect(() => {
textNode.nodeValue = name();
});
Aberdeen looks like it should be able to do something similar like
$("div", ":my name is", () => name)
I do like this as a no-build alternative to SolidJS, and I think the syntax works really well for creating mini templates. I can imagine this being great for dropping in little components on traditional server-rendered, mostly static pages - no need for a large library, just something providing the bare essentials in a clean way.
You mentioned somewhere that in benchmarks, this seemed to be running at around React performance (albeit a lot more lightweight). I suspect you can get a lot more performance by fiddling with the signals implementation. It might even be worth pulling in an existing signals library as a single dependency, or at least exploring how some of the more performant ones are implemented and taking those ideas. Especially as things get more complicated and you end up with more nested `observe`s, getting that to work efficiently is going to be difficult.