Two Features of JavaScript that you might not know
monkwhocode.com
monkwhocode.com
> Optional Chaining operator (?.)
> Nullish Coalescing operator (??)
Esp chaining can have a huge impact on readability.
[0]: https://www.monkwhocode.com/2020/05/nodejs-v14-2-things-to-k...
Basic examples for null coalescing here https://byexample.xyz/javascript/ECMAScript2020/nullCoalesci...
Oh looks like the operator is actually '?.' instead of just '?' so guess this.myOptionalFunction?.() could work but that looks really confusing in my eyes.
(get-in obj [key1 “key 2” (make-key obj 3) 4] “not-found”)
“not-found” can be a value or a function or a function evaluation, and the keys can be of any type, including nested maps or, if you wanna get really wild, functions.
Someday I’ll get to use this professionally instead of transpiling piles of NPM dependencies into something IE11 can work with...
Both of the new additions to JS specified in the article can be sort of done in cljs, though each one will be a function. This already fits with the existing paradigm; there are no operators in Clojure, only functions. “2 + 3” in JS is already “(+ 2 3)” in CLJS.
The Math.pow() vs “two stars operator” is kinda pointless: it can be reduced to (pow x y) with a require statement. Is that really used often enough to warrant new syntax?
Here’s how big numbers can be separated by space though. It does not handle overflows; I don’t think the JS version does either:
(defn bignum [& xs] (js/parseInt (apply str xs)))
(bignum 123 456 789)
;; yields 123456789 as a JS int
https://github.com/StevenBlack/hosts
While not your traditional ad blocker done via browser extension, it does the job quite well and blocks the requests at the OS level.
I'm not the author or maintainer, just a very happy user.
If not maybe they need ads. So many people say they would rather pay directly but few do when given the chance.
You don't need so many paying readers to get more money than ads. I also think that people should stop putting ads on their website when the gains are so little.
If writing is your job, write for a proper good media.
JavaScript's multi-paradigm approach is one of its strengths, but, in my opinion, a weakness at the same time.
It allows people to write JavaScript following whatever approach suits them, which is fine for individual developers and small teams, but expand beyond that and it becomes a big ask for every developer to be up to speed with every feature JavaScript supports.
I use and teach JavaScript/TypeScript every day, and its possible to be very productive with it, but I prefer the approaches of Go and Clojure better. Limited languages that support a single paradigm, and support it well.
The result is that practically no-one wants to write in whatever a "JS native" paradigm might look like. Everyone wants to write it like C, or like Java, or like OCaml, or whatever. Mind, I don't think it's a bad thing people avoid writing "JS native" style, because I certainly don't want to be handed a codebase in which anyone's done anything remotely interesting with prototypal inheritance—it's just something I find interesting about the community of such a popular language.
const [username, setUsername] = useState('')
const onChange = event => setUsername(event.target.value)
const onSave = () => dispatch(saveUsername(username))
return (
<div>
<input value={username} onChange={onChange} />
<button onClick={onSave}>Save</button>
</div>
)
2. Where are the closures and what's the necessity to use them?
2. onChange and onSave are both closures.
It isn’t technically necessary to use closures, but you need to find the correct setUsername from onChange, and since setUsername isn’t a global variable, closures are the natural and easy way to do it.
Hooks have shown that Super Serious programming can also be comedy, which is pretty cool.
I dunno, the functions-or-bust crowd happily doing and championing manual OO machinery fiddling amuses me.
[EDIT] what they couldn't have done, probably, would have been cleanly implementing that on top of class-based components without then having to tell their large and influential functions-are-the-only-way constituency that they'd need to write a lot more classes in the future. I suspect aversion to having to deliver that message is part of why we ended up with hooks as the solution, and classes left behind instead.
They were saying that for a long time before hooks when the only way they had it implemented at all was for classes, and functional components were usable for much narrower use cases. I suppose, if they could have done it cleanly with classes, they would have, whatever that meant saying to those downstream who aesthetically preferred functions. I don't know if it inherently worked better with functions, if the core devs themselves are just more proficient in that style, or if it was just a confluence of experience and the timing that the push to improve functional components occurred, but in the end functional components are just much cleaner.
1. https://overreacted.io/react-as-a-ui-runtime/
Where else would you propose putting UI rendering logic?
const todoItems = []
addTodoItem.addEventListener(event => {
todoItems.push(event.target.value)
renderTodoItems()
})This comment really looks like it's a reply to some article other than this one.
Realistically, do you think JS programmers are going to form two camps?
x ** y
Math.pow(x, y)
Nor do I foresee a big problem with some numeric constants being written with separators and others not.
In the unlikely event there's a problem with either addition, prettier can be enhanced to make it so developers don't need to be up to speed on them.
I guess I was speaking more to a general fatigue with every new feature that is added to JavaScript/TypeScript.
What was so wrong with Math.pow(x, y) that we needed a new operator for it? I think this is a question that could be asked of many additions to JavaScript/TypeScript over the years, and I think every (well-intentioned) addition has contributed to the language's current kitchen sink.
New additions don't mean the old capabilities will go away (without breaking backwards compatibility). So yes, some developers will use the new power operator in net-new code, but all existing usages of Math.pow() will remain, and every new developer that learns JavaScript will now need to know both.
With prettier, one can make an old style go away.
This is something any popular programming language has to wrestle with. There is a lot of merit in Python's philosophy of having one, and preferably only one, obvious way to do something. Otherwise, even if each different way is perfectly good in its own right, you still have more for anyone learning the language to know, and you get different representations of the same idea appearing in the same code base for no particular reason.
I do think JavaScript has more of a problem with this than most languages because of its rapid changes and ambiguous standardisation (the de jure of annual ES standards vs. the realities of what is supported in real time in each browser, or Node version, or Babel preset).
Does anyone really have time to check whether some new function on Array's prototype or some new syntax like the examples in this article is available in every target they need to support yet? I'm guessing most of us still use Babel in our build process for front-end code, even if the relatively new parts of JS we're using are supported natively everywhere we need them by now.
But then you get things like modules and imports, and you still find Node's story with these is a muddle. Things we've taken for granted for years now on the front end don't always work out of the box as you might expect on the back end, and there are at least two competing styles. And this is arguably the most important and fundamental tool a programming language needs for building larger applications!
Is the power operation really used enough for this shortcut to be a meaningful addition? I’ve literally never used it in workplace code.
Prettier.js is fantastic. I don’t think it does any function remapping right now though, does it? Seems like a better fit for Babel.js, since its whole reason to exist is backwards-compatibility.
Yeah, Python got this right when it said "There should be one obvious way to do it". It's a shame the language seems to have disregarded that part of the "Zen of Python" recently.
1. Double asterisk is the exponentiation operator.
2. _ can be used in numbers, e.g. 1_000_000
Also (and not in the article) both are also true in Python.
const language = {
set current(name) {
this.log.push(name);
},
log: []
};
2^5 = 32
However, Lua is one language that does use `^` for exponentiation (its XOR operator is `~`).
In SageMath, which uses a lightweight preparser on top of Python, I made it automatically convert ^ to , since otherwise mathematicians, who are used to LaTeX, would be very confused (I remember realizing this during a tutorial at Pycon in 2005).