HNHacker News
TopNewBestAskShowJobs

robpalmer

489 karma · joined November 6, 2015

submissionscomments
robpalmer··on Insights from Adopting TypeScript at Scale
It's more about setting up the guard-rails ahead-of-time to avoid falling into a hole, rather than getting out of one. We know the way to do this is to stick to standards like ECMAScript.

ES Modules are the glue that binds the whole JS ecosystem together. Whilst ESM is the standard, today a lot of people are using ESM only as an authoring format that later gets converted to CommonJS before being published or executed. Many of today's tools rely on this, meaning the ecosystem is partially tied to CommonJS. Migration is happening but it's slow and non-trivial.

In a way, we bypassed the CommonJS era and skipped directly from AMD to ESM. AMD and ESM are pretty much isomorphic and differ only in syntax. You just run a codemod to get from AMD syntax to ESM syntax - semantics are preserved. Whereas the step from CommonJS to ESM does not fully preserve semantics. CommonJS module initializers are always synchronous. ESM can be asynchronous - you can use `await` in the module initializer.

The article covers a few of the things we've done to retain a very standard ES Module system that is ECMAScript compliant. I think it is this pursuit of standards and desire for robust interoperable packages that led to some of the surprising discoveries.

robpalmer··on Insights from Adopting TypeScript at Scale
The TypeScript ecosystem is amazing - partly because of the large number of users also also because of the sense of community. It is run as a true OSS project. Roadmaps are release plans are all public on GitHub. Even as outsiders we've been able to contribute significant features, e.g. Private Fields in TypeScript 3.8.

https://devblogs.microsoft.com/typescript/announcing-typescr...

robpalmer··on Insights from Adopting TypeScript at Scale
Agreed. The article touches on this. When you have hundreds of projects that all target the same tightly-managed evergreen runtime, there's not much justification for having each project select and maintain a different toolchain. It just leads to the same problems being solved over again, and makes it harder for developers to switch between projects.

The fact that we can consider high-quality sourcemaps a solved problem (during both debugging and consolidated crash telemetry) really helps developers focus on building functionality rather than debugging a build system.

I think most large companies have dedicated tooling teams for these kinds of reasons. A related viewpoint in a related thread: https://www.reddit.com/r/typescript/comments/jrgi8z/10_insig...

robpalmer··on Insights from Adopting TypeScript at Scale
Yes - you deduced correctly!

There was a long period of parallel evolution. Over the last few years we've been able to get back on the standards track. The article describes this as one of the guiding principles. It's why we participate in TC39.

Nowadays our tooling stack now uses TypeScript, Babel, Rollup & Terser which I regard as the most mainstream of choices. And we go out of our way to keep things aligned with ECMAScript, e.g. preventing the use of "experimentalDecorators".

robpalmer··on ARM chips have an instruction with JavaScript in the name
What other numeric types would you like to see?

In addition to the existing doubles, ES2020 added support for signed integers.

robpalmer··on 0.30000000000000004
A new proposal for adding arbitrary-precision Decimal support to JavaScript is being presented at TC39 this week.

Proposal: https://github.com/littledan/proposal-bigdecimal

Slides: https://docs.google.com/presentation/d/1qceGOynkiypIgvv0Ju8u...

robpalmer··on Our Software Dependency Problem
Yeah, you see them all really easily here:

https://anvaka.github.io/pm/#/galaxy/npm?cx=-1345&cy=-7006&c...

robpalmer··on Network protocols for anyone who knows a programming language
That book is one of the most useful engineering books I have ever read. Top quality theory with practical application.
robpalmer··on Rollup now has code-splitting and we need your help
Rollup's strength is its simplicity and focus.

It splits a fine-grained module graph into coarse-grained vanilla ES modules with zero duplication across fragments and no artificial overheads, e.g. no wrapping internal modules inside functions, and no runtime loader infrastructure.

A simple idea done well.

robpalmer··on The rise and fall of Ext JS
I met Art, the Sencha CEO, back in 2013 after having some positive experiences using Sencha Touch on iOS to develop consumer-facing apps. He said that the company was going to solely focus on Enterprise because that's what the investors wanted.

At the time that felt like it signalled the death of the company. I note that the successful JS ecosystems we have today are not enterprise-only or consumer-only.

robpalmer··on TypeScript at Slack
Agreed. ES6 class syntax is superior to constructor functions and prototype mutation, because it's declarative and statically analysable.

I think the only legitimate reason left not to use ES6 class syntax is (for perf sensitive code) performance, but that's a negligible and temporary problem as the JS engines will fix that over the next 6 months.

robpalmer··on TypeScript at Slack
A codebase with no objects... I am guessing you mean no classes.
robpalmer··on Top-level await in JavaScript is a footgun
So the argument is that the bad-effects of top-level await are viral. One bad apple in the app entry point's dependency graph stalls evaluation of the main entry point. And to mitigate this risk, you have to segregate out sub-graphs that you safely load via imperative import().

Doesn't the same risk apply if one of the modules in the graph declaratively imports a module hosted on a slow external CDN?

← PreviousPage 2 of 2