I’d actually love to see something that goes in the opposite direction, highly optimized and compiled, where the result is as small, fast, and efficient as possible. I get that a lot of people dislike compilation, but once I have the CI set upI never found build steps to be a problem for me.
Some time ago while I was experimenting with writing Debian benchmarks[0], I found that by completely avoiding strings, using Uint8Arrays, and manually managing bounds/memory, I could squeeze out performance that almost made you forget you were writing JavaScript. I never ended up submitting a PR, but it was pretty eye-opening.
At one point I went into a rabbit hole and tried to build something similar on my own, but it got complicated very quickly given my limited compiler knowledge. That’s why I always thought Prepack[1] was such a cool idea.
Isn't that what Svelte was aiming to do? It's moved on a ways since then, but you can still see the fundamentals in its demos: https://svelte.dev/playground/hello-world
That’s a good comparison — Svelte also started from the “write less, ship less” idea, and I have a lot of respect for it.
The big difference is that Svelte achieves that by compiling away the framework, whereas Dagger.js avoids compilation entirely. You don’t install a CLI, you don’t run a build — you literally drop a <script> from a CDN and wire up directives in plain HTML. It’s closer to Alpine/htmx in that sense, but with a focus on working alongside Web Components.
So in spirit, yes — both try to reduce overhead. Svelte optimizes post-build output; Dagger.js tries to remove the build step altogether.
Thanks for your comment.That's right — the compiled/optimized end of the spectrum is powerful, and I think Prepack showed just how far you can push that. However, dagger.js is intentionally the opposite: it trades the simplest usage for zero build, instant setup. My focus is “drop in a <script> and go,” not competing with compiler-driven stacks. In practice I see them as complementary — one for squeezing every byte/cycle, the other for minimizing friction and complexity.
> I’d actually love to see something that goes in the opposite direction, highly optimized and compiled, where the result is as small, fast, and efficient as possible
Right, but that is what basically every JS framework is going for these days. Its refreshing to see somebody trying to go back to old school non-compiled js/html where every front-end is open-source(ish)
Really appreciate that. The “old school” vibe is deliberate — I wanted to lower the barrier so that you can share a snippet or inspect a page and actually learn from it, the way we used to with plain HTML/JS. Frameworks are great, but sometimes it’s nice to have a path that prioritizes openness and simplicity over machinery.
I’m in a similar boat like you. I would love for a React-like library that compiles down to direct JavaScript DOM transforms. Of course Svelte exists but I don’t want to mark what is reactive or not and I can’t go back to html templates after using typed JSX. Also I don’t really like the “island” like template syntax of Vue, Svelte, etc
Solid is definitely in that “compile-to-direct-DOM” camp, and I think it’s awesome — it shows how far you can push the reactive model with JSX + fine-grained updates.
dagger.js is coming from the opposite direction: no compiler, no JSX, and also no signals. just plain HTML with attributes like +click / +load. You drop in a <script> from a CDN and it wires up behavior at runtime. It’s more about zero build friction and “view-source-ability”than squeezing out maximum perf.
So if Solid is about compiling React-like ergonomics down to efficient DOM transforms, dagger is about skipping compilation entirely and letting you glue components together with HTML. Two very different trade-offs, but complementary ends of the spectrum.
Thanks for your comment. — typed JSX ergonomics are really nice, and most compile-time frameworks today make you choose between that and some sort of template DSL.
However, dagger.js takes a different angle: it doesn’t try to be “React-like compiled,” it tries to be no-compile at all. State is just plain JS, DOM transforms happen directly via attributes (+click, +load, etc.), and everything is HTML you can literally view-source.
So it’s not competing with React/Svelte on compile sophistication — it’s aiming to be the lightweight “glue” around whatever components you like, while keeping the HTML open and approachable.
I really hope you will try using dagger.js and come back to tell me how you feel about it.
Thanks!
I also meant more advanced optimizations beyond what svelte does, like: inlining, loop unrolling, partial evaluation that would trickle down to the frameworks as well. I am aware that some of these and others are very hard to do on javascript as prepack shows.
Yeah, totally — once you start talking about inlining, loop unrolling, partial evaluation, you’re basically in compiler-research territory. Prepack showed both the promise and the difficulty of doing that well in JavaScript.
dagger.js isn’t trying to chase those kinds of deep compile-time optimizations. Its focus is the opposite trade-off: keep things build-free, HTML-first, and easy to drop into a page. I’d rather leave the heavy lifting to whatever compiler or bundler someone pairs it with, and make sure the runtime layer stays simple and transparent.
So in my mind these approaches complement each other: advanced compilers make large apps faster; Dagger tries to make small apps and prototypes friction-less.
From what I know it can't be "rotated losslessly" in all cases, only if the dimensions of the images are multiples of the MCU which are block of pixels whose size is determined by the chroma subsampling. Ex.: With the common "4:2:0" subsampling the MCU is 16x16 the image's height and width must be exactly multiples of 16, otherwise I think it's just visually lossless and uses some tricks that I'm still not sure how they work.
Unpopular opinion: I think I’m going to wait for version 4 /jk. But honestly, I’ve been spoiled by modern languages like Rust, Go, and even TypeScript with modern tooling, strong typing, stability, and performance out of the box. Right now, I’m just interacting with LLMs, not building them.
That said, I remember writing myself a note a few years ago to avoid Python projects. I had to clean up code from all over the company and make it ready for production. Everyone had their own Python version, dependencies missing from requirements.txt, three way conflicts between 2 dependencies and the python version, wildly different styles, and a habit of pulling in as many libraries as possible [1]. Even recalling those memories makes my stomach turn.
I believe constraints make a project shine and be maintainable. I'd prefer if you throw at me a real python instead of a python project.
[1] Yes, I'm aware of containers, I was the unlucky guy writing them.
Much more capable and reliable type system, paired with comparatively sane package management. This is getting better in the Python world (thank you Astral), but it's still not anywhere near the same.
I was thinking about buying an incinerator, I recycle my trash but recently found that everything gets mixed back together in the end by the privatized trash company and no recycling happens.
I have a bottle of soap that has this actual notice on the back:
"This bottle, after pump is removed and discarded in garbage, may be collected in your local community, but actual recycling rates in the USA are currently very low."
I really dislike when people don't see this. They try to cut 10 grams of CO2 per day while other industries (shipping, aviation, rails) produce hundreds of tons per day and even this transportation modes are less that 20% with most CO2 produced mainly being in energy production and used by industry.
Plastic bags and papers straws is not about CO2 emissions and I wish people would stop repeating this like it's some "gotcha", it's about landfill and natural area pollution and damage to wildlife and natural areas, and that's how it's always been talked about by policy people who have advocated on this stuff.
This makes sense and I'm with you, people that are polluting beaches and natural areas should face harder punishments. That being said I'm missing plastic straws for drinking cold coffee.
Nothing stopping you from carrying your own reusable straw around with you.
Finally, most of the (local, not even thinking about the developing world) pollution is not deliberate. It blows in from other places, usually. I live rural and I'm continually picking up plastic garbage from my ditch or back forest or fields that blows in from the nearby highway and roads, especially after garbage pickup day.
Rituals define a school of thought (or a religion). These are rituals of folks who want to prevent catastrophe through conservation. To each their own.
Ultimately, individual habits do add up. But with climate, one would be hard pressed to find evidence that conservation is the path forward. It does not work, unfortunately.
That's exactly how I started using them as well. 1. Give it just enough context, the assumptions that hold and the goal. 2. Review answer and iterate on the initial prompt. It is also the economical way to use them. I've been burned one too many times by using agents (they just spin and spin, burn 30 dollars for one prompt and either mess the code base or converge on the previous code written ).
I also feel the need to caution others that by letting the AI write lots of code in your project it makes it harder to advance it, evolve it and just move on with confidence (code you didn't think about and write it doesn't stick as well into your memory).
I think at some point the number of tabs doesn't matter because the tab is unloaded and the state is maybe stored on disk. As long as you don't open them, having them open shouldn't slow the browser down.
Nope, not yet. I tried that 3 times, once for my mac, then for my linux and once for a project. Every time I gave it a solid try found it lacking so I made a note to wait a few more years. The promise of reproducible systems is so hard to resist but nix brings crazy complexity (not all of it necessary), I'd prefer a system where their package repo has 4 packages but it makes it easy enough to me to bring other packages.
Writing nix is like writing functions but in order to remember the arguments and fields of those arguments in another file that you can only access through your browser. Look at any nix file, and tell me where each variable is coming from.
I have tried NixOS and the out of the box experience isn't bad, neither on my main VM nor my notebook. Everybody points you to flakes and flakes point you do use the unstable branch of nixos and that is where I say no. Then you learn a bunch of things along the way like upgrading replaces your stuff and you have to start again.
I've moved to Atomic desktops and can't name anything I am missing. For dev stuff there are containers.
Flakes and the unstable branch of NixOS (the `nixos-unstable` branch of Nixpkgs) are unrelated.
Flakes is an "experimental feature" of Nix itself, but it has shipped in stable releases of Nix for years now. There was a time when you had to build an unreleased version of Nix to play with flakes but that was a long time ago.
Whether you use a rolling release for the package set, e.g., nixos-unstable or nixpkgs-unstable, is orthogonal to whether or not you use flakes.
Fwiw, I generally prefer to run the unstable branches of Nixpkgs. Occasionally you hit something you have an opportunity to fix yourself, but that's not very frequent these days, even on the unstable branches.
Yeah I think this is a big flaw of declarative systems. I see a Nix derivation that contains `foo: bar`. How do I know what this does? It's pretty much impossible to know without learning all of Nix, because anything can access it.
If it was a function call you could just go-to-definition.
Environment variables have a similar issue. It's often hard to know what they do because they could be used by basically anything at any time.
Yeah I think you can definitely find which process sets environment variables (I think you just need to intercept execve or whatever). The real problem is finding which processes use the environment variables. That's extremely difficult, if not impossible.
Right. Iirc the environment is put on the stack of a new process shortly after. Though I'd want to do this from very early on and then track how the environment changes. I thought of ftrace because it can be enabled/configured in a kernel parameter and as such will already capture information shortly after boot. But maybe it would be easier to work with ebpf or ptrace.
Its not that practical. I cr#ated a nix file to roll a new jellyfinmediaplayer client in nix and it worked until s(me update broke it but the audio and a few other things needed finding obscure nonsense and specifying it to work passably. Its been replaced by fi e sentences remnding me what to click installing bazzite and it works rock solid for very mnimal additiobal setup time
Some time ago while I was experimenting with writing Debian benchmarks[0], I found that by completely avoiding strings, using Uint8Arrays, and manually managing bounds/memory, I could squeeze out performance that almost made you forget you were writing JavaScript. I never ended up submitting a PR, but it was pretty eye-opening.
At one point I went into a rabbit hole and tried to build something similar on my own, but it got complicated very quickly given my limited compiler knowledge. That’s why I always thought Prepack[1] was such a cool idea.
[0] https://benchmarksgame-team.pages.debian.net/benchmarksgame/... [1] https://github.com/facebookarchive/prepack