cxr

> You're committing a fallacy here: You're assuming that not using the method/framework comes free or cheaper.

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.)

You're committing the very sin that the original article fingers as the problem with the webdev culture.

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)

HN is weird. My submission yesterday "Roku SceneGraph 2.0 SDK: Migrating to TypeScript" <https://news.ycombinator.com/item?id=50212170> (which also involves the not-inconsequential news that the new SDK is open source) is at least 10x more interesting but got almost no attention.

More info:

- 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>

> You can still setup the mirror and be done with it, and put the original repo links at the top in the README

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 fact that language designers take into account things like efficiency (or ease) of potential implementations doesn't change the fact that performance is a property of the implementation. Languages don't perform. There's no such thing as a performant language.

That's because there's no such thing as a "performant language". A programming language is inert. It's notation. The only thing that can be compared are language implementations. That a given implementation, such as the GCC backend, 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 has some inherent performance characteristics. Programming languages get run. The binaries do.

C programs compiled with GCC and LLVM are fast. The same program compiled with My Toy C Compiler with none of the work that has gone into optimizations is going to have different runtime characteristics.

When it comes to questions of copyright and the infringement of copyright, the small matter of whether or not infringement occurred is in fact not merely an inconsequential detail.

<https://en.wikipedia.org/wiki/Motte-and-bailey_fallacy>

I'm a big user and advocate of Zotero, but "it just works" is not a description that I'd say applies to it. It works kind of reasonably okay most of the time, and you get a feel for where and how you have to give a thump the times when it's not working the way it's supposed to, but it has its flaws. Unfortunately, it's also gotten harder to build, which means more difficult for people to get involved to contribute changes.

> It's baffling actually that Firefox doesn't let you annotate bookmarks, it seems such an obvious feature.

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.)

That's not the rub. We don't have to figure those things out here. The Photopea Offline repo that started this whole mess contains literal copies of the Photopea bundles/assets copied from the Photopea website.

> The vast majority of license violations are just MIT or ASL projects whose license text got stripped in the minified deliverable.

"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.)

> It's much simpler to update a webpage than force every user to update their app when something needs to change.

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.

> Or, you could have a build system that does a 100% out-of-tree build

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.

Fun fact: even though "There is no authoritative resolution mechanism for tags" and they're "not designed to support resolution", you're totally allowed to resolve them anyway. You can, for example, bodge your server to do it at the HTTP level:

    GET tag:[email protected],2013:15fb-4628-94d3 HTTP/1.0

    HTTP/1.0 302 I love you
    Location: https://example.net/~alice/2025/11/03/go-vote

(You can even respond to requests to resolve other people's tag URIs that you didn't mint. No one is going to stop you.)

Instead, the URL should lead to the actual label in vector format, and most elements of the design should be clickable links.

> Web Development (1994-2025) will be remembered like elevator operators.

Good.

This place being well-known now for the prohibition on "shallow dismissals", I think it'd be great if we brought back the rule against submissions that are merely "shallowly interesting" (which is frankly something that this, er... "performance"* doesn't even qualify as):

<https://hn.algolia.com/?q=%22shallowly+interesting%22>

* hard to read this characterization and see it as anything other than the product of unvarnished, I-want-to-believe (that emperor is wearing magnificent robes) hero worship

Boy, those pesky emotions! Surely that's the culprit here, and not self-assured HN commenters showing up to hand out /r/confidentlyincorrect-tier advice that still wouldn't address anyone's problem even if it did work.

Yeah, I don't know why you'd think, having taken care to add stuff to .git/info/exclude that doesn't belong in any commit that will make its way upstream (but nonetheless might be—and probably is—important work, maybe even the product of some non-trivial effort), that what I'd want is for it to be wiped out.

And `rm ./.gitignore` will, predictably, leave the tree without a ./.gitignore (i.e., the desired state) whereas `git status --ignore`, uh, won't.

I know they aren't because:

> 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!

> So all your fellow devs do `ln -s contrib/gitignore ./git/info/exclude`?

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.)

Believe it or not, there are people whose interactions with software are not limited to projects that they wrote and have control over.

Oh, I can? Cool advice! How do I get the people with bad hygiene that we're talking about to follow it?

(You have lost the plot; your response amounts to explaining how soap and water works to someone who has just described their office mate's tendency not to shower.)

I've never seen a .gitignore that was justified, ever. It probably shouldn't even exist. I've run into projects often enough with horked build scripts or bad docs about build pre-requisites, where upon failing partway through and necessitating some fix, the build failure leaves the tree in a state where it still won't build successfully even after fixing the thing that caused the original failure. The only fast fix is to rm .gitignore, then look at the output of git-status and rm -rf all the crap that it shows the original build attempt splattered everywhere before re-running the build script for a third attempt. Thanks, .gitignore.

.gitignore is banished in every project I'm in charge of. Everyone is required to manage their personal .git/info/exclude themselves, and any changeset attempting to slip .gitignore into the project will get ipso facto rejected. (Anyone is free to submit a change that adds a file contrib/gitignore if you think you have a set of useful globs relevant to the project that will be a help to others, along with instructions to cp that file to .git/info/exclude, but .gitignore is not making it in.)

Git needs to ship a git-ignore command (or extend git-config) that exclusively works by managing .git/info/exclude for you, including converting "legacy" .gitignore into the less anti-social version.