[andrewfong]

At this point, I feel like the party best equipped to reduce JavaScript bloat are the web browsers themselves.

There's the obvious stuff, like simply blocking third party tracking JS.

There's some small quality of life bits -- a non-trivial number of websites load JS to make prettier UI elements (like a nicer date picker) because the defaults are so ugly (on desktop at least -- mobile tends to be better). If browsers shippednicer default UI elements, folks would be be less inclined to write their own using JS.

And then there's larger fundamental changes to the API themselves. If HTML6 included virtual DOMs or reactive primitives, that might reduce the inclination towards framework bloat.

[paulryanrogers]

> There's the obvious stuff, like simply blocking third party tracking JS.

Doubtful this will ever be a mainstream default. If by some miracle it did then I imagine CNAME cloaking or proxying via first party would immediately take hold. Not necessarily bad but certainly very disruptive to the status quo.

It's also not clear how browsers could do it. Do you prevent all network calls from scripts loaded from a 3P host? Do you similarly lock 1P scripts to only making network calls to 1P hosts?

[josephg]

> If HTML6 included virtual DOMs or reactive primitives, that might reduce the inclination towards framework bloat.

Please no virtual DOM. A virtual Dom is pure overhead compared to how svelte or solid renders.

But I’d be very curious about what proper browser integration would look like for reactive frameworks if you have an instinct for what better apis could look like?

[andrewfong]

By virtual DOM, what I mean is telling the browser I would like to replace the innerHTML of an element with another bit of HTML, and the browser should figure out an efficient way to "diff" the update rather than replace all the children wholesale.

It would not be as efficient as Svelte and Solid since those can use the compiler to further optimize code, but having the framework-less version of JS be "as good as" a framework like Vue or React would be a big plus for moving away from frameworks generally.

Apart from that, the general problem of reactivity boils down to "map this DOM element to this variable, and if the variable changes, update the DOM element". You could imagine an API sort of like this:

  <span bind-var="variableName" bind-gen="functionName">
    Default Value
  </span>

Where `bind-var` specifies a variable that, if updated, signals that the span should be replaced with the return value of the function specified by `bind-gen`

[josephg]

> By virtual DOM, what I mean is telling the browser I would like to replace the innerHTML of an element with another bit of HTML, and the browser should figure out an efficient way to "diff" the update rather than replace all the children wholesale.

Yeah, I know what you mean. And I agree that something like that could be faster than react if it were written in C++. But if we're going to bake something into the browser, I'd like it to be something good. The "Regenerate big chunks of HTML then do expensive tree-diffing operations" approach is, as you say, always going to be less efficient than how Svelte or Solid render. I'd much rather skip DOM diffing entirely and go straight to that.

> Where `bind-var` specifies a variable that, if updated, signals that the span should be replaced with the return value of the function specified by `bind-gen`

Nice - thanks for the example. I suppose the trick is implementing this in such a way that it doesn't depend on "watching" a variable in javascript. (Well, or we'd need to also add that as a feature to javascript - which would be a bit wild.)