I am surprised this is not the norm, It looks like that this person have a tendency to lean into the extreme (like with his previous blog about chaining). I always feel like every syntactic sugar of any kind are to be treated like any other design/style philosophy. Too much of it is not good. Look at Java that is OOP to the extreme. Any language would quickly became unusable if any one of the features/design philosophy are (ab)used.

This might seem trivial, but it's a sign of mastery.

Thanks! Lotta good history in this writeup.

For Proxy specifically, that is how vue ref is actually implemented. By making a proxy so you get reactivity.

getOrInsert ≠ upsert, I don't understand how such a vocabulary confusion was let through

Thanks for the info.

I noticed that npm finally requires approval to run postinstall scripts: https://github.com/orgs/community/discussions/198547. Just noticed this when I was setting up a dev environment for my wife. Another good feature copied from pnpm :)

In pnpm you can override this. I don't think you can in npm.

How to install the library?

it isnt published to npm or anything else. there are a lot of details in the project that i dont think are refined enough to publish.

Readme says Zero Dependencies, but also says: Built on top of Lit.

some context on the approach: i originally wanted to create this as vanilla webcomponents. it turned out to be more difficult than i expected... in particular handling the rendering. so i used the render function from lit-html. instead of importing the render function from lit-html (a common practice), i decided to "pluck out" the render function and add it into my repo( because i only needed the render function)... and that way i can avoid lit as a dependency in the typical sense (in package.json). the render function is straight-up copied from lit and so its important to mention in the readme that its used (credit where due). i did it that way because my intention is still to work towards creating my own render function... its only going to take longer than i anticipated.

there is no "keep up with patches", this is far from finished and not stable enough for me to confidently advise anyone else to use. its open source, but not something i advise people actively use.

existing real-world apps

im integrating details like encryption-at-rest and bottom-up state-management into other projects like https://enkrypted.chat/ ... that project can be a whole separate conversation. its largely React. that is the project i would like to use dim to replace react. the project there is pretty complicated and i wont be able to replace react there any time soon.

SSR

my apps dont use SSR. there is emphesis in my project for them to use client-side functionality. i have thought about SSR, but its way at the bottom of my todo list.

Finally!!!

allowScripts defaults to off: npm install will no longer execute preinstall, install, or postinstall scripts from dependencies unless they are explicitly allowed in your project. This includes native node-gyp builds (i.e., a package with a binding.gyp and no explicit install script still gets blocked, because npm runs an implicit node-gyp rebuild for it). prepare scripts from git, file, and link dependencies are blocked the same way. To see what would be blocked, run npm approve-scripts --allow-scripts-pending. Then allow the packages you trust with npm approve-scripts and block the rest with npm deny-scripts. The resulting allowlist is written to package.json and should be committed. If your install routine runs scripts, you can observe warnings in npm 11.16.0+.

How to install the library? A search for @dim/core on npm returns no match.

Readme says Zero Dependencies, but also says: Built on top of Lit. Does this mean you maintain a fork of Lit? What are your changes compared to upstream, and is it difficult to keep up with its patches?

Are there existing real-world apps dogfooding Dim, in addition to the demos?

Do your projects that currently use React have SSR, and if yes, how are you going to reimplement it when you switch them to Dim?

The main argument, and it's a strong one, is: YAGNI (You Ain't Gonna Need It).

Compared to defining a function as synchronous (the default), there is a significant cost to defining a function to be async: Its signature is different, therefore every caller to that interface must also be aware the function is async; test cases must handle not just a simple return value, but a Promise; etc. etc.

So, don't impose that cost unless you already know it's needed, today. If you don't need it today, the most likely expectation is You Ain't Gonna Need It, at least not any time soon. So don't pay the cost now for something you likely won't get a benefit from.

What happened to one tool that does one thing well? If deno wanted to have HMR and all the good stuff the author mentioned, then Deno, with however much the maintainer count is, MUST prioritize and make compromise. But with every tool being a separate project, it is easier to make changes and to gather maintainer because of how broad range the tool application is compared to a single monolithic tool.

However, we do see a difference in Bun approach. It brings ALL the good stuff Deno does AND compatibility with Node from the get go. So the developer of course would flock there. Because the tooling works. Ironing out kinks of the tool is much easier than entirely severing compatibility in the name of progress.

Yeah, it's how software should be. Learn from other mistake. However, I'd also like to point out that I think it's better to focus on build system ergonomic rather than a package management ergonomic. Let git be the package repository and the build system be aware of git repo. That way I think it would solve a lot of supply chain issue being centralized

COBOL laughs maniacally in the background

What about if there's a patch for a CVE? Do you need to disable the config, update, then re-enable it, or is it possible to bypass per-project?

text-based browsers must be first-class
ad-hoc browsers must be first-class
the harder it is to haphazardly spin up a web browser, the more monopolistic it is

Can highly recommend Oxlint over ESLint. Runs faster, easier to configure, fewer dependencies. It's been a dream so far, really good.

Throwaway variables are an antipattern. Say what you will about Airbnb as a company, but their JS style guide is fucking dead on.

SonarQube can eat my whole asshole.

One reason you may not have known this is that these (iterator methods, not the Iterator itself) are newish additions to Javascript and only available in all the big browsers for just over 1 year.

You made me go down the rabbit hole with that question. TIL the very same methods exist on Iterator's prototype. They aren't eager, no.

You can get an iterator out of an array with Array.prototype[Symbol.iterator]() and you can collect an iterator into an array with Iterator.prototype.toArray().

Are they eager even with generators?

Ugh, SonarQube with the cognitive complexity check.

"Instead of having 50 lines where all logic is right here, I'mma need you to break it up into 10 separate functions so it's a massive pain in the ass to figure out what the fuck is going on"

I understand the reasoning but sometimes it's way more confusing to split up complex logic instead of just having it all in one place.

Only tangentially related, but I dislike that filter and map are eager in JS. Meaning if you chain them, you allocate N-1 arrays that are being discarded right away. C#, Java and Rust have the right approach.

I disagree with this article for the same reasons as everyone else.

I'll also add it's possible to add comments between each line of the pipeline.

I aslo use promise chaining as pipeline pattern for non-chainable calls, as described here : https://blog.kaki87.net/promise-based-pipe-in-js/