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.
I wish all Chromium forks would band together to maintain a base that supports Manifest V2, it shouldn't be that difficult to each chip in some funding.
VSCode is still a very competitive text editor even without its proprietary plugins.
Ootb VSCode is already a superior experience to Emacs, which I only begrudgingly move away from because of subpar TypeScript + JSX support like 6 years ago. However, after I started using VSCode for work there was just no going back. I use VSCode a lot for text manipulations. I find its regex search replace much easier than using sed in the terminal. Multiple cursors, Git integration, beautiful diffs, command palette is just like Emacs M-x.
Without its proprietary plugins it's still a great gift to the public and forks like Cursor is a good showcase of that. Thanks to monaco almost every web editor nowaways have great usability, syntax highlighting and the keybindings that I'm familiar with.
I think the bigger joke of the century are open source beneficiaries that only take and give nothing back, but still have the audacity to demand for things and hound open source developers to implement what they want. You can't have your cake and eat it too
I'm Malaysian. They even messed up DoH for the popular DNS providers like Google and Cloudflare. I think they are routing 1.1.1.1 to their own DNS, so when you try to connect to DoH you get SSL_ERR_BAD_CERT_DOMAIN. The only option it seems is to VPN or play the cat and mouse game now to find a DNS that hasn't been rerouted yet
"Democracy" is a bit of a red herring here. Democracy doesn't mean the government can't censor you or restrict what information or media you can consume. Democracy just means that the voters have consented to whatever legal framework is in place, and to whatever their leaders want to do within that framework.
And that's the thing: in many democracies around the world, if there was a referendum on the law to blocking copyright infringement, online gambling, or pornography at the ISP level, I think many would pass that law.
(Certainly there are "democracies" out there that only pay lip service to the concept, and have fixed elections and repression of dissent or opposition. I'm not talking about those.)
Sarawak here (on unifi). My network uses self setup multi DNS path with enforcing encryption so no biggie but I tried some nonetheless. Quad 8, 1 are fine atm, while Quad 9 traceroute returned !X.
router DNS redir to pihole(Not the shitey FiberHome) -> pihole to internal(bind9 plain local to Adguard Proxy DoQ) -> self hosted tunneled whitelist DNS quicdoq DoQ, Adguard DNS DoQ (upstream quad 101, others.)
I have a similar setup, it will not be immune if they start implementing in your area. They were rolling out by areas before they reversed course. Your upstream will stop working unless you proxy it through another network
It's between ChatGPT being on there or something else like Claude... OpenAI cannot afford to let the masses know there is something out there that is just as good
if you are at a stage where this matters you will not be using Array.shift or even Array for that matter. JavaScript has lower level facilities for this.
