community-protocols VS esbuild

> except that "reactivity" does not meet the bar of developers collectively having landed on a solution to a common problem

Now that everyone seems to be in love with signals, there is work going on in the web components community group to prepare a spec for a signal (or observable, not sure what they are trying to call it) primitive [0]. It seems that they are getting ready to bring it to TC39 as a proposal.

(In the meantime, the Observable primitive from rxjs been given a go-ahead for browser implementation. There is a proposal ready [1], and I think I heard that it may already be in Chrome behind a flag [2].

So yeah; it's gonna be fun. Especially if both groups call their primitive Observable :-)

0 - https://github.com/webcomponents-cg/community-protocols/issu...

1 - https://github.com/WICG/observable

2 - https://nitter.net/BenLesh/status/1737174784406933599

The custom element spec definitely only deals with the mechanics of when are where to run your component's lifecycle code - it says nothing about data. So your choices are basically property accessors, which are interoperable, but require prop-drilling for global-ish data, or something proprietary like a state management library.

The Web Components Community Group (WCCG) is offering something of a third way with the community protocols: https://github.com/webcomponents-cg/community-protocols

The Context protocol provides tree-scoped ambient data in an interoperable way. It's implemented by Lit and FAST (I believe). It doesn't replace a data store, but it's often used to provide data stores to components, and at least reduce some coupling.

Did you know events can also carry promises? A great showcase of this pattern is the Pending Task Protocol by the Web Components Community Group. Now, "Pending Task Protocol" sounds very fancy, but really, it's just an event that carries a promise.

If you’re coming from the Angular world, you probably appreciate the great dependency injection (DI) mechanism they have. You can centrally define some services and reuse them across your app, without thinking about passing on props from component to component - the DI system takes care of it. Lit provides something similar via the [@lit-labs/context](https://lit.dev/docs/data/context/) package. It’s based on the Context Community Protocol and similar to React’s context API.

Fundamentally it is an event based mechanism to access state or "context" from ancestores of a component node. Based on the Web Components Context Protocol RFC which in turn is inspired by React's Context Api, the key purpose is to solve the problem of prop drilling.

The conversation led to the creation of https://github.com/webcomponents-cg/community-protocols. So there is some effort to standardize at least on convention for these higher-order considerations, but working through this and how opinionated it is made me recognize even more that this has a lot of similarities to a different group building a different framework. Tricky balance.

I’m pretty actively following a lot of the web components community so I thought I would jump in here with some hopefully helpful information. Depending on what you mean by SEO it’s worth noting that for a while now Google and I believe Bing and a few others haven’t had any kind of requirement to pre-render content. You can just serve standard web components or any kind of SPA style front end and it will get indexed just fine, no penalties and no real issues unless you’re doing something particularly strange.

However, one of the more exciting projects in the web components space (lit.dev) now also supports proper SSR as well which is a very new thing in the world of web components. They are trying to build it in such a way that any other library can take advantage of through a common interface.

In fact there are some kind of early stage talks happening over here https://github.com/webcomponents/community-protocols where a bunch of companies like Google, Adobe, ING and others are trying to develop some open protocols on a whole bunch of topics to improve interoperability between various libraries so that no one has to buy in 100% to any one setup.

At first we wanted to just get rid of all the helper utilities. Keep only the kernel, but this would mean a loss of backward compatibility. We needed some efficient code processing instead with recomposition and tree-shaking. We needed a bundler. But which one? Our testing approach relies on targets, not sources. We rebuilt the project frequently, speed was critical requirement. In essence, we chose a solution from a couple of among all available alternatives: esbuild and parcel. Esbuild won. Specifically in our case, it proved to be more productive and customizable.

During my search for deploying Lambdas via GitHub actions, I came across a tutorial that utilized ncc for converting TypeScript and bundling. While ncc is effective, I discovered esbuild, which proved to be significantly faster and perfectly suited to my requirements.

The advent of esbuild, the native support for ES Modules in browsers, the widespread adoption of import map, the emergence of tools like Native Federation, and the Nx ecosystem all combine to forge a flexible and well-maintained Micro Frontend Architecture.

EsBuild is a relatively new, blazing-fast JavaScript bundler and minifier. It stands out for its high performance, significantly speeding up the build process in development pipelines.

Unlike Webpack, the Vite DevServer only compiles files when they are requested. It leverages ES module imports, which allow JS files to import other files without needing to bundle them together during development. When one file changes, only that file needs to be re-compiled, and the rest can remain unchanged. Project files are compiled with Rollup.js. Third-party dependencies in node_modules are pre-compiled using the ultra-fast esbuild bundler for maximum speed, and they are cached until the dependency version changes. Vite also provides a client script for hot module reloading.

Use esbuild to build the React code into a form executable on both the server and client sides.

The functions will bundle using esbuild. For that, it is required to install esbuild globally:

TSX is the newest and most improved version of our ts-node, using ESBuild to transpile TS files to JS very quickly. The most interesting part is that TSX was developed to be a complete replacement for Node, so you can actually use TSX as a TypeScript REPL, if you install it globally with npm i -g tsx, just run tsx in your terminal and you can write TSX natively. But what's even cooler is that you can load TSX for all TypeScript files using --loader tsx when you run your file. For example, let's say we have this file called index.ts:

esbuild plus Vite is out of developer preview and enabled by default, yielding 67%, 87%, 80% speed improvements for build time, hybrid build time and hybrid serve time respectively.