Github availability is driven by massive growth in the amount of work. I might add that is without a massive growth in the amount of accounts.. MS is struggling to make Github systems scale, clearly.

VS Code doesn't have a similar scaling issue that I see

Maybe NPM is scared to break a ton of packages? I also think action from NPM on the repo level is vital

I went through the package.json on my machine - seems like ~400 / 60000 or 0.7% have (pre|post)install. (That's not all of the scripts that run at install)

Seems to me like a backwards compatibility is a non argument since pnpm is popular enough to stand as existence proof that scripts can be, at least, opt-in

IMO - pre- and post- install scripts should just be abolished/deprecated. It should require a special dispensation from npm to even publish one. A better system for binaries (needed by esbuild) is probably needed.

Even saying "just use pnpm" isn't enough, we need to get the developer community to herd immunity and that isn't going to happen on an opt-in basis.

I would love for npm to sandbox as well. But I think the better way forward is just turn off scripts.

Yeah but with a flashing light, if you look during an "off" phase, you don't see anything for a little while. Animated would/could show one segment on always

I'd like to orange turn signals come back! They could even have an arrow inside them and toggle between inside and outside. Maybe thats too goofy, but at least something would always be illuminated. Here's a goofy SVG to show the concept

https://codepen.io/tln0/pen/WbodXKw

Turn signals in the EU are required to be orange. It's the US which doesn't have any laws regarding their color.

https://www.thedrive.com/guides-and-gear/u-s-amber-turn-sign...

Yeah in context I'm Australian where turn signals are orange as well.

The US is wild in terms of its commitment to "maybe the brake lights are faulty" style.

What? Why? Git has branches...

They're two completely different codebases... even if they are 100% feature parity, it's 100% different code. They should absolutely be separate from each other, with different issues lists. Clean separation of two different codebases isn't a strange concept...

Its not 100% different code though. Docs, build instructions, C++, Typescript...

The issues should absolutely be kept. The rewrite was file by file translation so logic bugs would remain. It's valuable to ensure the memory bugs are in fact fixed. Starting the issues from nothing does not make any sense to me.

Judging by the comments, Bun as a company doesn’t give a single shit about community. The only reason it is in the same repo is tracking down issues, discussions, etc. Those would be hard to migrate.

Right, but it's my understanding that it was done as a PR that was merged to `main`. Sure, anyone could find the last Zig commit and branch off of that, so I guess it's all po-tay-to po-tah-to.

> Admittedly, however, support for the <dl> element is not yet universal.

Wait what? <DL> has been in HTML since.. the first draft in 1993!

I like DL's but they can be challenging to style. This article is using a lot of fixed pixel widths which would break on really small screens or larger data.

Granted, I do not know what I am doing with CSS, but the Character Sheet example seems standard flexible elements?

Some of the extracted CSS chunks

  #statblock{
    box-shadow:0 20px 25px -5px rgba(0,0,0,.1),0 10px 10px -5px rgba(0,0,0,.04);
    font-family:Lato,'Trebuchet MS',sans-serif;
    font-size:85%;
    min-width:50ch;
    max-width:70ch;
    margin-inline:auto;
    background-color:#fffaf0;
    padding-inline:2rem;
    padding-block:1rem
  }
  dl.statblock-bio{
    color:maroon;
    line-height:1.5;
    border-top:5px solid maroon;
    border-bottom:5px solid maroon;
    margin-block:0.75em;
    padding-block:0.75em
  }
  dl.ability-scores{
    min-width:40ch;
    display:flex;
    justify-content:space-around;
    color:maroon
  }
  dl.ability-scores>div{
    text-align:center;
    line-height:1.5
  }
  dl.ability-scores dt{
    font-weight:700
  }

Well, it took about a decade for web standards to become a real thing and a lot longer for Web Platform Tests to come to be. Still, while there are lots of tests for DOM construction and visual rendering, testing construction of the accessibility tree is lacking (also keyboard interaction testing).

And that's just for browsers, there's no shared spec for the operating system accessibility APIs the browsers' accessibility tree has to be translated into or how screen readers (and other assistive technologies) will use the OS's APIs.

I've found CSS Grid is extremely useful for styling DLs.

This is about the rust conversion but that has not been released.

> Due to foreseeable compatibility and security issues

Hmm, Zig bun crashes plenty.

I wish yt-dlp linked to detail on why there are foreseeable compatibility issues. Both projects have test suites, in an ideal world they would allow fast rewrites. Maybe they want to limit inflaming the situation, but if they have spotted some specific issues it would be good to see.

I hope Bun.rs is 1.4 or even 2.0 and not a minor release, with some alpha/beta releases.

Yep, it's one thing if there was some project that saw severe regressions in Bun.rs and actually showed data about regressions.

But it's been available for a week. And so far, seems like crickets on actual data on any regressions. It's more "I just don't like this!" style grumbling.

They could at least wait a bit, test the new Bun for some weeks/months, have people read big chunks of the codebase.

It should be a major release indeed, and communicated as such, with full accountability of the migration beyond an “all tests pass”. A major tool should move slower, be tested longer, more thoroughly, since it’s used my millions.

It’s reminiscent of JavaScript world, where something is in beta for mere days (e.g. Expo’s short release cycle).

I found this:

    bun upgrade --canary

...will install a very recent build, with version 1.4.0

I still hope there is a beta release.

pre- and post- install scripts should just be abolished. It should require a special dispensation from npm to even publish one.

Yes, I choose to use pnpm but opt-in safety isn't going to get the developer community to herd immunity.

I'm not sure any of the packages here would be part of a "better standard library".

Do any language standard libraries have a "3 hours ago" formatter? Thats what timeago.js does

Maybe slice.js, which just does python-style indexing with negative numbers. TC39 already made array.at() and array.slice() handle negative numbers.

> Do any language standard libraries have a "3 hours ago" formatter? Thats what timeago.js does

There's also a platform feature for that now: Intl.RelativeTimeFormat: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

It asks you to do the basic time math to determine your granularity so there's still a role for a library, but also that time math gets easier with Temporal: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

(Specifically `Temporal.Now.instant().since(somePastInstant)` returns a Temporal.Duration that you can relatively easily determine the highest granularity you want and pass that to an Intl.RelativeTimeFormat instance. Also Intl.DurationFormat which is what a Temporal.Duration's `toLocaleString()` uses may also be good enough in many "x hours ago" type situations, though it is over-precise for them.)

Thanks for that!

So, back to the GP post - TC39 should make a bigger stdlib.

Lets say timeago.js is warranted (as a polyfill and terser API) AND TC39 is taking action.

On slice.js, TC39 took action AND usage is unwarranted since the functionality is widely available. Maybe a stride.js would be needed.

There are 2 modules where npm's culture of "tiny modules because the stdlib is impoverished" holds - but the issue isn't TC39 really. There are 312 modules that aren't related to npm's culture of "tiny modules because the stdlib is impoverished".

> Lets say timeago.js is warranted (as a polyfill and terser API)

Though it may be useful to point out that timeago.js specifically is not a wrapper for Intl.RelativeTimeFormat. It implements its own unique internationalization beyond/instead of the platform capability. (Similarly, so do Moment, Luxon, and date-fns.)

I would argue that it is unwarranted to use such libraries, because we can do better in Vanilla with platform features now. Though yes, Safari still doesn't implement enough of Temporal today for it to be considered Baseline Widely Available. (There also are direct Temporal polyfills. Surprisingly I've found vanilla polyfilling with Date by hand isn't terrible enough to warrant a Temporal polyfill, but also my most complex Temporal math is usually server-side in Deno.)

But yeah, that's mostly quibbling outside of the point being made.

> There are 2 modules where npm's culture of "tiny modules because the stdlib is impoverished" holds - but the issue isn't TC39 really. There are 312 modules that aren't related to npm's culture of "tiny modules because the stdlib is impoverished".

Ah, yeah, I think that is a fair call and I mostly agree with it. "The stdlib is impoverished" argument has changed a lot since the "leftpad" days. So much so it has started to feel more like "the stdlib was impoverished for too long" (and/or "Node was too slow to adopt Browser platform stdlib features and accidentally forked the stdlib for too long"). Most of the damage happened in the past, but a lot of those libraries remain in the ecosystem as developers are slow to adopt new platform features or switch away from old "comfortable" libraries (timeago.js or slice.js versus more vanilla approaches; the quibbling above wasn't entirely tangential, I suppose).

But also the proliferation of modules in npm goes far beyond that. Of course there are a lot of blockchain libraries that will never be stdlib. Of course there are client modules to proprietary APIs that will never be stdlib. The giant size of the npm ecosystem includes a lot more than just "stdlib" style libraries.

I even think the "leftpad" debacle itself did a lot to accelerate npm out of the "tiny modules" approach in general. It also may have itself been a sign that that attitude was already dying. (It was caused by one of the earliest and most prolific "tiny modules" authors leaving the ecosystem in a huff because the ecosystem was changing.)

Thats a really elegant solution.

How does the website trigger the CI script? Through GH rest API?

thank you, yep through the rest API, here is the example: https://github.com/archestra-ai/website/blob/29ebdacbd8a22b9...

Don't you need fire setbacks? I didn't think full roof racks were possible

Building codes on that are going to vary locally. They are doable in most of Switzerland if you plan for it: no sky lights, no chimney (there's setbacks and fire codes for those), ect.

I thought the IFC International Fire Codes were a bit more ubiquitous than they are. Apparently whole roof is possible in a few EU countries. Probably not a good idea for the stick-built houses prevalent in US though

Thanks for sharing