cxr

For a time, it was popular for movie trailers to end with a domain, often of the form "${ $TITLE }film.com", which would take you to the marketing site for that release. Nowadays there's a whole TLD specifically for movies.

It's a shame that isn't a norm for you to be able to plug a URL into a reader that consumes application-specific RSS (à la podcast clients) for the express purpose of giving notifications when that film is available (either for rent or by subscription) on a new platform.

(Ideally, of course, the media itself would be self-hosted, so you could paste the URL into e.g. VLC and encounter a platform-neutral way to negotiate payment directly with the distributor (or not and just get embedded ads—à la podcasts) and then you're off to the races.)

And the Web is not HTTP!

There's always some nincompoop who brings that up. Al Gore deserves credit for what he did as a senator and vice president. He helped to pass legislation that enabled the NSFNET backbone to grow and to permit commercial traffic to flow on the government-sponsored backbones in the US. Had he not done that, it's pretty likely that the commercial sector would not have seen an opportunity to create a commercial internet that all of us can enjoy, so he does deserve some credit for what he's done.

— Vint Cerf, Tracking the Internet into the 21st Century <https://www.youtube.com/watch?v=Hf0rjtnwC9A>

Would moving the untrusted content to be served from a separate domain entirely close the hole?

Yes.

That's why I'm careful not to include allow-same-origin in the sandbox attribute

It doesn't matter. I just said there is no combination of CSP or the iframe sandbox attribute that can be relied upon here.

<iframe sandbox=""> - which really is designed to be used as a sandbox

Not for untrusted content living on the same origin to prevent it from exercising any of the powers that it would ordinarily have to be able to access sensitive data. It's a misleading name and shouldn't have been chosen. There is no combination of CSP or the iframe sandbox attribute that can be relied upon for that purpose. This is a fundamental limitation of the way the specs were written.

(There needs to be a big warning about this on MDN, but moving from the old wiki to a wiki with GitHub for login to the GitHub-based pull request process really didn't help the there's-a-problem-on-this-page-but-limited-resources-to-make-things-better problem.)

CSP is optional and designed to be one part of a defense-in-depth strategy (to extent that it was thoughtfully designed at all—it's an awful standard that should not have made it past proposal stage). It's not a solution for sandboxing untrusted content and should not be relied upon that way. Treating it like one is a great demonstration of how some uses of CSP make people more vulnerable.

A lot of people don't get podcasts. They think it's a genre (and that it applies to the show(s) they watch on YouTube).

For a large segment, telling them that a feed reader is for podcasts but for reading will just elicit a "what?"

It's no use being pedantic if you're not going to be correct.

This is a pedantic point, but that's not really what the definition of compiler is as much as a common understanding of it. By definition, it just translates one language into another

The history and etymology doesn't support that definition, either; that's just another "common [mis]understanding" of the term. It's in the name. A compiler produces a compilation—an aggregate of multiple subroutines, including user-supplied ones and some by the system/programming environment, transformed into a single program for a given target.

(You're describing the process of "autocoding", a job that every compiler does, and a term that predates "transpiler" but that no one uses because they favor stretching the more frequently encountered term "compiler" for their use case.)

The creator of lcc also published a paper "lcc.NET: targeting the .NET Common Intermediate Language from Standard C" (2004).

<https://drh.github.io/documents/msil-spe.pdf>

One problem with lcc has always been that it's distributed as source available with restrictions and has never been available under a FOSS license.

You seem very angry and I clearly don't understand what you are talking about.

Luckily you managed to frame it so that the failure comes across like something that I got wrong and messed up and am responsible for, and that's the most important thing.

Unfortunately Firefox doesn't support the FileSystem API so to do this you need to resort to uploading the entire source code directory each time you change a source file.

Right, it's so much less onerous to have people download and set up an entirely separate fickle toolchain—and needing to trust that the install triggers in the package.json of some transitive dependency won't exfiltrate your personal data or install some nefarious ineradicable background service onto your system, versus the two extra clicks you'd have to subject yourself to if you wanted to re-run the build.*

Wait, no.

people [are] forced to ship "Chrome-based only" features

No they're not. By your own admission they could make their build scripts work with the standardized HTML5 APIs that are well-supported in all major browsers. They choose not to.

And you're not really responding to the substance, anyway—which is that JS programmers (frequently writing for browser runtimes, even) require that you install NodeJS, Bun, or Deno (because they hardcode the build scripts internals against one of those runtime's APIs). If programmers really were writing build scripts that you could run in Chrome but unfortunately not Firefox, then even that would be an improvement over the status quo. But that's not what we're talking about, because that's not happening.

* most of which are destined to be one-shot executions, anyway

That's a start at improving something. But it won't rid itself of the Playskool/Fisher-Price gimmick factor or have any lasting effect until we can convince JS developers to write their own tools in a standards-compliant dialect and use standardized APIs so that contributors can use the runtime they already have installed instead of being cajoled and browbeaten into installing NodeJS or Bun or Deno or whatever to do what the browser runtime is perfectly capable of: opening a project directory, executing the code comprising the build script, and outputting the build artifacts when it's done.

What?

This is an independent riff on an argument Ted Nelson wrote down 50 years ago (and the reason why he coined the term "hypertext").

<https://en.wikipedia.org/wiki/Computer_Lib/Dream_Machines>

<http://link.springer.com/10.1007/978-3-319-16925-5>

the class="" property is in the HTML and that is the styling info

The class attribute (not "property") is in the HTML because it's part of HTML. It's markup. Element classes weren't created either by or for the CSS people when CSS came along. The class attribute predates CSS by years and has no more relation to "styling info" than the id attribute does.

How can the browser execute git commands from opening a local html file?

It can't. The CONTRIBUTING.html shell would spit out a file and tell the user what Git commands need to be run—just like project READMEs (or landing pages like jekyllrb.com) show which commands will install the tool.

I am one of ~3 people primarily responsible for the JS Reference as it appeared/appears on developer.mozilla.org since before NodeJS (or V8) ever existed. I "know what JavaScript is".

Like the Project Gutenberg collection on archive.org, the ZIMs are only current up to 2018.

There is no argument or insight in your comment. It's physically possible to type in code that makes direct use of non-standard APIs that work in NodeJS but not the browser. Pointing out that this is so and that there are people who do it is not the same as engaging with the subject of whether they ought not to—which was the point of the remarks you responded to. Previously:

You're offering a retort to someone who is communicating their position that you ought not do something, where the retort consists of nothing more than explaining that people are doing it. Yes, clearly. But what the person you're responding to is arguing is that you ought not do it.¶ Consider[…]:

Person A: Here's little advice: don't take up smoking. Smoking is bad for you.

Person B: Yet people smoke

<https://news.ycombinator.com/item?id=38712699>

You don't need to put it on the Web to be able to leverage the World Wide Wruntime.

Epiq looks to be written in TypeScript and distributed as JS via NPM. You know what excels at executing JS? The browser.

If you want to actually address the usability problems—then create a CONTRIBUTING.html—linked from the README, that users are instructed to double-click to open (i.e. launch in the browser on any sanely configured system). From there, they can/should be able to load the project either by pointing to it with a filepicker-based workflow that's the same as VSCode's "Open Folder…" workflow, or by dragging and dropping the source tree into the browser window. If you do it right, then this should immediately present them with a browser-based UI for poring over and interacting with all the Epiq data in the repo—down to the Git commands to execute to integrate changes into the Epiq "database".

It's beyond baffling that so many programmers who are nominally JS developers thumb their noses at writing standards-compliant code and instead insist on coding directly against Node's proprietary APIs.

DigitalOcean App platform[…] only connect to GitHub

They also support deployments from GitLab (so long as you're using the gitlab.com-hosted instance and not a self-hosted GitLab instance). If you've deployed your own self-hosted forge, then you can connect DigitalOcean App Platform to it by using gitlab.com as a bridge—register an account on gitlab.com once and instruct your self-hosted forge to replicate copies to gitlab.com. You don't really need to actually use GitLab.

Having said that, considering that DigitalOcean is in the business of selling IaaS/PaaS, it's loony that they don't let you connect to, say, your own self-hosted Forgejo running on their infrastructure…

(Indeed, considering how many people would like to self-host their own forge but how few people want to actually set up and do admin for it, it's loony that DigitalOcean doesn't pick up, say, Forgejo and/or an alternative and offer a sharply discounted (e.g. $20/year) quasi-managed one-click deployment option with first-class support for connecting to their App Platform.)

This post highlights but never explicitly addresses the current language trend that involves the corruption of the word "agent" to imply ChatGPT- and Anthropic-era AI.

It also speculates on the practices at Microsoft in its opaqueness but doesn't recognize the development methodology used for Linux despite its transparency or acknowledge how it differs from the pilloried code review that the audience is most familiar with—even though the kernel development project is the cradle for the VCS that everyone decided to use (but also to never use correctly).

Overall, there aren't really any insights here. The solution described just highlights that high-trust teams are composed of members that (are|can be) trusted by one another. But being on that kind of team is a luxury. The introduction of coding agents doesn't change anything. Take out the LLM-powered patch iteration, and it works for all the reasons it already worked before the advent of coding agents. It's a little like the obliviousness-to-privilege of folks who try to address the problems of people who experience poverty with advice that reduces down to the question, "Have you tried <thing that precludes someone who is poor>?"

ECMA-262 doesn't require the use of NPM or NodeJS. (In fact, they are at odds, even 10+ years after modules were standardized in ES6.)

PS: Really cool static site generators that shoot for simplicity don't require you to create extra template files written in a new, made-up template language. When you want to create a new post, you give it (a) the static files from your existing site and (b) the markdown for your new post. The "templating" engine inspects your existing posts (incl. e.g. class attributes) and then copies the same document structure into a new file, except with the right stuff (timestamp, title and heading, post content...) substituted in to the places where it's supposed to go.

<https://news.ycombinator.com/item?id=30961588>

That breaks if the library uses build scripts

Uh… no.

setting up native binaries, or native modules linked against the specific Node version

So the majority of projects—those that don't use binary NodeJS modules—don't have a reason for sidestepping the primary VCS and going along with npm's shoddily designed overlay version control approach?

However, I would just stick with regular pnpm and installs.

You're not answering the question. npm isn't bedrock, and pnpm certainly isn't. If you're going to introduce (mandate) the use of a tool in the workflow, you should be able to justify it by explaining your rationale for introducing it (and making everyone deal with the associated costs). You should at minimum be able to provide a lucid explanation of the tradeoffs. For good measure, you should be able to disprove the "NPM Null Hypothesis"; you should be able to state a straightforward answer to the question, "What problem is this supposed to be solving?"

In this case what’s needed is „npm ci“ instead of „npm install“ or better „pnpm install —frozen-lockfile“.

The grugbrain developer says, "I can use git-add to keep a version controlled copy of the library in my app's source tree with no extra steps after git-clone."

(Pop quiz: what problem were the creators of NPM's lockfile format trying to solve?)

(2005)

<https://github.com/w3c/feedvalidator/commit/8ca2fd4e5a520158...>

Since this is largely/almost entirely for private data with occasional publicly accessible content through share links, this is a good candidate to be rebased onto remoteStorage, which gives you auth and storage for free, and there's always an escape hatch for the user to have access to their data—and permit other apps to access it, too.

<https://remotestorage.io/>

Wasn't this specifically some lame-ass attempt to combat some click fraud or something these extensions were doing?

No. That you believed that was just an unfortunate consequence of HN's kneejerk tendency to upvote middlebrow dismissals to the top comment, which resulted in people rushing to craft apologetics for what is in reality bonafide scumminess on LinkedIn's part, which itself resulted in confabulations like the claim that, "It was all extensions related to spamming and scraping LinkedIn last time this was posted"—which is simply untrue.