danvk

What about Object.fromEntries?

See https://github.com/tc39/proposal-array-grouping for why this isn’t a method on Array.prototype.

Thanks for the correction, Paul (and for the great email client and JS Compiler!). I've added a note to the article.

The focus on inlining as a performance win makes a lot of sense. It's hard to get back into the pre-JIT IE6 mindset where every getter and setter came at a cost. By the time I used Closure Compiler years later this had gotten simplified to just "minification good". I remember search (where I worked) in particular was extremely concerned with shaving bytes off our JS bundles.

Beyond that the branding is also confusing. Is it Closure? The Closure Compiler? Closure Tools? Google Closure? I used it for years and I'm still not clear which is right.

That is an interesting note (and news to me as the article author). Note that they used Closure in its "simple" mode, rather than "advanced", which is what the post is mainly talking about. I wonder if React still uses CC?

The lack of RTTI in TypeScript _is_ definitely a pain but the jump to "must use decorators" and "TypeScript is not a server language" is unjustified. There are many approaches to validation and RTTI with TS. For example, you can generate JSONSchema from your TS types (see https://github.com/danvk/crosswalk for an example of this approach) or you can use a tool like Zod (https://zod.dev/) to declare your schemas as runtime values and derive TS types from those.

Writing your backend in Java or C# comes with its own issues, i.e. you can't share code between backend and frontend.

I built something that sounds very similar at my last company called crosswalk. Open sourced here: https://github.com/danvk/crosswalk

One thing that worked surprisingly well: codegen TypeScript types from your database and use those in your API schema.

This is fascinating. It reminds me of the infamous MCAS on the Boeing 737 MAX. A system was designed, implemented and rigorously tested to be used in a specific scenario. A decision was then made much later to use it in a very different scenario without any understanding of the consequences.

Graphing Calculator was incredibly helpful for me when I was learning Calculus in school since it let me visualize everything I was learning interactively. Grapher just isn’t the same!

I'm curious about the results, but remember that this article is talking about the type declarations files that tsc has to read (.d.ts files), not the JS that winds up in your bundle.

Yes, the underlying issue has been resolved and so this should be a relatively easy fix for any project using `googleapis`.

It's not mentioned in the article, but we also added an eslint rule to ban importing `googleapis` so that this won't happen again in the future.

This is the size of the type declarations files (.d.ts files) that `tsc` pulls in when compiling your code. This is distinct from bundle size.

Tree shaking is a big win for bundle size. One of my big takeaways from looking at these visualizations is that we badly need an equivalent for type declaration files.

My understanding is that skipLibCheck skips _type checking_ .d.ts files, i.e. looking for type errors in them. But tsc still has to read those files since you might refer to their types in your own code, which TypeScript will type check.

Are the photons that land in between the instruments just lost? Why not make them cover more of the space?

Postponed by one day due to weather. New launch date is Christmas Day.

By default, Node has a relatively low limit on the amount of memory it will use (I believe 1GB). As you get close to this, it thrashes as it tries to garbage collect more and more frequently.

You can increase the limit by running `node --max-old-space-size=8192`. But that doesn't seem to fix this specific issue, either with the Map or the Object!

The 2012 article states:

> Specifically, we ran analyses examining whether the two conditions differed in the number of instances wherein reported odometer mileages ended with 0, 5, 00, 50, 000, or 500. Numbers that end with these digits indicate a higher likelihood that customers simply estimated their mileage. We detected no statistically significant differences between our two conditions in the instances in which these endings appeared (pooled measure: treatment, 19.9% vs. control, 20.8%; χ2 = 2.5, P = 0.12).

1. What does this mean? (“Pooled measure”) Wouldn't a mileage ending in 500 also end in 0 and 00?

2. If the numbers are uniformly randomly generated, shouldn’t the odds of ending in 0 be 10%, not 20%? Or is this an equal mix of fraudulent and real data in both arms?

Just curious because this is the one of the only bits of data for the fraudulent study in the 2012 article.

There are many forks of schemats out there that add various features. Here’s mine: https://github.com/danvk/pg-to-ts

It copies Postgres comments over to JSDoc/TSDoc comments, emits some data about foreign key relationships and supports TS types for json/jsonb columns via @type comments. Feel free to copy any of those feature if you think they’re good ideas :)

Why is it so important to express this as one SQL query? Why not just run the two simple queries? It feels as though two different types of things are being joined.

I’d love a tool (that’s not Acrobat) to manage comments on PDFs.

The longer I use React, the more I appreciate the power of being able to pass children to components.

Could you say a little more about the sort of project you’d use Alpine on? “filled a massive void many people didn't even know existed” is certainly intriguing!

Could this be useful for astronomers?

If you prefer the "or throw" approach to handling null values, you can write a little helper to get something like it in TypeScript:

    function assert<T>(v: T | null | undefined, message?: string): asserts v is T {
      if (v === null || v === undefined) {
        throw new Error(message);
      }
    }

    function parseFile(file: File | null) {
      assert(file, 'File must exist');
      // TS now infers type of file as File
    }

Check out the TypeScript 3.7 release notes for more on assertion functions: https://www.typescriptlang.org/docs/handbook/release-notes/t...

Can someone say more about the JavaScript optimization?

I've run into many more performance issues with editor latency (i.e. tsserver) than with compiling (tsc). Unfortunately, these tend to be harder to diagnose.

The worst turned out to be a crashing bug in tsserver that manifested as autocomplete and error checking feeling sluggish, I think because the language service kept restarting. It made me feel grumpy about TS for a month or two before I finally looked at the server logs (using the instructions on this page). That quickly led me to this bug: https://github.com/microsoft/TypeScript/issues/35036. Even though it took a while to get fixed, I felt immensely better that the problem was real, acknowledged, etc.

Nowadays my biggest performance issue is with the Material-UI typings.

I'm sad that JSONSelect (https://github.com/lloyd/JSONSelect) never caught on. It uses CSS selectors to query JSON, which has the nice side effect that learning to use it improves your CSS as well!

In case anyone is curious, this is a rename of PostGraphQL.

4/6 developers describe their desktops as "boring".

You can read more about this project on its about page: http://www.oldnyc.org/about.html

It's JavaScript, everything is a global! (so long as you don't declare it with var)