<https://news.ycombinator.com/item?id=2285569>

Submitted several times to HN since then. Most recently:

<https://news.ycombinator.com/item?id=16519132>

Double standard. If you're going to make a fair comparison, then you need to compare like with like; you need to compare the subset of things about e.g. HTML that give you what you can also get with a screenshot. It makes no sense to hold the performance penalty of script execution against browser runtimes when (a) you don't have to execute any scripts to effect anything that gives you parity with a static image, and (b) you can't with static images do anything like what executable scripts enable.

And whether or not parsing HTML is trivial (which is debatable), it's still not strictly greater than the computational resources that are needed for the kind of computer vision and widgetry that lets you e.g. select the text in a screenshot...

There's no reason to have a separate /archives resource and a /feed.xml (with or without content negotiation). You can just specify some external XSLT with an xml-stylesheet processing instruction in your feed XML that will cause the feed to be rendered nicely when it's opened in the browser...

So, yes, if you just naively write a bookmarklet that navigates to a new page with e.g. assignment to window.location and then expect any result other than the next line of code not executing, then you're going to be disappointed. You solve this the same way you'd solve it if you were writing an ordinary Web app--implemented in JS delivered by the server with script elements on your own page. Two stupid easy solutions that immediately come to mind: use XHR/fetch instead of actual page navigation; alternatively, have the bookmarklet open up a ~postage stamp-sized window with window.open that you can use both to output visible diagnostics and to keep the crawler resident (by doing all the work in the diagnostic window's context, which uses window.opener to control the initial tab as its puppet)... etc.

Why do people keep framing the story this way? Servo's future is in Gecko.

always_has_been.jpg

The Servo repo was a testbed that allowed people to work on new, Rust-based browser components without anyone having to pass the type of code reviews that are necessary for a production Web browser that is by the way already continually shipping to millions of existing users.

This (far too common) meme of Servo as a somehow failed separate browser engine that was supposed to, I dunno, be swapped out at some indefinite point and retire the lizard or something is very weird.

Wait a second, sure you can. Why can't you? Your example isn't as good of an example as you think. The rest of the people in the world can hum along on their current trajectory if they want; what do I have to do with the production of those electronics in the hypothetical world? I don't have anything to do with it in the world we're actually in.

jonah_hill_fuck_me_right?.jpg

(We don't agree on the appropriateness of the description that he "was involved", however. That sounds like an attempt to understate/diminish.)

Irrelevant. You're quoting docs.github.com, which is neither authoritative (docs are written to GitHub's documentation standards, not by their legal team), nor is it always up-to-date or well informed for the non-legal matters where it ventures to comment about the state of GitHub's products/services.

> that doesn't mean it's open source

Strawman. The question is "can you fork/copy?", not "is it open source?". The answer to the former is "absolutely yes, unequivocally". Anyone saying otherwise is wrong.