- 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...
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.
""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.
Thanks for the read ! I didn't know svelt and it seems like it has solid motivations. I should definitely check it out.
I'm actually more of a preact fan and the community Jason Miller has created, their work have inspired me a lot in concern of front-end and javascript dev.
ctrl-f hook is effectively something that has to be considered when implementing such feature.
I'd argue that the list & search feature it self is hard, not as something to put on and program and get working, but as a user-experience and design perspective (I'd like to thank you about pointing that out by the way, I will definitely spend some time making sure it's there for my app)
The reason I can think of, is that we do actually take control over parts of the applications in a way that was not imagined when browsers implemented search function.
It almost feels like the "With big power comes big responsibility", but i don't like the word "power" in our case, so I'd change it to something alike to "With features that have extra consequences we need to have an equal amount of extra care to even considering them." as if it was hidden and we needed to understand the tool better to have it properly done.
I guess front-end dev is easy to get in and understand, but hard to master, and that could be why we end up with these rampant "half-done" apps that do not take those extra steps.
In the end, the rushed dev will probably just look to have it's app working and will not check these kind of "bugs" that have been caused by his decisions,
Tbh, without this discussion i'd probably have missed it too
- 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...