We started out not knowing what anything should look like, we didn't even know what computers were suppose to do. Everything had to be envisioned and implemented. Different approaches were taken for a lot of things. Eventually we just know how something should work. At that point it can be abstracted away.
Similarly lots of things should stay in JS. If we've experimented and evolved to the point where we know how something should work we should grow beyond modules and have build in methods for it.
It is happening but much to slow in my opinion.
Say, we have a Date API, are week numbers a thing or not? Are they an unpredictable poorly understood thing? Does it bother anyone if the API supports it?
Everything should be able to migrate up and down from the metal to the highest level of abstraction depending on how much we use it.
edit: There is no point shipping [table] sort magic to the client on every page view that needs it.
It seems like you're simultaneously saying "sorting doesn't belong as a language function in JavaScript" and "we shouldn't ship a sorting routine to the client," which seems...odd. If the page view needs sorting, then isn't that the use case where we can most say that there is, in fact, a point to "shipping sort magic to the client"?
(Also, you can do an HTML table sort in about 10 pretty short lines of code[1], so this seems like a kind of weird hill to die on.)
JS should have an array sort function. HTML should have sort-able tables. We know what they look like. We shouldn't have to pump up our pages with a bazillion lines of js just to implement something entirely obvious.
IOW: If there is a table it doesn't hurt to be able to sort it by default.
The example is great! 10 lines... no wait... 30 lines... then you have something that... or no wait, it sorts numbers alphabetically. The cursor is wrong. There is no accessibility. The little arrows are missing ▲ ▼ did I pick the right ones? They look bulky, better add another span inside the th? Oh I clicked the th twice now the text is highlighted.
Why should I need to implement this myself? I'm not inventing anything new? I don't want to be dealing with colspan but we all know how it should work? I know its wrong but I usually leave out the <thead>, tables render just fine without it but when something generates tables like that the script needs to be re-examined to figure out why it doesn't work. There is some unknown number of other ways to break it.
A default implementation could deal with some common units out of the box. Monday could go in front of Tuesday, 50 cm could be smaller than 1 m, $100 could be bigger than $20. Just the simple obvious stuff. For everything else something like <th sort="foo"> with: foo = (a,b) => a.length - b.length
List items are a bit less obvious but I'm sure we can think of something sensible. Perhaps sorting by child class?
We started out not knowing what anything should look like, we didn't even know what computers were suppose to do. Everything had to be envisioned and implemented. Different approaches were taken for a lot of things. Eventually we just know how something should work. At that point it can be abstracted away.
Similarly lots of things should stay in JS. If we've experimented and evolved to the point where we know how something should work we should grow beyond modules and have build in methods for it.
It is happening but much to slow in my opinion.
Say, we have a Date API, are week numbers a thing or not? Are they an unpredictable poorly understood thing? Does it bother anyone if the API supports it?
Everything should be able to migrate up and down from the metal to the highest level of abstraction depending on how much we use it.
edit: There is no point shipping [table] sort magic to the client on every page view that needs it.