Question: Should we be setting any ground guidelines for what a Data Driven implementation is?

[ryansolid]

I know this sort of thing has come up before (#230). But that's not my intention. When I first submitted Solid I did several things unknowingly mimicking the vanillajs implementation not realizing it was generally seen as bad form. They might not be the type of considerations a VDOM library would consider, but in the range of data-driven libraries perhaps there is something here that should be said.

Roughly I'm thinking:

1. A data driven library should provide at minimum:

   • mechanism to update data
   • automatically/manually trigger DOM updates
   • provide a mechanism or abstract complexity of reconciliation of basic template control flow (conditionals, loops)

2. An implementation should:

   • At any at rest view state should be re-constructable from data only. (Ie. any atom of state cannot exist solely in DOM nodes at rest)
   • Treat DIV.main as the mount/entry point. All DOM interactions within should be bound as part of the library's mechanisms.
   • Not explicitly exploit Chrome's unclear performance boost using requestAnimationFrame to clear rows.

Is calling this out unreasonable? Is this too restrictive or specific?

[ryansolid]

Similarly is it worth calling out reference implementations like VanillaJS, WC, etc.. since including them has value and they shouldn't be held to the same standards.

[Havunen]

Yeah, this is a fair point. For example DOMc has html hard coded in index.html

https://github.com/krausest/js-framework-benchmark/blob/master/frameworks/keyed/domc/index.html

So it does not need to create the DOM which is major slow down in JS API. This makes comparison difficult.

[leeoniya]

there are a lot of libs that are starting to get into questionable territory lately.

even for ivi, where @localvoid has historically held the philosophy of a straightforward, obvious implementation without "tricks" has drifted into using custom delegation logic and utilizing textContent pulled from the dom to improve ivi's numbers. :/

fundamentally it's still "data driven" but certainly not without "tricks".

https://github.com/krausest/js-framework-benchmark/blob/master/frameworks/keyed/ivi/src/main.js#L86-L97

[Freak613]

I'm totally fine to move reactive view into JS for the sake of consistency.

I just can't understand blaming with the words "hard coded" and "does not need to create the DOM".
@Havunen , can you provide some metrics that proves your point that inlined HTML provides any performance benefit for domc.
I'm sure you, ParseHTML page stage by no means can be faster than JS API. You can clearly see that by comparing domc and stage0, where latest does inline view into template element and then attach it to the dom. Surplus also proves that by recreating the view from scratch using just JS.
And domc doesn't show any exceptionable startup metrics that could be the result of so-called "trick".

domc was initially designed to work like VueJS, that has ability to reactivate the view defined in html. And it's not shortpath.

Talking about event handling in top's: Yes, I also feel strange about working with the DOM, especially after long discussion about how 'Selected Row' should not be implemented switching classNames on target elements.

[leeoniya]

can you provide some metrics that proves your point that inlined HTML provides any performance benefit for domc.

I think the benefits of having html on the page (or SSR) is in metrics that are not currently captured by this benchmark:

• First Meaningful Paint
• First Contentful Paint

since html parsing is done progressively (streamed as it's received over the network) it will outperform anything you do in JS (which must be fully parsed, compiled and executed before any painting can happen).

EDIT: the amount of html that's pre-rendered by domc is pretty tiny and the real-world effect may not be noticeable. but if you pre-render 1,000 dom elements, then the benefits become very obvious.

[Freak613]

Thanks, @leeoniya ,
Yeah, that could be reasonable.
I just ran Lighthouse and got following results:

• domc(inlined HTML) - FMP/FCP - 1.9s
• stage0(parsing from JS) - FMP/FCP - 1.9s
• Surplus(classic DOM API) - FMP/FCP - 2.0s

stage0 performs same as inlined code. Therefore, I can't say that inlined html is always faster.
I hardly believe that loading prerendered page with 10k rows could be much faster than generating it from JS.

Though I'm fine to move view into JS, I still see no signs that it provides any meaningful benefit over other solutions to be able to say that it's making comparison difficult. I'm not stating that SSR provides zero-benefit, but looks like those benefits are hard to argue.
I think all parse-through-template solutions will show no difference in performance. At the end of the day, it's still parsing, no matter how it's done.

[leeoniya]

stage0 performs same as inlined code.

for a tiny dom, sure.

I hardly believe that loading prerendered page with 10k rows could be much faster than generating it from JS.

you should try it, especially on a throttled connection and cpu ;)

I'm not stating that SSR provides zero-benefit, but looks like those benefits are hard to argue.

there's quite a lot more that can be done during stream-parsing of html. for instance, images and fonts can start to be loaded in parallel, etc.

[Freak613]

Yes, I just built 1k prerendered domc page(without JS) and stage0 that runs 1k run on load.
Here are results from Lighthouse with "Fast 3G, 4x CPU slowdown" settings.

• SSR - FCP/FMP - 3.3s/3.4s
• stage0(from JS) - FCP/FMP - 1.9s/2.0s

I got literally same results with "No throttling" settings. And that's because benchmark server doesn't perform gzipping, therefore placing any SSR solutions in bad position.
Again, as I said, it's very hard to argue about SSR performance benefits, as it requires very good tuned environment with server setup, that is not the case in this benchmark nor to say that it does something dirty and makes comparison difficult. And domc doesn't perform any kind of SSR, instead of 'reactivating' the view.

Edit: Actually, I just figured out that Lighthouse stated throttling in Runtime settings, despite that 'No throttling' setting. That's why I have same results.

Edit: I was able to run benchmark's http-server with -g flag to serve gzipped content and perform page gzipping using standard Mac gzip tool, making the page size down from 294Kb to 2.2Kb
And tests with throttling showing:

• SSR - FCP/FMP - 1.9s/1.9s

Making it still hardly noticeable from performance perspective.
And all that without view rehydration, that will add additional cost as JS probably should perform dom walking and setting up environment for reactivity.
Maybe we just discovered dirty SSR truth :)

[leeoniya]

when i have some time, i'll try to set up a proper test on my linode/nginx server (http2) with domc/1k and 1k pre-rendered static html. then run both variants through https://www.webpagetest.org/ with these settings:

[localvoid]

@leeoniya

even for ivi, where @localvoid has historically held the philosophy of a straightforward, obvious implementation without "tricks" has drifted into using custom delegation logic and utilizing textContent pulled from the dom to improve ivi's numbers. :/

I just gave up convincing everyone to remove all this BS[1][2] from their implementations. I've tried :)

1. surplus
2. solid

[ryansolid]

I made the comment about the entry point in respect to domc 0.0.2 implementation since it didn't use template parsing to bind top level event handlers. The current implementation does not have that issue. I actually don't think the way domc currently works as a particular advantage. Maybe in terms of lines of code or memory, but it still has to parse over the template. The per item template gets rendered then removed to be cloned for each iteration. Depending on the implementation this can be more visible and expensive especially on large complex pages. There is a big difference between this and SSR which pre-renders. It's actually usually a challenge for libraries to do this sort of parsing to do SSR since they expect the child render context to be the template and once rendered the templating information is generally lost. That being said SSR has big benefits for first paint, and depending on the diff mechanism clientside hydration can be more performant than the type of parsing/reconstruction domc is doing.

But this is exactly the sort of discussion I was looking for. I do feel that a number of people consider something like React the baseline here. Even React and Angular sort of share some commonality in that React based it's original viability off the fact that Angular's digest loop wasn't really any more efficient than redrawing everything (in VDOM) and diffing. They both were fundamentally large central loop driven and top down.

Not sure if everyone is familiar with KnockoutJS but it was an early pioneer for data driven client side (c. 2010). It introduced the concept of ViewModel which differed from the controller based MVC of the time in that VM's are instances much like Components. It was the first "Just a Render" library with MV* in mind and didn't concern itself with Model/Store implementation or even how you sliced up your ViewModels (Components). It has custom directives, an extension system, and disposal hooks. It does the same real dom parsing domc does. It's core is event driven rather than scheduled.

In many ways it was way ahead of its time, and solved a lot of the same issues that React "revolutionized" nearly 4 years later. Vue's early design, Riot.js and a number of other libraries were inspired by KO. Over time there wasn't much innovation in this approach and times moved on. But it is a perfectly valid approach to data driven implementation. I submit this as another baseline for expectation of data driven library.

I honestly don't see what the whole concern is with event delegation. Here's a whole official documentation page from Knockout.js on event delegation. To take this further having had to hack this for React, most libraries that auto do event delegation are broken by the Shadow DOM. With Solid I actually did attempt an automatic syntax(precompiled) and directive mechanism for this before realizing not only was it more convoluted, but it was an unnatural fit. I looked at Inferno and a couple other libraries to only come to the conclusion it was an example where the solution was worse than the problem.

[Havunen]

I believe in real applications people dont host their event listeners outside the component either so why here? In my opinion that is a task for the library to handle and then keep the application implementation simple.

Also in early days this benchmark had React version where was one table and then each row was a component. Now the component is no longer there in many benchmarks. I understand that all libraries here dont have components in them, but why do we keep components in React then? Somehow I feel like the improvements and optimizations should be done in libraries and not in the app layer.

What about correctness vs the speed? We could implement basic swaps / test cases before the test starts just to see it works as expected, we could port those from React/Inferno/Ivi repo. Also what about errors? Previously Inferno did not have any fallback behavior If application encountered ja exception in the middle of render. All your future renders would be stuck and application jammed for that vNode tree.

[localvoid]

If application encountered ja exception in the middle of render. All your future renders would be stuck and application jammed for that vNode tree.

Bugs aren't recoverable errors, there shouldn't be any future renders.

[Havunen]

@localvoid
Imagine following:
You render vNode tree which contains a button that fails. Ok. Then your end user goes away from that page and you render another vNode tree on top of that, InfernoJS will handle it and not fail here. But this comes with cost of marking all vNodes during keyed, non keyd algorithms

See code:
https://github.com/infernojs/inferno/blob/master/packages/inferno/src/DOM/patching.ts#L477

Also I started wondering how do these libraries handle vNode hoisting, this is also a cost that Inferno and all inferno like libraries should do. Imagine you hoist a vNode and add it to multiple places in your application, in InfernoJS we need to clone the vNode or application might fail to runtime error. This is also done for all vNodes. Lately it was optimized to use bit for detection but because JS its still semi expensive.

https://github.com/infernojs/inferno/blob/master/packages/inferno/src/DOM/patching.ts#L472-L474