I think that if I were doing this page with a clean slate I would

(a) Store all the items in an array rather than having to retrieve them from the DOM.
(b) Only call the server to obtain new items (rather than round tripping the whole page - which, I assume Michel is doing)
(c) Only update the DOM for items where the elapsed time has changed ( which, given that Michel seems to be doing this every second, should be very few items)

And for (c) ideally rely on something like angular to bind the field - that would automatically only update those items that were changed


>resolving complex selectors may be slow (jQuery's sizzle brought such progress that other libraries like Prototype have adopted it), .getElementById() is very fast (finding an element in an ordered list), and the DOM manipulation that the OP does is very simple (insert a text does not require a whole page repaint)
>
>The number of JS instructions executed really matters
>
>Anyway, testing rules.
>
>>Must admit I'm a bit vague on the behaviour of constants within a method. IAC I think the main cause of slowness will be in updating the DOM.
>>
>>Found myself wondering how an angular directive might fare in this scenario ?
>>
>>>Doing calculations in else definately is smarter, did not really look at code ;-)
>>>But I guess const being scoped for function level could lead to 1 allocation on "variable" stack of the fuction and perhaps 1 assignment on each run ( could be optimized away if each function as an object is considered an immutable object similar to strings in C# or Java runtimes, then const could be a RO property of the function similar to python "variables" in a dict of functon level) - hoisting the constant strings to an object or array outside the function and only accessing it should be minimally faster as this should provide a caching effect - even if variable lookup should take minimally longer as another scope has to be searched, it should be faster then re-setting the const in each function call.
>>>
>>>
>>>>>Something is very slow here if I have about 200 items on the page. I would have expected that to slow around 40,000. Anyone would have an idea on how to optimize this logic to avoid this javascript latency?
>>>>
>>>>Seems to me you are doing some calculations unnecessarily (e.g current date every time, hours, minutes and seconds when only day is of interest). Also I think the calculations themselves could be simplified. This looks shorter:

function SinceWhen(receivedDate, currentDate, language) {
>>>>            const ONE_SECOND = 1000;
>>>>            const ONE_MINUTE = ONE_SECOND * 60;
>>>>            const ONE_HOUR = ONE_MINUTE * 60;
>>>>            const ONE_DAY = ONE_HOUR * 24;
>>>>
>>>>            const SECOND = "second";
>>>>            const MINUTE = "minute";
>>>>            const HOUR = "hour";
>>>>            const DAY = "day";
>>>>            const NOW = "Just now";
>>>>            const YESTERDAY = "Yesterday";
>>>>
>>>>
>>>>        }

Not properly tested :-} Not dealing with the language issue (which could be handled in the getString() method) But I'm not sure it would improve performance - manipulating the DOM is probably taking most of the time.