What We Need Instead of "Web Components"

• observable

  9 514 8.2 Bikeshed

  Observable API proposal

  

> 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

• lit

  141 17,535 9.4 TypeScript

  Lit is a simple library for building fast, lightweight web components.

  

actually, looking at it (https://lit.dev/), i do exactly that.

I also define a `render()` and extend my own parent, which does a `replaceChildren()` with the render. And, strangely, I also call the processor `html`

I'll still stick with mine however, my 'framework' is half-page of code. I dislike dependencies greatly. I'd need to be saving thousand+ lines at least.

Here, I don't want a build system to make a website; that's mad. So I don't want lit. I want the 5 lines it takes to invoke a dom parser, and the 5 lines it takes do define a webcomp parent.

• SurveyJS

  surveyjs.io sponsored

  Open-Source JSON Form Builder to Create Dynamic Forms Right in Your App. With SurveyJS form UI libraries, you can build and style forms in a fully-integrated drag & drop form builder, render them in your JS app, and store form submission data in any backend, inc. PHP, ASP.NET Core, and Node.js.

  

• vanilla-todo

  4 1,122 8.4 JavaScript

  A case study on viable techniques for vanilla web development.

Thanks for this, gives my intuition some words to back it up!

I find especially compelling how the author separates concrete problems like reconciliation (hard to argue against) from the abstract principle of "everything should be a component" (can be argued more easily IMO).

Shamelessly plugging https://github.com/morris/vanilla-todo here; in this try-hard-to-stay-vanilla case study there are similar conclusions: Reconciliation is hard, CSS global namespace is problematic, etc. - I also did not use web components, but could not explain/justify that decision well (until now!).

• format

  19 1,901 9.5 C#

  Home for the dotnet-format command

  

C# has https://github.com/dotnet/format but because C# is, well, not JS, the importance of linting is far less significant. Instead, there are hundreds of out-of-box analyzers that highlight problematic patterns or likely mistakes in the code and there are even more that you can enable through extensions (like Roslynator) or through packages that are 'dotnet add package' away.

On the package management - it couldn't be more different between Java and C# and it's incorrect to compare the two. .NET has few if any issues of the former.

• community-protocols

  8 168 5.4

  Cross-component coordination protocols

  

> 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

• RxJS

  98 30,191 8.8 TypeScript

  A reactive programming library for JavaScript

  

> This proposal makes the same mistake as various stream implementations (including RxJS in the past) of making operators methods on the observable.

I don't think they are making a mistake. I am sure Ben knows what he is doing, given how it was he who refactored rxjs 5 with all operators being methods on the Observable, to rxjs 6 with pipeable operators.

But, their objective is not to bring rxjs into the browser, but rather to bring the Observable primitive into the browser. And, like Array prototype, which has methods, Observable, in order to be even minimally useful, needs some methods, which they modelled from TC39 iterators, for the sake of consistency.

They say:

> We expect userland libraries to provide more niche operators that integrate with the Observable API central to this proposal, potentially shipping natively if they get enough momentum to graduate to the platform. But for this initial proposal, we'd like to restrict the set of operators to those that follow the precedent stated above, similar to how web platform APIs that are declared Setlike and Maplike have native properties inspired by TC39's Map and Set objects. Therefore we'd consider most discussion of expanding this set as out-of-scope for the initial proposal, suitable for discussion in an appendix. Any long tail of operators could conceivably follow along if there is support for the native Observable API presented in this explainer.

As to

> We really need a `pipe` operator, at minimum

Maybe we don't. Note that in RxJS version 8, they have introduced a new way of piping observables, which is the rx function [0]. Maybe they are thinking of something similar for the browser. Or maybe they are thinking of using the native pipeline operator if it ever gets approved.

In the meantime, for any complex manipulations on observables, users will probably still import relevant functions from libraries.

0 - https://github.com/ReactiveX/rxjs/issues/7203

• reqwest

  57 9,130 8.9 Rust

  An easy and powerful Rust HTTP Client

• InfluxDB

  www.influxdata.com sponsored

  Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.

  

Suggest a related project