- `document.querySelector` vs `$`. - `element.addEventListener` vs `$element.on`
JQuery really has some confusing behaviour too. JQuery sets the target of the event as `this` inside of the method. Native makes it an event property.
- `document.querySelector` vs `$`. - `element.addEventListener` vs `$element.on`
JQuery really has some confusing behaviour too. JQuery sets the target of the event as `this` inside of the method. Native makes it an event property.
Also some programmers opt for readabiltiy over terseness.
I've been changing my style to be more terse but that makes it more readable or easier to see the abstraction concept rather than the details.
I'd much rather read
rect = element.getBoundingClientRect()
area = rect.width * rect.height
velocity += acceleration * deltaTime
position += velocity * deltaTime
than r = e.g()
a = r.w * r.h
v += a * d
p += v * d
but to each their own.Google, Apple, Microsoft, Facebook etc all specifically say terseness is not a goal and say to use whole words so naming a function '$' would be explicity against their guidelines. I suspect there's a reason for that. The most obvious is I don't know what 'a' or 'd' or '$' mean without digging through the code but I do know what 'area' or 'detlaTime' or 'getElementById' mean
One of the reasons I like lisp-like languages more than the rest is because hyphen-separated-symbols are a lot easier to read than camelCase, which feels cramped by comparison. (underscore_separated_words is an improvement over camelCase, but for some reason people seem to shy away from it. In any event I think hyphen-separated is superior, since hyphens are used to conjoin words in English prose, while underlines typically aren't.)
It reminds me of reading 17th century dense English. I don't see how query or select is any less descriptive than querySelector.
I find that names are rarely all that useful anyway, since you can't capture the full effect of a function in a name in most cases. I once named a method mkdir() and then someone commented that it was "obscure", so it got renamed createDirectory(), then someone commented that it was actually creating all intermediate directories, so it became createDirectoryTree(). This still doesn't really communicate that it won't error if the directory already exists, so I commented it should really be createDirectoryTreeOrDoNothing().
`mkdir` is immediately obvious to someone like you or me that has a background in dealing with legacy system design (namely, any Linux/Unix/BSD/GNU system that all derives from early 70s design ethos (or hardware limitations..)) but to somebody who's not already steeped in this tradition, it's basically a bizarre incantation.
And mkdir is far from the worse of it; once you learn what it means it's easy to create a mnemonic mapping between `mkdir` and "m[a]k[e] dir[ectory]". But what about something like `ln`? Obviously that's "natural logorithm", everybody learns that in highschool. Wait no, it's not that at all. It's "[make] l[i]n[k]" Frankly, that's crap. Contrast with `make-file-or-directory-link` from racket. It means the same thing but it's more than 10x as long (less dense) and there is simply no way you could mistake that for a natural log function.
I don't think the problem with 17th century prose is density either. Rather, it's archaic vocabulary, idioms, and grammar. I've recently been reading through an anthology of English renaissance drama and my impression is that once you become acclimatized to the common archaic vocabulary and grammar, the idioms remain as biggest impediment to understanding. Consider:
> "Art thou in thy wits? I tell thee I must have a pair of shoes; dost thou mark me? A pair of shoes, two shoes, made by this very shoe, this same shoe, against tomorrow morning by four o'clock. Dost understand me? Canst thou do't?
He's asking for a pair of shoes, and questioning whether his request is understood. It's not a particularly complex or information dense paragraph, but it could be hard to understand if all of that archaic vocabulary is obscure to you. In many ways, this makes it very similar to your average bash script. Saying something simple, but made to seem complicated by archaic terminology.
Instead, browser have two incompatible APIs: `querySelector` to retrieve one item only, and `querySelectorAll` to retrieve multiple items.
On top of that, jQuery always returns an array-like object. `querySelectorAll` returns a NodeList that is so poorly designed that it didn’t have a `.forEach` for two years or so, and you’re still better of doing an `Array.from` on it for the sake of consistency and sanity.
For every thing that jQuery got right, browsers got 10 things wrong. For every thing that jQuery got wrong, browsers got 100 things wrong. It took browsers 7 years to implement querySelector/querySelectorAll after jQuery showed it’s possible and useful. And they still got it wrong. 13 years after jQuery debuted DOM APIs are still a mishmash of extremely poorly designed functions that are unnecessarily verbose and error prone.
`querySelectorAll` doesn’t even return an array-like object. It took w3c almost two years to add a forEach to it.
It’s also so badly designed that MDN docs has a whole section oh how it behaves with unexpected results and how, quote “to restore expected behavior”.
So all perceived benefits (like the separation between Element and NodeList) are badly contrived and trumped by how badly they are designed in comparison with a 15-year old library whose core API was designed by one person.
Similar in prose, if you can say it in 5 words, then why use a paragraph?
Of course, there is a sense in which lisp-like code can be dense while at the same time having verbose names for things. Consider this and an idiomatic C equivalent: (filter odd? '(1 2 3))
That is simultaneously intuitive and verbose. Would it be improved by changing `filter` to `fltr` or some nonsense like that? I don't think so. But even though it hasn't code-golf'd the names for things, it's doubtlessly shorter (denser) than the equivalent in idiomatic C using the mangled shortened identifiers that are par for the course in that language. Density through good abstractions is superior to density through short names and abbreviations.
Could you do both? Sure. But for what marginal gain?
* Variable argument types determine different kind of behavior, like ajax taking a string or object as 1st argument. Other functions take a function or string as a parameter. I'd much prefer it enforce a single style or define a new method, ajaxurl() and ajaxobj().
* naming of `off()`. In this context, off is not the opposite of on. On here means 'in event of'. A better word would be 'cancel' or 'mute' or 'ignore'.
element.on('click', dostuff);
element.ignore('click');
off('click')/off('mouseover') sounds like if you click/hover off the dialog box which is incorrect.