New rule: Prevent direct DOM access

[krausest]

Please vote "thumbs up" for the formulation of the new rule that should be added to the benchmark or propose a better formulation:

[krausest]

Proposal 1:
The implementation must use only the idiomatic style of its library (e.g. direct dom access is not permitted).

[krausest]

Proposal 2:
The initial rendering must be able to render the selection state.
(Question: Is that sufficient to prevent reaching into the dom with the initial state?)

[krausest]

Proposal 3:
Don't use shortcuts in your implementation. Using explicit event delegation, manipulating the dom directly or using direct request animation frame calls are considered bad smells and may lead to rejection.

[WebReflection]

@krausest mind expanding on the explicit event delegation? Both lit/lighterhtml use the row to intercept once internal events, while hyperHTML, as example, places listeners right on the node that should trigger the action.
Wich implementation is correct, if not both?

[WebReflection]

P.S. I like all proposals but I'm not sure I get the last one

[krausest]

@WebReflection
The idea with event delegation came from #430, but maybe it's not really well put. I'd consider it an illegal shortcut if e.g. a react implementation used userland code to add the select row event listener to the table.

Maybe this way:

Proposal 4:
Use the idiomatic style of the library and avoid userland shortcuts in your implementation like userland dom manipulations, userland request animation frame calls or userland event delegation. These are considered bad smells and may lead to rejection.

[leeoniya]

yeah, there are a bunch of libs that delegate and dom-climb (in the impls):

https://github.com/krausest/js-framework-benchmark/search?q=parentNode&unscoped_q=parentNode

[WebReflection]

@krausest I like proposal 4 the most 👍

[leeoniya]

(e.g. direct dom access is not permitted).

this part is gonna be the most controversial. i feel like outright disallowing it is a bit heavy-handed, but policing the details gets messy in a hurry. with the right abstraction, it could probably be acceptable as long as it's generalizable for other applications and is uniform for create and update. for example, if the framework had a way to notify of the granular necessary textContent changes but left the actual mechanics down to a subscriber/driver. maybe if there is a framework that allows you to bring your own rendering driver. like if core React lib was the submitted lib and react-dom (the "driver") was just part of the impl.

[adamhaile]

This conversation has gotten so far into the weeds.

The point of DOM libraries is not to abstract all access to the DOM. It's to help people build useful apps.

There are lots of ways to do that. All have their respective pros and cons. Some people -- yeah, I'm calling out @localvoid here -- have gotten so far into the VDOM approach that they have tunnel vision. They demand that all other libraries adopt the same cons VDOM faces or they're "cheating."

I ask a library to do what it does well, and for the rest, to get out of my way -- which is to say, to interop with non-library code in predictable ways with minimal ceremony. The fact that Surplus (and lit-html) plays well with the DOM is a feature, not a bug.

(Aside: Web Components are built on DOM nodes as an API. If you put this rule in place, you're saying Web Components are wrong. Frankly, I agree that Web Components are a bad design, but not for this reason.)

None of us are doing original research here. All these approaches were tried in the last millennium, most in the 70s. If there was a clear winning strategy it would have won 30 years ago. Surplus is based on research done by INRIA in the 80s and 90s into declarative, predictable effects. It is idiomatic to work with the DOM API in Surplus, because Surplus intentionally makes it possible, and S computations let you do it in predictable and declarative ways.

/rant

I would propose a different rule:

Before submitting to this benchmark, please demonstrate that your library has been used to create realistic apps by providing a link to an implementation of either the realworld demo or an app of roughly equivalent complexity. Note: TodoMVC is not sufficient.

(Put-up-or-shut-up: https://github.com/adamhaile/surplus-realworld )

I think this rule would filter out a lot of the libraries that were built just for this benchmark. I support people exploring ways to achieve awesome performance, but they shouldn't be in the benchmark until they've proven they can build useful apps.

[WebReflection]

@adamhaile a repo called real-world doesn't mean every library is used in the real world. hyperHTML ships with ABP to million users and it's been used by W3C Respec for long time and I've never had the time, or the interest, to PR real world cause I've done all the others already plus the lib literally ships to the real world so your proposal is also kinda irrelevant.
Also worth saying that I agree many libraries are there to show potentials, even if experimental, but then again that's the beauty of this project, imo.
I do agree though, that there are too many entries so that maybe those about libs that haven't been updated in a long time should probably be removed as irrelevant/outdated, but even here I don't have strong feelings about it.

[WebReflection]

@leeoniya I think if the way of the library is to manipulate directly the Dom then let it be? This new rule purpose is more about avoid cheating for the sake of scoring.

[adamhaile]

@WebReflection Yep, the things you cite are exactly the kind of proof I was referring to. They show that hyperHTML is a mature and useful lib. I cited realworld as an example of a minimum requirement -- hyperHTML is obviously way over that. My comments were directed at some of the libraries that don't seem to have any use beyond submitting entries to this benchmark. Those libs should absolutely be implementing this benchmark for their testing, but I would argue that they shouldn't submit until they've developed the lib to the point that it can build useful apps.

[Freak613]

@adamhaile , correct me if I'm wrong,
But surplus-realworld has zero usage of manual event delegation or computation lifting, and can be considered as idiomatic implementation. You didn't used it there, but used it in the benchmark, for the reason.

It's not in the demo, because optimization requires additional effort to find tight places and apply fixes. You can say that in React, when we put sCU we also need an effort for that. But in React, sCU shows feature of the library itself, how it can address dataflow optimization. And as a bonus, we can port it to other platforms, and still utilize its benefits. S.js is the same, cause of data-centric approach.

Most of the libraries, if not all, have exit gates to the DOM. And if not Ref-s, access to event.target is possible literally everywhere. And easiness of porting this solution to other libraries demonstrates that this is not new/unique feature. It's not the feature of the library, it the feature of the DOM spec.
It can be okay if you go down to the DOM to apply additional logic to the element itself. But it looks "hacky" when you use it to build additional bridges to get around the view logic.

However, I agree about matureness requirement, other way the benchmark will soon be full of one-day libraries. And my libraries in this bench can be considered as that (if don't look at the numbers of npm downloads), although they're not using techniques described here, working in the designed way. That's what stops me from pushing any new raw libraries here, until I test it enough to decide that I reached sufficient functionality.
It's not clear how to define this matureness though, but good point to have it in mind.

I sure you, if we're thinking that manual delegation and lifting is best what we can, that's not true. It's limiting us. There should be ways to generalize such approaches, and instead of arguing about what level of workarounds is acceptable in this or other benchmark, it's better to face that there is no perfect library, there always be weak points and edge cases, and start thinking about how to fix that. Library developers should carry over as much complexity as possible, there was no VDom 10 years ago, but now it's here and it's helpful no matter how bad it is at some points.