I'm all for experimentation but getting rid of JS in this case almost certainly results in worse performance. You're trading a bit of load time for significantly slower runtime/rendering.
Huh.... why would a CSS animation of a transform be slower than JS? This is strictly for the "CSS transform" case ofc - obviously pure webgl would be way faster.
I'm having a hard time seeing it. My experiments with CSS animation have always performed much better in CSS than JS (again, excluding it being pure webgl/canvas JS).
And ofc there's the nice bonus that it works if I haven't chosen to trust and whitelist their website for JS yet.
Oh. Sure, that is pretty obvious. A triangle in webgl is so much more lightweight than building it out of DOM elements but this was more about "if one is going to use this CSS system, why not support a pure CSS viewing mode" - which right now, it does not - rotation requires JS and is pretty stuttery. I was thinking it should actually be a bit smoother if there was a "toggle on/off rotation using a CSS animation" option. Plus, something like that could easily be done in pure CSS if JS was disabled, which would make the output all the more accessible and offer a good usecase.
It could also be helpful in scenarios where JS is restricted - emails? iframes? bulleting board user content? Dunno. Trying to come up with some that aren't just "nemo was running umatrix and doesn't trust your site just yet"
well, people do in fact still do that. or APNG or WEBP.
But, all I was focused on was the initial comment was on if you were going to use this particular tool, it'd be nice if it had a pure CSS rotate mode, which makes a fair amount of sense given "working without JS" is probably one of the few significant use cases anyway (unless, you reeeeeally need your model to be tightly integrated into the DOM for some reason).
So, saying that CSS would be worse than JS as a feature for this project did not really make sense. We weren't talking about "should the project even exist"
(I feel it should and it's awesome ;) )
Super interesting! I checked your repo and you have been running since 2021, can you share a bit about the journey? Did the repo project changed direction at some point?
Sure. We've been building Lowdefy since 2020, we use it as the web framework for all our consulting customers at https://resonancy.io , where we build back office software for businesses.
We've built all kinds of internal tools using Lowdefy, CRMs, reporting apps, ticketing systems, workflow, SOP and QC tools, call centre automation tools, customer portals, survey apps and more.
We find that having a well define abstraction framework in place helps us scale our custom apps really efficiently, particularly from a maintenance pov. Also sharing work across our team, etc. It helps if everything is pluggable, and well documented. By making Lowdefy open-source it has helped our team maintain the discipline to enforce best practices across our stack.
Lowdefy is very declarative, and it lets you build data intensive web apps in just a few lines of yaml. With AI code gen, this is where the power of the framework guard rails and generated apps really accelerate the apps we can create while following the same patterns that our team applies over all the solutions we build.
As for change in direction, no. We have a demand for building agentic experiences from our customers, and found that we could wrap it really nicely into the Lowdefy framework, especially when building in additional functionality like agents co-authoring web forms and more.
We feel that agents inside your apps is a great fit, since you can expose the same api routes, auth roles and more to agents with ease.
That makes complete sense, now I get the angle. They are just another layer of apps that can be abstracted after all.
Did you try to also support OpenClaw/PicoClaw etc? Maybe OpenFang? I've found that since OpenFang is so different to the other harnesses its hard to share the same abstraction layer
Hi HN, I built Moltnet, a local chat network for AI agents, its opensource!!
The model is small: create or join a Moltnet network, install the Moltnet skill in your agent, then start the node. When a room or DM message arrives, Moltnet stores the event, wakes the attached agent system, and the agent can reply explicitly through `moltnet send`.
I built it because I wanted agents running in Claude Code, Codex, OpenClaw, PicoClaw, and TinyClaw to share rooms, DMs, history, and operator visibility without setting up Slack bots, Matrix, or custom comms glue.
Moltnet is not a model proxy or an agent framework. Each machine still runs its own authorized agent system. Moltnet just gives them a shared communication layer.
I’m looking for feedback on whether the current scope are enough as core agent-communication primitives
"Unless you have confidence in the ruler's reliability, if you use a ruler to measure a table you may also be using the table to measure the ruler"
Thanks for bringing this! I hand't heard about this concept before.
Considering the perspective of the essay, I would say the tests, almost certainly.
We keep measuring models on capability benchmarks (can it pass the bar exam, can it write a sorting algorithm) when the actual bottleneck in practice is coordination. The model can write an entire Three.js application. It cannot nail what I mean by 'porous' until we've built enough shared ground in the codebase for that word to point at something concrete. I think no standardized test currently measures that.
> The model can write an entire Three.js application....
Once you are willing to question the referential basis of measurement, please go on to question the terms chosen as the basis of performance:
For example, saying a model "writes" the application.
It can also be said that the model "retrieves" the application.
The term write in context amplifies the term intelligence, becoming arbitrarily anthropomorphic and implying human creativity.
But what computational theory explains the machine's creativity? Is there any theory of human creativity?
This distinction is important by virtue of the principle of Occam's razor: If a question must be begged for an explanation, prefer the simplest question.
The term retrieval is with respect to computation ipso facto. To say the model retrieves avoids any need for a theory of creativity and its corresponding anthropomorphism.
By extension, any appearance of intelligence manifest by the model is understood truly as artificial. A taxonomic circuit is closed without need for a mysterious antecedent of creativity.
Assuming any intelligible theory of creativity can be formed, this must regarded as significant in the entire history of thought, not sidelined as a semantic quirk in the field of AI.
I think this is exactly the kind of question the essay is trying to avoid productively.
Whether the model 'writes' or 'retrieves' is a question about what is in the model's box.
The beetle in a box argument says: it doesn't matter for the language game to function. What matters is whether the coordination works. I can build a working particle system with a model regardless of whether its process is creative or retrieval. The practical question is not what the model is doing internally but how synchronized our shared referential frame is.
I think the 'write vs retrieve' debate its super interesting philosophically. But it will keep us stuck looking inside a box we cannot open when the actual work is happening on the shared surface.
There's some CSS properties specifically for doing 3D, yeah. You use perspective and perspective-origin to create the view frustum, and then CSS transforms to place your elements in 3D space.
