evmar

"TypeScript adds a great deal of complexity both in tooling and dependencies, and I do not think that it is worth it."

The subjective parts of that statement are the author's opinion and fine enough, but I am confused by the "dependencies" part. TypeScript is a single self-contained dependency. Especially in the context of the larger web ecosystem where to do almost anything else you do need a million dependencies, I find this remark pretty confusing.

I did a similar thing for Chrome back in the day, to have the compiler check an `override` annotation:

http://neugierig.org/software/chromium/notes/2011/01/clang.h...

Favorite obsolete tech story: a coworker's kid saw a 3.5" floppy on their desk and said "Cool, you 3d printed the save icon?"

devdocs.io is a dramatically faster alternative to MDN, with the same content.

My recollection is that the original prototype was written in Perl, but the oldest commit on github[1] is in C, which is still the language it uses today. The original C version had big contributions from someone other than Brad starting from the third commit (search the git commit log for 'avva'). Definitely still Brad's baby though.

(Disclaimer: I was an early, minor, contributor. It looks like the second commit mentioning me was to fix a bug introduced by my first one, whoops.)

[1] https://github.com/memcached/memcached/tree/32f382b605b4565b...

Your links appear to be 404s.

Regarding #2, if the class has any private properties (even if the classes have the same private properties) they are no longer assignable.

At runtime, TypeScript is JavaScript, so depending on your perspective either encapsulation is impossible (because you don't have types to defend you) or easy (because you use the patterns that JS has to defend encapsulation at runtime, without types).

Here's another opportunity to point out this unfortunate licensing bug in TypeScript's standard library:

https://github.com/microsoft/tslib/issues/47

(Disclaimer: I like TS, but I filed the above bug.)

As a person who doesn't use SO much, can anyone clarify why there's such a seemingly passionate community of people still around to discuss this after this mess? In particular, why do they continue to devote even more free labor to the business rather than just exit and go contribute to something else?

The next time you need to make an HTML treemap like this, try my tool: https://github.com/evmar/webtreemap

It provides a command line app that accepts simple space-delimited data and outputs an HTML file. See the doc: https://github.com/evmar/webtreemap#command-line

(It also is available as a JS library for linking in web apps, but the command line app is the one that I end up using the most. I actually built it to visualize binary size exactly like this post and then later generalized it.)

Previous discussion, leading with a comment from one of the protobuf authors: https://news.ycombinator.com/item?id=18188519

His "cost me $200m" is of a $20b company, so by the math he's suggesting he would've had 1% of the company after it went through all the dilutions on its path to $20b.

So yeah, if you have a chance to get nearly a cofounder's amount of equity in a company that will end up 20x a unicorn (which got that name because of how rare they are), then definitely go for it.

"cheap" in English means both "low cost" and also "low quality". To convey what I think you want to convey you could use the word "inexpensive" or "low cost" (but I also agree with the parent comment's advice).

So I think they are defining whether a given API as "open" or not as whether it is callable from JavaScript? So they're only willing to edit the JavaScript code, but not the C++ code alongside it? (I am genuinely confused by the reasoning, questions are not rhetorical.)

I have liked the other posts in this series, but I find the reasoning in this one confusing. (Disclaimer: Perhaps it is because I am familiar with the Chrome code.)

In the context of a browser fork, these statements make no sense: "Firefox has open APIs for everything the browser does [...] Chromium on the other hand does not expose certain areas that are sensitive to Google’s business." In the context of changing the source code, how are some APIs "open" and others not? How can the Chrome code possibly "protect" (their words) the address bar from modification relative to any other code?

I think what they're instead talking about is the available extension APIs from JavaScript maybe? But in that case, why call the project a fork, instead of a browser extension or something?

My goto project is a terminal emulator, for reasons I went into here: http://neugierig.org/software/blog/2016/07/terminal-emulator... (summary: it touches a surprising breadth of details!)

The 'git-subtree' tool (by the same author as this tool) can import subdirectories.

This post shows a Haskell-ish definition of Functor, then attempts to show the same thing in TypeScript.

    interface Functor<A> {
        map<B>(f: (a: A) => B): Functor<B>;
    }

But the TypeScript definition loses something important: the point of a Functor is that you get back the same data type -- there's one `f` in the Haskell defn both in the argument and return type, while this TS definition can give you back any random data type. E.g. the implementation of Array.map could give you back an Either.

I don't mean this comment to be a random nitpick of the post. Trying to think these things through is hard, and trying to use things you know to help understand the new idea is not unreasonable. But in particular with PL each thing has so much associated baggage (here in TS, subtyping) that reasoning "by metaphor" often means you end up missing the critical point.

Go has a compatibility promise from 2012 that they've upheld for now seven years. They are still discussing whether to change something in Go 2.

https://golang.org/doc/go1compat

Bazel has experimental but pretty sophisticated support for TypeScript, with arguably a better compilation experience for large projects than the best known alternatives. (Disclaimer: I'm biased because I work on it, but I also work on non-bazel TypeScript projects so I am aware of the tradeoffs.)

https://bazelbuild.github.io/rules_nodejs/TypeScript.html

Bazel is just the open source name of the internal Google build system, it is the same codebase.

Does build2 handle the case where code has

#include "foo.h"

and then, after a successful build, you create a new file named "foo.h" in a directory earlier in the search path than the foo.h that was used in the previous compile?

FTA: "For instance, if the company is worth $1m, and you are granted options on 1% of the company, then this basic model says that the expected value of the options is 1m * 0.01 = 10k."

The options are options to buy, so if you are granted 1% options of a $10m company your options are worth just above zero -- you can pay $10k to get $10k of stock back. You only make money if the company value goes up relative to your strike price, and the amount of money you make is proportional to that.

E.g. if the company literally doubles in value, you now can pay $10k to get $20k worth of shares. Only then do you profit the $10k in the above model. So the model only makes sense if you get in and the company doubles in value, and even after that you still only make $10k.

That is the answer, yes.

I wrote a post about how Chrome's Linux updates work:

http://neugierig.org/software/chromium/notes/2011/08/zygote....

(Sorry to spam this thread multiple times with this, but it is very relevant.)

Germane to this, the Debian package update model breaks both Chrome and Firefox:

http://neugierig.org/software/chromium/notes/2011/08/zygote....

Wow, why would you define it this way. I had to check the spec because I didn't believe you. They got #2/#3 backwards.

https://es5.github.io/#x11.13.2

I'm not at all surprised they wrote their own, because it's often the case that people have different use cases, design constraints and so on. I am surprised here that someone attempting to reduce the JS download bundle size after the fact didn't start by running the standard programs (uglify/terser/etc) used to reduce JS download size!

They mention (in https://www.mediawiki.org/wiki/ResourceLoader/Architecture#J... ) that even with the cache, they can't afford a stronger minifier.

Don't get me wrong, I really like the "just ship less code" approach to making apps fast. I am just shocked that running a processor on the code that they do ship to make it smaller was not one of the first things they tried. (Disclaimer: I work in this space and have even tinkered with writing such a tool. http://neugierig.org/software/blog/2019/04/js-minifiers.html )