Skip to content

Note: View state on the model [sticky] #800

Open
@krausest

Description

@krausest
Owner

These implementations move the selected state on to each row. While this is a perfectly fine thing to do it changes the nature of the select rows test. Every library would benefit from it, so a note is added to the implementation when it is used.

The impact for react and angular can be seen in PR #799

Activity

hville

hville commented on Sep 30, 2020

@hville
Contributor

What about imposing an external Store that can be imported like @WebReflection did?
Similar to a standard vendor API, it would level the sources of variances and also reduce some of the maintenance efforts by making all examples shorter.

ryansolid

ryansolid commented on Sep 30, 2020

@ryansolid
Contributor

Some libraries (all reactive libraries) use special primitives to do change detection. These are mutable generally, so non-proxy libraries examples would need to map the data before use. If that was not done in the store you'd incur an additional mapping step. Unfortunately everyone of these libraries has their own primitives.

Libraries like Svelte and I think Fidan use a compiler to mask these reactive primitives which has restrictions to where these occur. These syntaxes don't differentiate between reading a reactive atom and reading the value it holds always compiling to the latter, in so only properly working within the local scope of their components. They have their own approach to stores but they can bring additional overhead. In Svelte's case introducing subscription based reactivity instead of their usually component based. It's like forcing React to use Redux.

In short I'm not sure doing so let's most libraries play to their approaches. Many benchmarks take that approach and completely alienate reactive libraries.

hville

hville commented on Sep 30, 2020

@hville
Contributor

But ultimately all data has to come and go somewhere and that cost has to be born at least on every upstream exchange. Not that I have a preference for this benchmark, it is all up to the goals and intent.

changed the title [-]Note: state for selected row is kept on each row[/-] [+]Note: View state on the model[/+] on Oct 23, 2020
ryansolid

ryansolid commented on Oct 28, 2020

@ryansolid
Contributor

@hville Generally speaking unless the operation is a full diff you only need to pay this cost on initial creation/load. Unless you are in the habit of repeately loading large data snapshots this never comes up again. You set the data up (one time cost) and from there end-user updates don't need to pay the cost. It's what makes this benchmark much nicer to work with than like dbmon etc which don't even attempt to simulate end-user actions.

If we prevent libraries that work this way from paying the cost upfront (which is their typical pattern) then they have to pay it on every interaction which basically negates their reason for existing since their creation cost is generally higher to optimize for updates. The whole purpose of these libraries is to trade CPU cost of Memory cost to improve update performance.

There are otherways for these sort of systems to achieve this with proxies but restricting it just forces those sort of solutions. While I'd say the majority of libraries don't work this way, there is still a significant number. I think it is probably just under 30% that do including Vue and Ember, among others. They have other means to deal with this but it can be a significant deoptimization.

pzuraq

pzuraq commented on Nov 8, 2020

@pzuraq

I just wanted to echo @ryansolid's concerns here, this is not just about using a better structure to get ahead. In cases like Ember and Vue, structuring state like this is conventional and a fundamental part of the framework as a whole. The fact that state management is deeply integrated into the view layer, and that the view layer can optimize for state without extra work done by the users of these frameworks, is a core part of their value proposition. The benefits users get from this include better performance out of the box. In fact, this exact issue is something we encounter frequently with new users of Ember, and the conventional advice is to restructure the state.

changed the title [-]Note: View state on the model[/-] [+]Note: View state on the model [sticky][/+] on May 2, 2021
added a commit that references this issue on Mar 13, 2022
added a commit that references this issue on Mar 14, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

      Development

      No branches or pull requests

        Participants

        @pzuraq@hville@ryansolid@krausest

        Issue actions

          Note: View state on the model [sticky] · Issue #800 · krausest/js-framework-benchmark