WorldMaker

namespaces are the other one, and that's a fun legacy because Typescript had to implement a half dozen module systems in the early days: no modules (jQuery-era globalThis pollution), AMD, UMD, CommonJS, SystemJS, Typescript's own which was proto-ESM inspired but not ESM, then Typescript's realignment with ESM.

Something of its own sign of Microsoft out-engineering some of the hiccups of the ecosystem as a whole. (I started using Typescript < 1 simply because it was the safest and easiest way to write AMD modules also with an eye to UMD or SystemJS output with just a compiler flag change if you needed to ship something compatible outside the house.)

I'd throw out webpack and start with unbundled ESM today. Vendor bundle and spot bundle with esbuild or rollup or something else designed for native ESM bundling and just ESM bundling, and only where you see actual performance bottlenecks (visible request waterfalls). Use any friction you see as an excuse to replace/drop old CommonJS dependencies entirely.

Webpack had its day, but today its kitchen sink and incredibly baroque configurations are as much a liability as a helpful place to start on a project. Start fresh with ESM and without a bundler and things are surprisingly nice in development experience.

Bun's being a part of Anthropic is just as concerning, if not more so. At least Cloudflare is being honest here that they have no idea continuing Deno support long term. Anthropic's first role in Bun was treating it as a playground to migrate from Zig to Rust using as many LLM tokens as they wished in the process. That's not exactly the sign of a steward with long term maintenance in mind.

It probably does get that advantage that it has had fewer supply chain attacks than npm.

I liked its scoring system for packages and "make the Typescript docs a public part of the package page" and "focus entirely on ESM-first/ESM-only packages". None of that npm does today, so JSR is still the best way I know to find modern and up-to-date/clean packages versus npm just has a nasty swamp of things still in CommonJS for no reason or that will never get upgraded out of CommonJS because the original maintainers are long gone.

US level anti-trust laws don't touch on a lot of anti-competitive behavior, mostly specifically it almost solely concerns just trusts and monopolies. I don't think I've heard of a court case ever before simply on the death of a product.

But also US anti-trust laws at the federal level have always relied on a strong FCC, FTC, and US Attorney General's Office to execute, all of which are currently neutered and/or understaffed under the current administration (and may take years to recover even in the best case scenarios). The US has decided it is a season for trusts and monopolies.

(See the mergers of Paramount and WB into Skydance consolidating 200+ combined years of movie history into a single monopoly under the Oracle nepobaby and almost directly undoing/mocking one of the largest and oldest anti-trust cases which was US v. Paramount Studios which set precedents for how large a movie studio could grow that lasted almost 100 years.)

(There might be something the state of California could do, but I don't know how much they want to get involved.)

Which also leads to considerable questions about if the thing being shut down in the acquirehire was the real purpose and any momentum of the team itself moving to new projects a bonus.

And with a ROM that had to be hand sewn. No flash updates, just "little old ladies" working in a former bra factory for a defense contractor (and huge tax payer expense if any mistakes needed to be debugged).

Scoped styles hasn't been an issue for me, but I understand why a lot of people want them.

My own library wasn't designed with Web Components in mind, but I keep finding it useful for them and some of my "v2" project is expanding what is possible/easy with them. https://worldmaker.net/butterfloat/

> In the real DOM you need to know which element from project _from_. The <slot> itself is only half the connection. In a light-DOM only document full of <slot>s you won't know which elements to project where.

There's still a concept of "importing" a template. A host node has slots under it and requests to "import" a template from elsewhere in the document. That import process can adopt the slots then. It's "adoption" rather than "projection" and you "lose" that relation to the source document that "slots stay in the same place", but the DOM has never been static with respect to source documents.

> ``` const template = document.getElementById("templates-materialization-base").content;

this.appendChild(template.cloneNode(true)); ```

It was pointed out to me that `this.appendChild(document.importNode(template))` is faster due to "adoption" (`importNode` clones and adopts the nodes for the current document at the same time/single tree walk, saving appendChild from having to do a separate adoption pass/tree walk; template.content exists in a fake separate document so the nodes need to be "adopted" by the current document).

Which is a point in favor of the current complexity of the JS API for working with templates. I agree that "HTML Modules" would be nice to have and more declarative template usage that doesn't require the Shadow DOM would be lovely. Both are still proposed standards going through various debate cycles.

> making it so that you have to have to make a more complex "update_render" function to work around that

One potential simplifying answer when trying to deal with batched updates to attributes is a simple "dirty flag" and requestAnimationFrame callback as your "update_render". Most things changing more than one attribute at a time are likely going to do it all between animation frames and even if they can't, rAF provides other throttling that prioritizes user interaction.

There's still complexity in that approach, but it is isn't as complex as trying to build a throttling timer.

> I usually have a function `_set_handlers(boolean)` that is used on connected and disconnected callback but this is just plain js organisation:

It looks like you could replace some or most of your `_set_handlers` function by implementing `handleEvent(e)` for the Web Component. It's an auto-registered/unregistered handler at the component level of the event bubble.

> For one thing, I just genuinely think WebComponents are a badly designed API that is weird and hard to use (how many people are using WebComponents without at least Lit, if not something much bigger?)

I've been using Web Components entirely without Lit (and somewhat dislike Lit) both "Vanilla" and with a JSX framework that is not a Virtual DOM (not React).

I think WebComponents for me started to click when I realized that for the most part I don't need the Shadow DOM at all and can work entirely in the "Light" DOM.

The other thing that only more recently clicked for "vanilla" Web Components work was moving to implementing `handleEvent(e)` and relying on "old fashioned" event bubbling over endless `this.querySelector('#element_name').addEventListener(…)` (and `removeEventListener` if you are a good citizen and care about garbage collection) boiler plate.

The Shadow DOM makes sense if you need a more powerful `iframe`, but that's almost never what I want, because I trust CSS and trust the Cascade. So much of the Web Component API complexity is just and just for Shadow DOM. Web Components make so much more sense in the "Vanilla JS" world as soon as you realize you can YAGNI Shadow DOM and stick to the Light. I understand that for ad companies and "powerful embeds" companies really want a higher powered `iframe` and so I can't blame Shadow DOM for existing, but I can blame Shadow DOM for making Web Components look like frightening things that "need" Lit rather than simple things that Lit pretends are more complicated than they are because it also assumes you want to start from Shadow DOM by default rather than Light DOM by default.

(You don't get some of the automagic of the `template` tag if you eschew Shadow DOM, which is silly and "Light DOM template standards are still on the roadmap" but the `template` tag is still useful in Light DOM work, and ironically Lit doesn't make good use of the `template` tag anyway so even most Shadow DOM users are not using `template` much yet.)

Similarly, a lot of the "I need a framework like Lit" comes from event handling and it feels like a full circle of the jQuery days with lots of querySelector/querySelectorAll and addEventHandler/removeEventHandler imperative shuffles in connectedCallback and disconnectedCallback, but one of the things that created the situation that was jQuery event handler hell was people not learning and/or distrusting the event bubbling system and one of the performance tools (that even React uses under the hood) in the jQuery world became moving event handlers up the bubble chain and being smarter about fewer handlers (even as the jQuery "state of the art" never strayed very far from lots of very specific handlers). (In React's case this is why in the debugger you often see classes called SyntheticEvent and friends because React often subscribes at a higher bubble level and then creates synthetic events to make it look like you are creating event handlers lower in the DOM.) In the WebComponents world you can implement the `handleEvent(e)` in your (Light DOM) Web Component, get addEventHandler/removeEventHandler "for free" from the browser, rid yourself of a lot of query selectors, and take (performance) advantage of the event bubbling.

For the same reason that most jQuery era scripts still used very explicit query selection and on/off handlers and React uses synthetics to pretend to do low level event handling with bubbled event handlers there's a developer experience issue in building combined event bubble handlers versus "localized" event handlers to deal with, and that may still often lend to wanting a framework to support writing event callbacks as "localized" event handlers, but Lit isn't doing anything particularly interesting there either (it takes an approach somewhat like Angular, preferring localized handlers and just providing template sugar for addEventListener/removeEventListener). As far as I'm aware no one is really quite thinking of it in that way of bubbled handlers other than the easiest way to write Vanilla JS WebComponents, but I've been toying with my own "micro-framework" ideas there.

Structural typing versus nominal typing is another one that often upsets "strong type" fans, because structural typing looks weak (but is still stronger than "no typing").

- I replaced a mess of prettier config files, eslint config files, tsconfig files, npm install scripts for all the above plus the typescript eslint config plugin for deno fmt, deno lint, deno check. It's nice to have that all in one place.

- Deno uses a system-wide module cache instead of endless nested node_modules folders. Especially on Windows where symlinks work but software, including npm, tends to avoid them by default, the space savings can be quite large.

- I kind of like Deno Deploy, even despite the messy transitions and generally "half-finished" feeling, but mostly because its free tier has been generous for the hobby projects I've been building on it.

- It's a strange sort of benefit but Dependabot doesn't police deno.lock files in the same way that npm package lock files get reported on, and even if it did it's a lot easier to keep development/scripting-only dependencies entirely out of the deno.lock file (by using http dependencies or full version qualified imports like "npm:package-name@v1.2.3" only for small scripts and dev time things). I've had some frustration lately with Dependabot pings on "completed" repos for dev dependencies that don't affect runtime. Especially in the deep dependency trees of eslint.

Node directly runs Typescript now, just not inside libraries (for political reasons not technical ones). It's type stripping approach is the strictest compared to Deno/Bun in that you must turn on a bunch of Typescript linting like Isolated Modules and Erasable Syntax Only to get it to work (and not use enums or namespaces). (Which is in line with the strictness suggested by the Type Annotations TC-39 proposal, for what it is worth.)

Relatedly, if you aren't developing C/C++/Rust packages against Node's FFI (rather than emscripten and wasm these days), why do you need a version manager for Node at all, just use your preferred package manager and stick to auto-upgrades of Node LTS.

(That's one of the things I appreciate about Deno is the "let's just auto-install point upgrades" evergreen mentality and its suggestion that side-by-side versioning is maybe a mistake in the JS world.)

One of the links (on Fusion) points out that GHC in particular has a lot of optimizations and rewrite rules for folds and many Prelude functions written as simple recursion also include optimized fold representations to suggest to various stages of GHC's optimizer.

As with so many such topics it seems an interesting spectrum between clarity and/or aesthetics and potential performance optimizations. Especially because it often seems like one of those "learning curve flips the clarity/aesthetics preferences" because at some point of familiarity folds can be faster to read than trying to reason through an explicitly written recursion.

Cryptographic protocols have been moving towards something of a compromise in flexibility. "Everything flexible" is a security risk, especially when "everything" includes "fallback to nothing secure". "No flexibility" is a security risk because you can't upgrade. The middle path is something like "version numbers" with hard breakpoints. "I only support v2 of this cryptographic protocol and will not fallback to v1."

Which is sort of the hash algorithm approach git is taking with incompatible versions and a version break.

We are in a golden age of indie cinema right now. Low budget stuff is doing better than it has in most of the history of the media. Both Backrooms and Obsession made strong returns on very low budgets. The kinds of movies like Reservoir Dogs and Pulp Fiction are doing rather well. Normal and Furious were both good as two recent examples. I could give a long list of really cool stuff I've seen just this year. Have you seen Buddy yet? So weird and rather great.

What Hollywood "lost" in recent decades wasn't indie/small budget/experimental/weird cinema, but "the middle budget", the romcoms and "family movies" and expensive ensemble comedy movies and oscar-bait dramas with lots of bankable stars doing silly or dramatic things on less than a blockbuster budget but more than an indie. But the indie world is filling in a lot of those gaps, and the direct to streaming "original" world is filling in more of those, and signs are some of those budgets are coming back (Heart of the Beast is an example of that sort of lost mid-budget film that just released to theaters).

You may not like superhero budgets, but they are not what killed "weirder indie shit". If anything they seem to be supporting it. Superheroes killed the mid-budget because they could play many of the mid-budget genres such as "family movie", comedy, and romance, and sometimes even "serious" drama.

(ETA: The Big Lebowski is a fun example because that was an indie budget film and the closest the Coens came to the mid-budget was The Hudsucker Proxy which needed it for all the period piece work. Budget size doesn't necessarily equal quality, though I remain a fan of The Hudsucker Proxy it did poorly in the box office and is often considered one of the worst films from the Coens. Ethan Coen directed Honey Don't and Drive-Away Dolls in recent years which were both excellent. The Coens haven't disappeared, though they've shifted gears a bit.)

I prefer the punny term "Soup opera". (It's full of supes.) It doesn't need to be gendered, women love many of the superhero movies and TV shows, too. There's also plenty of women that are fans of wrestling, as well.

Also, I say it with affection. I love my soup operas. Our culture has come to have negative connotations to the term "soap opera" and also to the term "wrestling", because of the association with lowest common denominator storytelling, but it is harder than it looks and mass appeal isn't something to scoff at.

I have and continued to say that "I googled it on the Bings". Some people have used it as the generic verb.

Microsoft has invested in C# for a much longer time, and uses it themselves in production. Why would you doubt Microsoft has at least some vested interest in exploring more cross-over of C# for systems programming that today Rust gets used for, but C# is growing capable of doing?

Yeah, 1 is always better than 0, just that reminder that real "product focus" happens when you have multiple customers, not just doing one-offs for one or two customers.

I know people that have used it that way in a while. Myself included: I certainly say that. I haven't intentionally used Google the search engine in years, but I use it at the generic term for an internet search.

Losing a trademark to a generic word can make marketing a lot harder, though. A company often needs a new brand then, because everyone else can use their old brand in the marketplace.

It would be fascinating for Alphabet to lose Google the brand to being a generic word. (To be fair, it is something that maybe should have happened already.) Kagi or DDG or someone could use a domain like google.new or google.tech to easily retrain old habits of some users. What is Alphabet going to do in that case? If Google is no longer a trademark but a generic word, do they focus on having the "Alphabet Brand Google" or "The Original Google, by Alphabet"? Either way, that's harder to market and maybe easier to build a fresh brand than fight the generic terminology.

Yeah, the Smalltalk and Self family take this "everything is an object" approach, sometimes to extremes.

Another relatively well known language in this space for its use as an alternative to especially Lua in embedding situations is Io: https://iolanguage.org/

> And you need at least one real customer project to dogfood the platform initially. Because most platforms start out way too generic with pure architecture astronauts [0] at the helm.

The Rule of Three in Refactoring applies to this scale, too. If you are building a "platform" for one customer project, that's a one-off and quite possibly YAGNI. If you are building a "platform" for two customer projects, that's likely coincidence and still possibly doesn't show company-wide need. If you can build for at least three customer projects, that is a pattern, that provides real guidance on exactly how generic things need to be and better ideas how to abstract it.

I've had similar fights over the years, on both sides of the discussion.

"If our internal design system is barely half as well documented than Bootstrap then teams will still use Bootstrap. We should take a page from Bootstrap's documentation and include as much detail as we can, on everything."

"As a platform team, your product is this API my app calls. My beta environment should be pointing to your Production, never your beta environment. If that means you need to support better multi-tenant from the same 'app', then you need better multi-tenant. Your outage impacts my testing, which impacts my velocity, which impacts my deadlines. Your backwards incompatible updates need to be planned and scheduled and rolled out like a Production update, every time."

Product mentality is still very useful in platform development. If you can't sell your platform on its documentation and its stability and you must sell your platform on mandate and top-down control, you probably aren't doing as much to help your engineering culture as you think you are.

I've had justwatch.com tell me things are on Mubi with ads, so I've watched films on it, but can't remember which ones and not enough to subscribe.

GoldenEye was re-released for Xbox One and is available to purchase right now: https://www.xbox.com/en-us/games/store/goldeneye-007/9n6639h...

I've been wondering this some myself, how many services I could drop and just return to a physical media budget.

One of the factors contributing to it not necessarily being cheaper to buy box sets: Target, Best Buy, and other big US chains have given up on physical media for movies. Last I heard Wal-Mart is on the fence about long term support for it. (At the moment the only chain I know that seems still in it for the long haul seems to be Barnes & Noble, but they could have one bad quarter and change their minds quickly. My local store the DVD and Blu-Ray section is somewhat obviously what used to the Music section and still has a bit left of that old focus.)

Even the manufacturing side seems to be disappearing. Sony has flirted with dropping physical media sales of movies. Warner Brothers and Paramount seem likelier to drop physical media sales if they are allowed to merge.

Netflix lets very few originals make it to physical media. Most of the exceptions I'm aware of are Sony projects. Sony Animation being one of Netflix's last exclusive deals from a studio that isn't themselves. A lot of Prime Originals don't make it to physical media. It seems a mixed bag for HBO Originals and Hulu/Disney+ Originals, presumably based on some internal formulas of popularity. A lot of Apple TV Originals seem to get delayed physical output, but that's largely been because Apple TV doesn't have its own studio, but that changed relatively recently with the purchase of Red Hour (Ben Stiller's studio, of Severance and The Dink fame).

It certainly feels like physical media is dying right now. Maybe more reason to switch to investing in it over streaming services, not that an individual's budget decisions in this vein will affect the company's bottom lines enough that they will notice.