In the Lesson “Sort an array…” from the “Functional Programming” course from the JavaScript certification, we can find this tip:
“JavaScript’s default sorting method is by string Unicode point value, which may return unexpected results. Therefore, it is encouraged to provide a callback function to specify how to sort the array items.”
I gloogled what was the complexity of the sort() function and this site: Time & Space Complexity of Array.sort in V8 says that, if no callback functions is provided, sort() makes a timsort. But, if a callback function if provided, it makes something similar to a bubblesort, which is much less efficient than the timsort.
My question is, wouldn’t it be better to use sort() with no callback function? At least in the case of sorting strings with no special characters, and integers?
If you are worried about speed, JS is probably the wrong language. In theory, using a callback function when you don’t technically need one may result in slightly slower code, but in practice it isn’t really noticeable.
Thank you for your answer! Now that you say it, I’m not really worried about speed. But, if I were, which would be a better languaje than js for front end development?
Well, theoretically any language can compile to WASM, which allows for control over memory layout, but you have to be very careful about what you’re trying to make quick. The only data type WASM allows is numbers. Those technically can be mapped to most data types, but in practice you only really want the WASM parts to be numeric/binary processing code (anything else isn’t likely to be faster, and in many cases will be slower).
Even with that, at the end of the day you only have one language you can use for frontend development. That’s JavaScript. No other language will work. WASM allows you to compile code to a very low-level subset of JS that executes in a sandbox, but it still has to work via JS bindings, and WASM is in its infancy.
It the same as most languages: you can write things in C or similar, and you may be able to write code that executes very quickly, but then you have to handle building that code plus the orchestration between that code and the host language plus guaranteeing that the host language hasn’t already done what you’re trying to do within its VM plus guaranteeing that the overhead of calling into your foreign code doesn’t wipe out any gains you get from it being fast.
What are you.doing that requires the large complications involved in integrating a foreign language into JS code? There are many very good use cases, but “fast” is so nebulous a term – it’s almost meaningless. You have to have a good reason for saying “I want code that executes much faster than the optimisations JS that engines do already”
People worry far too much about efficiency in the beginning. In web dev, 99% of the time is spent just waiting for user input. And anything less than 1/10 of a second won’t be noticed. It’s like racing to get to the next stoplight faster, but you still have to wait for the next traffic light. There is coding where every single microsecond and every byte of memory counts, but rarely in web dev.
Make smart choices, but also don’t worry about efficiency unless it becomes an issue.