10 ms·

This is how i manage more than 60,000 DOM nodes https://github.com/developit/preact-virtual-list https://github.com/developit/preact-virtual-list ; actually i t

This is how i manage more than 60,000 DOM nodes https://github.com/developit/preact-virtual-list https://github.com/developit/preact-virtual-list ; actually i think i could handle 600,000 and still have no problem.

Kuinox 6y ago
You just removed an usefull features from the user. The virtual list make ctrl+f not working anymore, and I hate every single react page using it. Suddendly, on this webpage using virtual list, you ctrl+f something, dont find it, because the element does not exist. A vue or angular manage your 60k elements list without any issue, you dont need to virtualize your list, and the search feature your your browser keep working. And if your don't use a virtual list, react get performance issues starts when you get only a few hundreds of elements and you want to filter them. Also, it start 'instantly' with other frameworks, not in 3 seconds, but below 500ms.
- krzepah 6y ago
  There is a find feature in the specs already. My users actually need to be able to interact with a lot of rows. I can just bind ctrl-f to my search feature. Also, it doesn't take 3 seconds to load but few ms as well. See, you don't just pick a tech, you need to start from the specs and get what the user need. Also, in pure HTML (because i tried it) ; the same rendering would be hanging anytime you try to act on something.
  - Kuinox 6y ago
    Now it doesnt work: - On mobile, using menu to search in browser menus. - When users use F3 to search, an alternative to ctrl+f. You added a few bytes to reimplement a browser feature, and spend time on a feature that already exist, because of your tech choice. There is still probably some accessibility issues. You can have easily 60k rows in HTML without any performance issue, you just need to pay attention...
    - krzepah 6y ago
      What are you talking about ? Are you saying a search feature is not necessary in my specs because you like using f3 or ctrl-f ? "On mobile, using menu to search in browser menus" -> This is not a sentence. I do add a "few bytes" to "reimplement" a "browser feature" ; but the reality is that i HAVE to implement search because it is hitting on 730000 per year records; How is you ctr-f or f-1 feature is gonna search on 2190000 rows in 3 years ? Again, you are too happy about your opinion that you spite it out like truth without even understanding specs. Specs is what allow you to understand what's required, it makes no sense what so ever to talk about technology without understanding WHY you use it in the first place. Is it meant for public ? employees ? How many rows do they deal with in their actual everyday workflow ? You are pushing your workflow so much that you don't even consider about your users and that's another red flag for me. PWAs have given so much in term of capabilities and mastery that I honestly wonder why I'm still talking about such things on HN while proper workflow about architectural design are ignored here.
      - Kuinox 6y ago
        ""On mobile, using menu to search in browser menus" -> This is not a sentence. " -> Sorry, I meant using the browser search feature by invoking it from the contextual menu of your browser, which is the only way to spawn the search toolbar on mobile. " but the reality is that i HAVE to implement search because it is hitting on 730000 per year records;" -> True, there should be a search feature with a backend API. "Again, you are too happy about your opinion that you spite it out like truth without even understanding specs." Yes I want too far, your use case does require extra logic, because it's not good to send that much data to the user. I'm not pushing a workflow, im not a front end dev, but i do maintain frontend apps sometimes, i'm simply angry at React, because it cause pain to me as an user. It's noticably slower (https://medium.com/dailyjs/a-realworld-comparison-of-front-end-frameworks-2020-4e50655fe4c1 https://medium.com/dailyjs/a-realworld-comparison-of-front-e...). The virtual list may be required for your use case, but as a user, I often met virtual list: - Used for less than 100 elements - ctrl f is not hooked on the 'webapp search feature' - the 'webapp search feature' is noticably slower than the browser. Also, here some reading, from a framework I don't use, about the virtual dom: https://svelte.dev/blog/virtual-dom-is-pure-overhead https://svelte.dev/blog/virtual-dom-is-pure-overhead Now, not as an user, but as a software engineer, my soul cry when I see the architecture principle of such a framework fixed with a workaround.

Kuinox 6y ago

You just removed an usefull features from the user. The virtual list make ctrl+f not working anymore, and I hate every single react page using it. Suddendly, on this webpage using virtual list, you ctrl+f something, dont find it, because the element does not exist. A vue or angular manage your 60k elements list without any issue, you dont need to virtualize your list, and the search feature your your browser keep working. And if your don't use a virtual list, react get performance issues starts when you get only a few hundreds of elements and you want to filter them. Also, it start 'instantly' with other frameworks, not in 3 seconds, but below 500ms.

krzepah 6y ago
There is a find feature in the specs already. My users actually need to be able to interact with a lot of rows. I can just bind ctrl-f to my search feature. Also, it doesn't take 3 seconds to load but few ms as well. See, you don't just pick a tech, you need to start from the specs and get what the user need. Also, in pure HTML (because i tried it) ; the same rendering would be hanging anytime you try to act on something.
- Kuinox 6y ago
  Now it doesnt work: - On mobile, using menu to search in browser menus. - When users use F3 to search, an alternative to ctrl+f. You added a few bytes to reimplement a browser feature, and spend time on a feature that already exist, because of your tech choice. There is still probably some accessibility issues. You can have easily 60k rows in HTML without any performance issue, you just need to pay attention...
  - krzepah 6y ago
    What are you talking about ? Are you saying a search feature is not necessary in my specs because you like using f3 or ctrl-f ? "On mobile, using menu to search in browser menus" -> This is not a sentence. I do add a "few bytes" to "reimplement" a "browser feature" ; but the reality is that i HAVE to implement search because it is hitting on 730000 per year records; How is you ctr-f or f-1 feature is gonna search on 2190000 rows in 3 years ? Again, you are too happy about your opinion that you spite it out like truth without even understanding specs. Specs is what allow you to understand what's required, it makes no sense what so ever to talk about technology without understanding WHY you use it in the first place. Is it meant for public ? employees ? How many rows do they deal with in their actual everyday workflow ? You are pushing your workflow so much that you don't even consider about your users and that's another red flag for me. PWAs have given so much in term of capabilities and mastery that I honestly wonder why I'm still talking about such things on HN while proper workflow about architectural design are ignored here.
    - Kuinox 6y ago
      ""On mobile, using menu to search in browser menus" -> This is not a sentence. " -> Sorry, I meant using the browser search feature by invoking it from the contextual menu of your browser, which is the only way to spawn the search toolbar on mobile. " but the reality is that i HAVE to implement search because it is hitting on 730000 per year records;" -> True, there should be a search feature with a backend API. "Again, you are too happy about your opinion that you spite it out like truth without even understanding specs." Yes I want too far, your use case does require extra logic, because it's not good to send that much data to the user. I'm not pushing a workflow, im not a front end dev, but i do maintain frontend apps sometimes, i'm simply angry at React, because it cause pain to me as an user. It's noticably slower (https://medium.com/dailyjs/a-realworld-comparison-of-front-end-frameworks-2020-4e50655fe4c1 https://medium.com/dailyjs/a-realworld-comparison-of-front-e...). The virtual list may be required for your use case, but as a user, I often met virtual list: - Used for less than 100 elements - ctrl f is not hooked on the 'webapp search feature' - the 'webapp search feature' is noticably slower than the browser. Also, here some reading, from a framework I don't use, about the virtual dom: https://svelte.dev/blog/virtual-dom-is-pure-overhead https://svelte.dev/blog/virtual-dom-is-pure-overhead Now, not as an user, but as a software engineer, my soul cry when I see the architecture principle of such a framework fixed with a workaround.