...is that the entire article? This reads like the thesis statement for a much longer article or book.
Readit Newsanonydsfsfs commented on Understanding "Financialization" and How to Defeat It apwu.org/news/magazine-ca... · Posted by u/qp11
Note, they also provide a one click link in the email to opt out, super easy
Still enjoying my sub $30 bills and bloatware free device
It's not one-click, or at least it wasn't for me. I clicked the link in the sentence "If you prefer to opt out of letting Fi use and share your CPNI with Alphabet and Google services, you can do so by replying here", and it took me to the Google Fi homepage. I had to then click on Settings, "Privacy & Security", and finally on "Allow CPNI Sharing". Four clicks total.
Deleted Comment
That's curiously the standard crackpot line. "They doubted Einstein! They doubted Newton! Now they doubt me!" As if an incantation of famous names automatically makes the crackpot legitimate.
The signatories on this are not crackpots. Hinton is incredibly influential, and he quit his job at Google so he could "freely speak out about the risks of A.I."
Whining about it on Twitter = free and easy
Suing Github = signing up for a ~decade long incredibly expensive and time-consuming legal battle against one of the richest companies in the world
There may be a slight difference in effort between these two options.
Not to mention Microsoft could countersue using their enormous patent war chest, which they have a history of doing[0]
[0] https://techcrunch.com/2012/03/22/microsoft-and-tivo-drop-th...
Tell me what I'm missing here - my project requires a download of N resources over N different hits to get them. Now in theory I host all my dependencies like css file, font-files, images and js files. Assuming I turn on gzip at my web server (nginx lets say) and I set up cache headers such that every resource file downloaded does not expire for 1 year, then the files download 1x for every initial page load. The first time is a hit not unlike downloading a decent sized image file which we all do without complaint on a daily basis.
Sure, I get it - a whole bunch of stuff has to come down before Document.onload() can be called and thats time from a JS perspective the user is looking at nothing. What I like to do is setup the default screen to be a fixed position blocking layer with my company logo on it and the last thing Document.onload() does is remove it. The initial load they see it for 1.4 seconds. Subsequent reloads from browser cache it's up barely long enough to notice.
So the problem of initial load is easily managed and not that big of a problem in the first place honestly. Simply setup caching on the web server to persist the files as long as possible ( I think a year is the max in most places now ) and problem solved right?
Now occasionally I run across some browser on some platform thats greedy about caching and refuses to pay proper attention to cache headers and replace them with newer versions when they come down. Its a little more of a pain but still well worth it to simply add a fingerprint to each remote resource fetched:
<link rel="stylesheet" href="/foo/bar.css>
becomes:
<link rel="stylesheet" href="/foo/bar.css?id=FINGERPRINT">
Now at build or deploy time I incorporate a little script that generates the current time in seconds and uses sed to replace FINGERPRINT with the current time in seconds (123888238823482834) such that browser sees:
<link rel="stylesheet" href="/foo/bar.css?id=123888238823482834">
This is a unique URL and forces the browser to pull down the new asset. This is easy to do with resources pulled down in the <head> section and more problematic with images however you just change the image name from "image" to "image_v2" on edits or changes and the problem goes away. Its easily enough done to iterate the image directory changing "*.jpg" files to a new version number and making the same replacements in html and js files if you really want to get tricky about it.
Now, new files are fetched one and only once per device and the page weight of a particular JS file becomes practically irrelevant.
Loading cached JS can still be very slow. https://www.webperf.tips/tip/cached-js-misconceptions/ has a good explanation of the bottlenecks involved.
> Subsequent reloads from browser cache it's up barely long enough to notice.
Are you measuring the time on your personal machine, or a machine that represents what your typical visitor is using? If you're using a recent Macbook, that's going to have very different performance characteristics than, say, an old Android phone. Something that's instantaneous on a Macbook could take ages on an old Android.
I am not familiar with this library, but if it does what it should then ofcouse is bigger, with react you just get a way to render divs and spans on screen, a GUI framework would give you say a DataGrid component with sort able columns and some advanced optimizations like windowing (aka a grid with 1 million rows will use same resources as a small DataGrid because it will only create enough DOM elements for the visible part and then recycle stuff).
JS devs that did not used Desktop or Mobile GUI tolkits have no idea what is missing in the browser.
> would give you say a DataGrid component with sort able columns and some advanced optimizations like windowing
react-data-grid is 13.8KB gzipped[1]. React itself is ~45KB gzipped, so that's ~60KB total, nearly half the size of W2UI.
edit: And if you want a full-fledged component library, you could also throw in react-bootstrap, which is <40KB gzipped.
[1] https://bundlephobia.com/package/react-data-grid@7.0.0-beta....
anonydsfsfs commented on Will Bun JavaScript Take Node's Crown semaphoreci.com/blog/java... · Posted by u/kiyanwang
The problem with stuff like introducing .env support out the box is breaking backwards compatibility in a silent way, ie without any code changes and in a way that'd still run the same in dev, and pass tests on CI etc, and then just affect prod.
I know this shouldn't ever happen, but you can well imagine plenty of legacy/badly configured setups where it would. More pertinently, where it would no matter how loudly you warn about it in release notes etc.
When you're as mature and used a platform as node, you just can't risk things like this, unfortunately, no matter how more convenient it would be for the vast majority of users.
Node already has a solution for this: core modules are prefixed with "node:" to distinguish them from third-party modules.
https://fusebit.io/blog/node-18-prefix-only-modules/?utm_sou...
Vim has been around long enough that I'd argue it's just as much owned by the community at this point.
I just checked the repo[0], and it says Bram has authored 95% of all commits to Vim. To say "the community owns Vim" when they've done ~5% of the work reminds me of group projects in school where one person does all the work and everyone else claims credit.
anonydsfsfs commented on Show HN: I ranked news websites by speed legiblenews.com/speed... · Posted by u/bradgessler
Yeah, same when I was working for Nature. Website was super fast, but then we had to load the (many) ad scripts that the sales team wanted and you’d add 2+ seconds to your page load time.
No way to win. At least I could wrap all the ad locations so they didn’t shift the page when they finally popped in.
I've been in the same situation, and it's one of the few times I've appreciated the bureaucracy and red tape that come with being at a Fortune 500 company. Whenever the sales team comes to me asking for another tracking pixel, I just say "We'll be happy to add this once you've submitted the necessary paperwork and it undergoes the the company-mandated security, privacy, and legal reviews". 90% of the time, I never hear back from them again.