
Deep JavaScript: Theory and Techniques - ingve
https://exploringjs.com/deep-js/
======
azangru
Have you seen that Flanagan's JavaScript the Definitive Guide, the famously
big book with the rhinoceros on its cover, has recently seen a new edition? I
wonder how deep its JavaScript goes :-)

([https://www.amazon.co.uk/JavaScript-Definitive-Guide-
David-F...](https://www.amazon.co.uk/JavaScript-Definitive-Guide-David-
Flanagan/dp/1491952024))

~~~
petercooper
David has written about what's new, if anyone's interested:
[https://davidflanagan.com/2020/05/03/changes-in-the-
seventh-...](https://davidflanagan.com/2020/05/03/changes-in-the-seventh-
edition.html)

I also (briefly) interviewed him about it here:
[https://superhighway.dev/david-flanagan-
interview](https://superhighway.dev/david-flanagan-interview)

~~~
ithrow
No PDF version?

------
ipnon
I've never heard of object sealing or freezing, glancing at the Table of
Contents. JavaScript keeps surprising me.

    
    
      // Levels of protection: preventing extensions, sealing, freezing
      Object.preventExtensions(obj)
      Object.seal(obj)
      Object.freeze(obj)

~~~
DylanSp
From using immer[1], I learned about Object.freeze(), which immer uses under
the hood.

[1] [https://github.com/immerjs/immer](https://github.com/immerjs/immer)

~~~
cjones26
Though I recommend to my team to avoid mutation if at all possible, there are
times which I have found immer absolutely invaluable. Try spreading out an
object 15 levels deep to replace a single property value and you'll catch my
drift.

~~~
acidbaseextract
My biggest challenge with immer has been that my code aesthetic taste leans
functional, but immer makes code look imperative even if it is ultimately
functional. Always looks a little wrong to my eye!

~~~
wereHamster
Writing old-style pure code to do changes in a deeply nested structure is
cumbersome, both to write and read. Eventually every language will find nicer
ways to allow programmers to express these mutations.

JavaScript doesn't provide a nice way to extend the language syntax, unlike
some other programming languages. So most DSLs end up looking like imperative
code but do pure mutations underneath. I understand, for the reader it's
confusing, because unless you know that it's a DSL you never know whether the
mutations are pure or not.

Compare that with Haskell, with its support for custom operators, allows for
some quite succinct code to express deep mutations (cf. lens library)

------
tempodox
This looks like it's worth a place in an electronic bookshelf. Among other
things, following a link in the contents led me to this little pearl:
[https://mathiasbynens.be/notes/globalthis](https://mathiasbynens.be/notes/globalthis)

~~~
ezequiel-garzon
He’s great! Consider
[https://mothereff.in/ampersands](https://mothereff.in/ampersands)

------
MatekCopatek
Love this!

Some languages are typically taught in introductory programming courses - it's
a very deliberate process aimed at explaining concepts from the ground up. JS
is the opposite, people mostly learn it top-down, doing web development and
being forced to use it.

And like eager college graduates need to learn it's sometimes a waste of time
to optimize an algorithm, DIY JS devs can greatly benefit from a bit of theory
and technical depth. Resources like this are perfect for that.

I can also wholeheartedly recommend Kyle Simpson's You Don't Know JS.

------
jorangreef
One of the things I love about JavaScript is that you can write an almost 10x
faster hash table than the standard library if you take care of cache misses
and GC: [https://github.com/ronomon/hash-
table#motivation](https://github.com/ronomon/hash-table#motivation)

In fact, all the usual low-level optimization techniques like reducing branch
mispredictions and expensive memory accesses apply, and make a huge
difference, even though you're writing in a high-level language.

~~~
game_the0ry
I do appreciate the effort the author put into that library and obviously
performance is important.

However, JS doesn't primarily live in the server side world, it mostly lives
in the browser world. And in the browsers, you _rarely_ do heavy processing.
If you are, you're doing it wrong - that logic needs to live on the server.

You're also doing it wrong in you are relying on server side NodeJS for tasks
that involve heavy duty computations.

Still, interesting to know. I wonder if the author can make this repo a
proposal to the TC39 committee.

~~~
hombre_fatal
I consider this wrong on all counts and I don't see where you're coming from
to make these claims. You obviously benefit from performance gains on the
server and client in standard use-cases.

A Node.js server's main thread is nickel and dimed by a thousand little cuts.
A faster hash implementation can reduce loop delay by a nontrivial amount.
This isn't heavy processing.

Same with the client. Any sort of game could have a good reason to be doing
hashtable lookups in a hot loop on the client. This isn't heavy processing in
some exotic use-case, it's rather elementary. And perf trade-offs especially
help slow clients. And freeing up the main thread lets you fit in more
nonreducible cycles.

Also, moving work to the server because your client implementation is too slow
and then generalizing that to "always do work on the server", is tautological.
Where you do work is fundamentally a business logic / product design concern
that is only a performance concern in the suboptimal case where you can't fit
the work on the server or client. So faster implementations move what are
performance concerns back into the realm of higher level product design
decisions.

These aren't symptoms of "doing it wrong". This is just plain jane software
engineering.

~~~
jorangreef
> This is just plain jane software engineering.

Thanks, love this quote!

------
adamc
Disappointed not to see a dead-tree version.

------
divbzero
A few bits of deep JavaScript that I’ve learned from _Deep JavaScript_ :

– The % operator calculates the remainder, not the modulus, which makes
difference for negative numbers.

– Constructors can return a Promise.

– Function names are stored as the .name property.

------
seph-reed
I just think this is interesting. The following statement is true:

`(~~4.2 === 4) && (~~-3.5 === -3)`

~~~
XCSme
Isn't `true` the expected result? Apart from that, who would write code like
this?

~~~
ipnon
Antagonistic JavaScript code golfers typically are not JavaScript users, I've
found.

edit: It's like writing an intentional buffer overflow in C. You don't see it
as often because it requires actually knowing how to program.

~~~
XCSme
The thing is, the result above is not even specific to JavaScript (in PHP for
example it also returns `true`), and it makes a lot of sense if you know what
the bitwise operators do.

