Should probably point out that the trending tag is targeted to you personally.
Like when people obliviously complain about seeing ads for 'gay sex' on Google not knowing it's targeted specifically at them because of their browsing habits.
I (straight man) keep seeing ads for feminine hygiene products, dildos, and sexy womens underwear. Also, ads for managing enterprise IT systems. I have no use for any of that stuff.
Maybe the targeting just isn't as good as the people selling their ad tech make it seem.
I don't use Twitter, I was talking about random web ads that I believe are served by Google (or companies that Google bought). Maybe they should fire half their staff too.
This implies that the algorithm identifies people who engage in leftwing politics and targets rightwing hashtags to them. I suppose that magnifies rage-engagement.
I was a (European) lefty my whole life. I lived on all continents for many years. Now back in Europe, I was shocked what the left has become. Full of bigotry and racism. I call it the “new left”.
Gladly, an increasing number of people seem to notice.
Trending/For You always has one rightwing hashtag on it, often repeatedly, no matter how matter how often I click "not interested"/"this is harmful" and add it to muted.
"not interested" doesn't seem to work for me at all, no matter how many times i click it the trend almost always just reappears on refresh, sometimes even higher than it was before.
Well, we could argue about the filter bubble and algorithmic amplification, which can be (and often are) terrible things -- however, as it stands right at this moment, as far as the individual is concerned, you can still, mostly, choose what you see -- the algorithm will just show you more of whatever you clicked, rather than trying to steer you to something.
The Algorithm is still arguably a terrible detriment to society at large, but I think one can still find use in twitter and see very little of what one doesn't want to see. That may cease to be true sometime, perhaps even soon, but it works at the moment if you are judicious with who you follow.
I’d say compared to other languages there’s been two big issues:
1. A not insignificant number of packages are either polyfilling things in browsers, or providing a consistent (or ‘isomorphic') API for certain things across both browsers and Node.js, or adding things that should have been in a standard library.
2. A lot of packages still seem to be distributed primarily as CommonJS and not ES Modules. CommonJS makes tree-shaking harder than it should, so it was often just easier to break what should have been a single library into many smaller pieces.
Hopefully in the not too distant future library maintainers get around to reading the Node.js docs[0] fix some of this.
My personal take having “grown up” with all of this - JS is one of the worst ecosystems for relying on external packages for everything. It’s more the culture than the tooling.
One of the things I love about Go is generally people are a little more forgiving to copying something around a couple times instead of making a lib for everything.
Go in particular has an amazing standard library and very clear guidelines on how to write code. JavaScript does not have either of those things so it promotes people releasing competing libraries with similar functionality written in various different styles.
Many a time I've forked a dependency for one reason or another, and kept it up to date with upstream. Sure, it's a few more steps to update, but allows for deep customizations without waiting for original authors to support it (if ever).
Another reason to fork/copy code, is that its development has ceased long ago. In that case, it totally makes sense to carry on the work, in-house at first.
Regarding the article, sometimes copying code keeps the entire codebase easier to understand and manage without having an external dependency.
I guess that's not impossible, but it seems to reinvent git submodules without the tool support I'd want, and I think explicitly depending on our fork of their library would be clearer and safer.
> explicitly depending on our fork of their library would be clearer and safer.
I complete agree. To temper my comment, I've seen plenty of bad examples of copying dependencies, bundling old un-updated versions, with undocumented changes. In such case, it's true that copying leads to a worse kind of dependency.
Inviting the question of why the culture hasn't sprouted a "package rationalizer" to produce a curated, tested, noise-filtered distribution of useful functionality.
Come to think of it, something that does for packages what jQuery did to bring (some) sanity to browser incompatibilities.
Because we can't even agree on whether React or Vue or Angular is best.
In fact this is the root of the issue. It's important to realize that `node_modules` for any project in Popular Framework X will be almost identical. Most of the packages are related to compiling, bundling, and the development environment and a small minority are actual client-side dependencies. Even the frameworks themselves are pretty light -- React has a grand total of 2 dependencies. It's packaging the entire toolchain that causes most of the bloat.
JavaScript is super popular and used by companies so there are lots of people releasing their own open source project in an attempt to hustle into a well-paid job by looking more experienced than they really are.
I'd say it's the same reason why there are so many bad Java and Php tutorials.
C++ for comparison is shielded from this because it's not the kind of programming language that you would learn in a weekend seminar to improve your salary.
Other languages have for most part a good standard library. In C# for instance you can make a small/medium project with only a few third party libraries because the base class libraries (BCL) contains lot of data structures and classes used for common use case (encryption, unicode, file operations, etc.)
