> there should be an easier way to "pin" a dependency, other than vendoring
You left out the part that explains why.
5,558 karma · joined August 24, 2019
-- Richard Feynman. Interview broadcast on BBC, 1981.
You left out the part that explains why.
Aside from the fact that it's a widely implemented, mature standard and the reason given in the article which happens to be one of the most important things in world of browsers ("Don't break the Web"), sure, there's no reason.
No, I'm not. Nowhere in my comment have I made that claim, nor is there any claim that could even be mistaken for trying to argue one way or the other. It's like you lack the ability see words on a page and understand what's actually being discussed in the remarks you're responding to. (This also explains why, when challenged on succumbing to the industry tendency to make all-vibes arguments instead of evidence—directly in the comments of the article that calls this out—your direct response to that is to restate your claims and arguments and avoid providing any evidence. It's always just hunches and attempts at inductive reasoning, all the time.)
The evidence-free claim here (that with frameworks you end up spending less) is all "vibes"—or, put more charitably, a hunch plus some inductive reasoning. It's not a tested hypothesis.
The crux of your argument* is essentially "a + b > a for some non-zero b", where b represents what you are "paying for your library code". The right side of the relation is supposed to represent using a framework, but this neglects c, the cost paid for not using the Nike method ("Just Do It") when it comes to dealing with things yourself (i.e. the framework cost—which, like b, is never zero).
* as stated at least; it's possible and probable that you really don't mean to say that c simply doesn't exist but that b > c (either by intuition or experience or both) but that's still just a claim—which is the entire basis for the author's criticism: not whether frameworks are or aren't actually more cost-effective, but the greater meta-level concern described here in this comment, in the original piece, and other comments by the author and people like Alex Russell elsewhere describing how resistant the culture is towards the notion of attempting to prove or falsify these kinds of claims (if you can even manage to get people to agree to formulate them in such a way that they can actually be subjected to the scientific method)
- RSG 2.0 SDK overview <https://gitlab.com/rokudev/rsg-sdk/-/blob/main/documentation...>, which includes the section "Why TypeScript"
- Announcement of Roku repositories moved from GitHub to GitLab <https://blog.roku.com/developer/gitlab-move>
There is no original repo to link to. That's why the README says that there isn't one.
> Setting up a git mirror that auto syncs takes less than 2mins
Prove it.
The only thing that can be compared are language implementations. That a given implementation, such as GCC, has an excellent code generator that emits efficient code is saying something about how great that code generator is. It's not that the input language is inherently "performant"; C programs compiled with GCC and Clang are fast. The same program compiled with My Toy C Compiler, with none of the work that has gone into LLVM and the GCC backend, is going to have different runtime characteristics.
There was a financial conflict of interest, since Mozilla Corp was selling Pocket subscriptions where the ability to even just be able to have an unlimited number of highlights was a premium feature.
Firefox has an experimental Tab Notes feature now: <https://support.mozilla.org/en-US/kb/tab-notes-firefox>
(In the Firefox heyday, the bookmarks manager had a Description field that could be repurposed for adding notes.)
"Just"? The requirement to retain verbatim copies of the license text and copyright notices is pretty much the whole point of those licenses. A downstream project that isn't following the terms of the license that it was offered under is violating the license, full stop.
(Side note: not a fan of the tribalism and reactionary tu quoque-y sentiments coming out in the comments here and in the linked comments on GitHub (which, to be fair, is predictably awful). If there are folks distributing unauthorized copies or derivative works of Photopea, those need to be taken down (or DMCAed). If Photopea itself is not in compliance with the licenses of its dependencies, it needs to be brought in compliance. Neither these things or nor some other acts undertaken by any of the persons involved cancels anything else out.)
The set of capabilities available to native desktop apps is a superset of the capabilities available to browser-based Web apps.* Ergo, if browser-based app distribution possesses some desirable quality, the same path is available** to a native app not built on W3C/WHATWG APIs.
* You can frequently come across people make a similar logical error in the opposite direction when it comes to being more distrusting of browser-based apps than native binaries, especially with an undue focus on the risk of the app exfiltrating your data over the network—even though a native binary can do strictly more damage than a browser-based app, which is at least confined to its sandbox and the associated execution model.
** It does require, though, that one actually take that path.
I'm not sure what effect you think properly functioning build scripts in my project(s) are going to have on the broken build systems encountered in other projects. Those broken build systems continue to be broken, despite my projects' build scripts continuing to work as expected. Please advise.
GET tag:alice@example.net,2013:15fb-4628-94d3 HTTP/1.0
HTTP/1.0 302 I love you
Location: https://example.net/~alice/2025/11/03/go-vote
Good.
And `rm ./.gitignore` will, predictably, leave the tree without a ./.gitignore (i.e., the desired state) whereas `git status --ignore`, uh, won't.
> The symlink creates what is effectively a version-controlled gitignore
No, it doesn't—like I already said. The ln(1) invocation you wrote is not going to work. As written, it contains two glaring errors obvious on sight to anyone who actually has enough experience with the particulars of /bin/ln and Git and how repos get populated with a default .git/info/exclude.
> My comment and the other replies show you how to use git
Oh, gee, thanks!
I don't know you think that will do or how symlinks work, but it won't lead to anything relevant to this discussion. (To answer your question: no.)
That's because the original sin of GitHub "wikis" is that they weren't (and most of them still aren't) even wikis. There's this perverse thing that happened during the wiki age, where people unable or unwilling to get on board decided to just start calling things "wikis" even though they exemplify the very thing that the wiki was invented as a response to. The reckless debasing of the word then infected adjacent spaces. Sourcehut's "read-only wikis" (wat) aren't even designed to be edited in the browser; on Sourcehut, "Publishing your changes is as easy as committing them and pushing them upstream." Newsflash: That's not a wiki.
This is both true and also if followed would fly in the face of what XMPP (and the Mastodon-flavored ActivityPub-powered fediverse of microblogs-and-more) is supposed to be about. And it's also both true and yet people understand what "email" means and how to use it without constantly and consistently running into issues trying to bang out a reply to alice@gmail.example even when the sender's inbox is hosted @yahoo.com—nor do folks spend much time thinking about how and why AT&T's SMSes (for example) are able to make their way to their friend's device even though they use Verizon (to give another example—and if they even know which provider their friend uses at all).
One thing that Jabber (and, later, Mastodon) did wrong was to take the unfortunate stance that it wouldn't be too big of a deal to adopt email-like identifiers without actually being email or implying that Internet-standard email services are available; it was felt that users would just be smart enough to adapt to it. This was a mistake.
The confusion with email, though, can be exploited as useful momentum—something that the network has going for it, instead of a flaw.
If the author and the rest of the Jabber/XMPP community wants the public to "give Jabber/XMPP a shot", then it probably does need (a) a flagship instance (a la mastodon.social) that controls multiple domains (the way that many email providers like Runbox or Fastmail do) and requires the user to pick which one they want their handle to be associated with at signup, in order to introduce email-like decentralization to the userbase as early as possible, and that (b) raises the bar by setting a standard among Jabber/XMPP instances and actually offering email services to that userbase (prior art: Google married (XMPP-based) Gtalk with Gmail in the early days).
While undertaking all of this, an effort to update the XMPP protocol (a la JMAP, but in a backwards-compatible way) while simultaneously reconciling it with legacy email (also in a backwards-compatible way) wouldn't hurt—where "backwards-compatible" here means "to gracefully degrade and provide a fallback" (prior art: Delta Chat).