| 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. |
" 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-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
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.