untog

Rather than deal with hypotheticals, why don't we talk about the actual e-mails in question?

I'd suggest reading the e-mail thread regarding the article:

https://greenwald.substack.com/p/emails-with-intercept-edito...

The editor in no way seems compromised to me. There's a lot of very clear, straightforward and polite feedback. I suspect what we're seeing in the statement is a great deal of frustration, which is perhaps not surprising.

edit: never talk politics on HN, how many times must I tell this to myself

Yeah but then you have to use XSLT.

(Jokes aside, I tried this years ago hoping for it to be a magic bullet. Gzipping meant that the bandwidth savings weren’t anywhere near what I hoped and XSLT is a PITA to deal with)

Strongly agreed that service workers have a ton of potential here. But I’m still waiting for there to be some kind of killer framework that crosses the bridge between worker and window, saving lots of main thread processing, etc... MessageChannels are quite low level so I imagine it would need some abstraction. But still, very powerful. I’m imagining some kind of Svelte-like thing that creates the whole page worker-side, then generates minimal window-side JS to hydrate the components that’ll actually change. Of course I’d make it myself, but... oh, look over there...

(IMO they should still be called local servers, or server workers perhaps. Service worker is too vague)

The promise of streaming was releasing us from bundled cable TV contracts and letting us pick exactly what we wanted to watch, paying for it and nothing else.

We came close for a time, but I think everyone realised it wasn’t what they wanted after all. You could buy standalone episodes of a ton of shows on iTunes, but the calculus changed: sure, you enjoy watching Wheel of Fortune, but are you really going to pay a dollar for every episode?

So I like Slack, the chat platform? I don’t. Do I like Slack, the Mac app? Honestly it’s fine. My problem isn’t with the app, it’s the amount of attention I have to give it. Making it native wouldn’t improve that.

> People uses Macs because they want to use Macs and software that takes advantage of the reliability and consistency of that ecosystem

ehhh. I think if you did some analytics of “apps Mac users use” an absolute ton would be “a web browser and very little else”. I can think of very few truly native Mac apps I depend upon and that keep me on the platform.

What does keep me on Macs is that every now and then I need to compile an iOS app. Apple give me no choice. Aside from that I’d say a lot of developers choose Macs because they’re the least worst POSIX platform, not because Mac native apps are a shining beacon on a hill.

I still don’t think the vast majority of users care. Slowness is something separate and I’d agree that a laggy interface is an awful one, especially with a visual tool like Sketch. But I don’t think I’ve ever heard anyone make that complaint about Figma.

It doesn’t answer how Twitter can be so bad at this, though. Looks like a like of us have experienced this for a long time, I’m mystified why they wouldn’t fix the bug.

That presumes the story about the laptop is true. And a lot of details in the story don’t quite make sense.

But still, how is Twitter even supposed to judge whether a story is trustworthy? No clue.

My laptop is festooned with a hub. It covers power, peripherals, HDMI and networking. And that’s all I need. So really not very different to a desktop, except I can also pick it up and take it with me if I want.

Nate was the outlier in that respect. But it’s true that the polls aren’t weren’t all that inaccurate in 2016: a bunch of important swing states were within the margin of error and Trump won some important states by very small margins.

The mistake in 2016, IMO was a) the extrapolation that came from those polls and b) people paying way too much attention to national polls, which have very little connection to electoral outcomes, given the electoral college.

Also perhaps c) the larger public not “getting” statistics in the way they’ve been presented. The NYT had, if I recall, Clinton at 90% chance of winning. That still means that in one of every ten flips of a coin is a Trump win. But people read “90% chance” as “definite win”. I don’t actually know what anyone should or could do about that.

For sure. But JS is JS, and far more ubiquitous than Lua. So QuickJS still has a place.

OK, to be clearer: almost all the libraries published to NPM that would use the functions in QuickJS’s std module instead use Node modules and there is no compatibility layer.

So yes, there are plenty of pure JS modules. But if you want to read a file from a disk you’re going to end up with a library that assumes you’re using Node.

QuickJS is a really, really interesting engine because it's only ~200KB. Fits a lot of cases where you want to add scripting ability but without bulking out size unnecessarily.

Unfortunately because it lacks stuff like JIT it'll never rival the likes of V8 in performance. But in terms of bang for buck it's unbeatable.

It has a very small standard library:

https://bellard.org/quickjs/quickjs.html#std-module

It would be enough for a good number of CLI tools, I'd think. But one big issue is going to be that every library on NPM is hardcoded to use Node's modules (e.g. fs) so you're not going to be able to use any external modules at all.

I can't say I've had that experience, I've never had YT music throw a video at me. I've seen them listed as results in searches though. The YT Music move annoys me more because it all just seems like such a dumb waste of time, and Google is making me think and expend effort to service their corporate nonsense.

(for me, I'm sticking with YT Music over Spotify because you also get a YouTube Red subscription, and no ads on YouTube is worth it for me personally)

I'd push back against "serious JS codebase", there.

Maybe it's just me but a monorepo with 180 packages sounds like a hole you've dug yourself into and you're propping yourself up with yarn.

I certainly don't think that anyone who keeps their packages separate (you could do that even within a monorepo, surely) has a "non-serious" codebase.

> seems, to me, to indicate some behind the scenes UUID tracking.

I don't know why. It's updating the URL so that if you copy and paste it'll show the receiver the same view you have as the sender. They just need to be using history.replaceState to do that, rather than history.pushState.

I doubt it has anything to do with that at all, that's not a performance intensive operation at all. Rendering a map, however, can be very performance intensive when done the wrong way, as I suspect it is being here.

Oh, I know. But once the option is available you can bet plenty will.

I'm conflicted about this. Being able to use two versions of React on the same page has a very obvious practical benefit for developers, but man does it feel like bad practise. Yet more JS dependencies you're forcing users to download and parse before your site is usable.

I guess the overall argument with React and download/parse times is long since resolved (broadly, people don't care, those that do use Preact or similar) but for me personally it still feels like a downer for the industry at large.

But only one of those assertions is actually backed up by evidence.

It depends how deeply you want to get involved in all this stuff. I used to have a Synology box and it was great in terms of plug'n'play: you set it up via a nice web UI and it... just works! It also has downloadable plugins/apps that let you bolt interesting functionality onto the NAS.

By comparison this Odroid box comes with Ubuntu preinstalled and that's it. Much more flexibility, but much more work involved too.

It's evidence that their policy is not to suppress conservatives, because conservative content is very obviously flourishing on their network.

> What am I missing?

I guess the incredibly long tail of JavaScript deployments. You could change the language today and it would take years for it to percolate down to all the deployments out there. By comparison a silicon change requires zero code changes and is entirely backwards compatible. Plus there's a pretty simple marketing argument: "buy our CPU, it makes commonly-encountered workloads faster", vs "buy our CPU, when everyone upgrades the platform they use it'll be faster"

> Showing "their algorithms and content-removal practices are politically neutral" is not an insurmountable bar.

It is when political appointees are the ones who judge if you've cleared the bar.

Well Rust's complication is memory safety and the lack of garbage collector. You see similar issues in a language like Swift, but Swift lets you create a memory leak very easily if you're not aware of the issues. Which can be fine when you're just starting out, you can always learn about it later. But Rust isn't so charitable: you must learn about memory safety upfront. The plus side is that it's significantly more difficult to accidentally create a memory leak.

Yes, I think for me Nim could be a great answer for when I want to throw together a quick script. Right now I'll often use JS/Node for that and I'm not going to switch to Rust because it'll take a lot longer to get a rough and ready script going.