rtsao

I've heard of `isolatedDeclarations` in TS 5.5, but this post left me with more questions than answers because it conflates so many distinct things (TS 5.5, Deno, JSR).

I'll try my best to break it down succinctly:

1) Historically, .d.ts generation is slow because it requires the full TypeScript type checker in order to correctly handle all cases (e.g. exported functions with inferred return types)

2) However, if types were to be fully explicit, then .d.ts generation could be performed without a full type checker (i.e. by a faster compiler via mere syntax transformation)

3) The isolatedDeclarations flag causes the TS compiler to trigger errors when any exports would require inference in order to generate .d.ts

4) Thus, the isolatedDeclarations flag can be used to guarantee compatibility with faster, simpler .d.ts generation using syntax-based transformation

5) A consequence of simpler .d.ts generation is that it can be trivially done in parallel, which can be helpful for large monorepos

Yarn 2.0 was ambitious, but in hindsight, it probably would have been better to make regular node_modules the default rather than pushing PnP and zero installs (and alienating most users in the process).

I think Yarn Berry with node_modules linker is strictly better than Yarn 1.0, whereas PnP and zero installs involve tradeoffs that might not be right for everyone. There's a lot of great design decisions in Berry that gets muddled with all the PnP-related discussion. I will say Maël deserves a lot of credit for driving corepack, which makes version control of package management totally seamless. It's always been a total nightmare but now it's shockingly easy.

The demonstrated software doesn't look too compelling (mostly floating 2D app windows), but I could see this becoming the ultimate learning/training tool. Interactive, step-by-step guides/instruction on how to do literally anything would be incredibly useful (play an instrument, vehicle maintenance, cooking, etc.)

If the hardware is sufficiently good, eventually the software will come, which is probably why this initially targeting the pro market. I'm skeptical the current frameworks make it easy enough to build quality AR apps, but hopefully the difficulty will go down eventually (maybe with the help of AI).

I recall many years ago Jonathan Hall (economist at Uber) describing a "traffic apocalypse" caused by empty self-driving cars flooding city streets. I think the notion was the operational cost of self-driving cars was so low that wasteful (empty car) usage would skyrocket without anyone directly paying the cost of time/road use. Today, the mean number of people per car on the road is at least 1, but with empty AVs that could plummet to <1.

I believe this scenario was discussed as an argument for congestion pricing, serving as a vital solution to the tragedy of the commons exacerbated by self-driving cars.

Automatic JSX runtime was added to esbuild in 0.14.51: https://github.com/evanw/esbuild/pull/2349

Your assumption is correct. Those docks are all based on the Goodway DBD1100 [1]. When I was researching which dock to purchase myself, I came across this comprehensive list [2] of Thunderbolt docks which was super informative.

[1] http://www.goodway.com.tw/prodimg/edm/DBD1100.pdf

[2] https://dancharblog.wordpress.com/2021/02/05/usb4-tb4-docks/

Uber | Senior Software Engineer | Web Platform | San Francisco

Help develop the foundation for all web applications at Uber! Our team builds and maintains the developer tools, infrastructure, and frameworks that underpin the broad web app ecosystem serving our users (riders, drivers, eaters, shippers, carriers, and our internal operations & logistics teams).

If you’re passionate about developer experience and would be interested in helping advance our React/Node.js/GraphQL stack, apply here: https://www.uber.com/global/en/careers/list/108634/

I think the fundamental issue plaguing virtually all forms of automatic release note generation boils down to the mismatch of audience. Commit messages and even pull request titles are tailored to be read and understood by other maintainers and contributors, who are likely to be familiar with internal details of the project. Clear and concise communication for this audience might mean using more specialized jargon or referencing implementation details.

By contrast, release notes are meant to be consumed by a much wider audience, who are chiefly concerned with the externally visible aspects of the project. Communication tailored to other maintainers (e.g. commits and PR titles) is rarely also optimal for this broader audience. This is why commit-based generated changelogs have a bad reputation: commits are meant for contributors—not customers—and thus tend to be useless.

This also explains why a good, dedicated CHANGELOG.md is usually so effective: unlike commits or PRs, it affords contribution authors a separate place to write for a broader, different audience. Another nice property of this method is the notes themselves within the CHANGELOG.md can be collaboratively reviewed and edited right within the context of the PR. This is a very helpful mechanism to ensure that release notes are high quality and to distribute the burden of writing release notes to those most familiar with the changes (as opposed to the person creating the release).

I think the ideal scenario is that on a per-PR basis, the "external" release notes are automatically scaffolded from existing metadata such as commits or PR titles (or even sophisticated means such as identifying which packages have changed or knowing if a breaking change has occurred as a result of type interface changes) which are later refined/edited during PR review. I think it would also be great if GitHub Releases themselves could go through a review process akin to PRs in order to help ensure high quality and facilitate collaborative writing of release notes.

There's also a substantial writeup on the architecture of esbuild in the repo [1]. It is definitely worth a read if you are interested in some of the inner workings of esbuild or are curious how various bundler features are implemented. High-quality, in-depth architectural docs for complex projects like this are exceptionally rare.

[1] https://github.com/evanw/esbuild/blob/master/docs/architectu...

It's great to see more tools adopting tree-sitter [1].

Having a (fast) single tool that can accurately parse most commonly used programming languages is incredibly useful, but it requires the maintenance of dozens of grammars, which is difficult without a large community effort. Hopefully increased adoption means more accurate parsers and support for even more languages.

Tree-sitter powers syntax highlighting on GitHub.com and (soon) neovim and OniVim 2. Hopefully regex-based syntax highlighting is a thing of the past soon. If you haven't seen the Strange Loop conference talk on tree-sitter [2] yet, it's worth a watch.

I think a Prettier-like code formatter using tree-sitter would be cool, both in terms of potentially broader language support and native performance.

[1] https://tree-sitter.github.io/tree-sitter/

[2] https://www.youtube.com/watch?v=Jes3bD6P0To

I hope this doesn't alter the current GitHub npm package registry policy where all packages must be published under a scope corresponding to name of the owning GitHub user/org. The resulting increased transparency and clarity of ownership will be great for the JS ecosystem.

The existing npm ownership model is markedly less clear and has led to several problems, including the transfer of package publishing rights to bad actors without anyone being aware. On the whole, npm accounts and orgs were always just an unnecessary abstraction that obscured the actual provenance of software, of which GitHub is the de facto source.

Did you evaluate TOML and if so, what were the drawbacks you identified for the workflow use case?

https://www.deconstructconf.com/2017/brian-marick-patterns-f... is an interesting talk on this topic, which is where I learned about Seeing Like a State. I've just finished reading the book and found the parallels between software engineering and the high modernist statecraft and agroeconomic policy discussed in the book to be quite striking. I thought the middle chapters were a tad repetitive, but overall it was a fascinating read and I would highly recommend it.

The Fusion plugin system is rather powerful and enables colocation of related/coupled code that would normally be spread across several places. For example, the Styletron plugin for Fusion (an integration for a CSS-in-JS implementation) will do several things:

* Wrap the application component tree in a React context provider component (which provides an instance that components will render styles into)

* On the server, extract rendered styles after SSR from provided instance and add necessary markup into the server-rendered page

* On the client, hydrate the provided instance from the server-rendered styles

* On the server and in development, set up a route handler that serves two assets, a web worker implementation and associated WebAssembly binary [1]

* On the client and in development, fetch and execute the web worker. Normally, this would be a somewhat difficult integration because of CSP-related issues with web workers, but because the plugin sets up its own route handlers, the requests will be same-origin, sidestepping most CSP issues that normally arise. Additionally, Fusion plugins can also modify response headers for requests, so if needed, CSP headers could also be set appropriately.

All the code to do this actually is related to a single concern, namely styling, but in a universal web app, such things typically requires the involvement of many different parts of the application lifecycle and both server and client code. Fusion plugins allow you to slice up the independent parts of your application logic in this fashion, somewhat analogous to how colocating HTML/CSS/JS for individual components in CSS-in-JSX is often much nicer than splitting apart component implementations across separate HTML/CSS/JS files.

[1]: This web worker generates debug CSS at runtime that maps rendered CSS to the source styled component definitions in JS using source maps, making it easier to reverse map the rendered CSS to the source CSS-in-JS when inspecting the DOM with the styles pane. https://github.com/rtsao/css-to-js-sourcemap

For folks who really care about performance, the easiest win is just switching to Inferno or Preact. You can pretty much leave your React code unmodified and get massive performance gains.

For fun mostly. It's a passion project I did in my free time. I wanted to dogfood ideas, experiment, and learn.

Yeah, media queries and pseudo selectors (such as :hover) are supported. These tend to be really important for critical CSS. Descendent combinators are possible but to a greater degree involve tradeoffs. I posted my thoughts on this on this issue: https://github.com/rtsao/styletron/issues/27#issuecomment-26...

Thank you! It was built with Styletron actually (you can inspect the source).

It was also built with the excellent Inferno.js [1] library to render static pages while also having a super fast full client-side app, kinda like what Gatsby.js [2] does with React.

[1] https://github.com/trueadm/inferno

[2] https://github.com/gatsbyjs/gatsby

You're absolutely right that you can do it with pure CSS. But doing a pure CSS solution usually involves some CSS methodology that you need to apply extremely strictly and consistently, which honestly can be a challenge, especially in large apps. Sometimes it's easier to just throw in a new selector at the end of your stylesheet and "make it work". Without discipline, things can get messy pretty quick.

The point of CSS-in-JS and CSS modules isn't that it's necessary, just that it makes avoiding these sorts of problems much easier.

Someone submitted a proposal on how to support descendent/child combinators. It's certainly possible, but I wrote a response on why it would would potentially involve tradeoffs: https://github.com/rtsao/styletron/issues/27#issuecomment-26...

I actually wrote a separate benchmark suite [1] that uses Paul Irish's pwmetrics [2], so using real Chrome to check render performance. From those numbers, Styletron performed really well in terms of time to first paint and time to first meaningful paint. But I didn't include it in the blog post because I wasn't sure how best to separate the transfer time factor (pwmetrics is set up to throttle network speed) since Styletron critical CSS was so much smaller.

[1] https://github.com/rtsao/styletron/tree/master/packages/benc...

[2] https://github.com/paulirish/pwmetrics

I think the argument is that separation of UI components is a more true "separation of concerns" than separating CSS, JS, and HTML.

The implementation of a UI widget is ultimately a combination of CSS, HTML, and JS which are coupled to some degree, so by colocating them together, the component is easier to manage. But to do this effectively, you need some way to get around the global nature of CSS. CSS modules and CSS-in-JS are means of achieving this.

A good blog post about this topic is: https://medium.com/seek-developers/the-end-of-global-css-90d...

Lerna [1] is very cool. I was firmly against monorepos, but the ability to easily manage and coordinate between individually versioned packages in a single repo is awesome. You get the benefits of a monorepo but also the benefits of small modules so it's the best of both worlds.

[1] https://github.com/lerna/lerna

CSJS author here, thanks for the plug! I think CSJS fairly unique in comparison to the numerous alternatives in that it:

1) Can be used without any tooling whatsoever. It's just plain JS.

2) Doesn't reinvent the wheel. You can use regular CSS (normal syntax, pseudo classes, media queries) and regular JS (variables, modules) together, allowing you to use the best of both worlds.

I loved the ideas behind CSS Modules but wasn't sure about the complexity of re-implementing a new module/variable syntax into CSS. Why not just use what is already provided in JavaScript?