
JS things I didn’t know existed - fagnerbrack
https://air.ghost.io/js-things-i-never-knew-existed/
======
poof131
Side anecdote, but a number of people at my company were making fun of a
candidate who used labels to break out of loops in JS. “Those don’t exist”
they joked. I remember thinking, “I thought they did,” but didn’t say
anything. The sad part is I really like the people I work with and they are
generally smart engineers. There is just such an arrogance to the interview
process in tech it is almost unreal. I haven’t noticed a lack of qualified
candidates in tech, just a lack of humility in many of the gatekeepers.
Whiteboard pissing contests.

~~~
maxxxxx
Some years ago I got into a dispute with an interviewer about some C++
construct. He claimed it wouldn't work. I claimed it would. I asked him to put
it through the compiler but he refused.

Same in your situation. Why didn't they try it out before making a judgement?

~~~
kazinator
At some point you have to have confidence in what you know (right or wrong).
You can't be trying every darn thing.

Wait does JS really have curly braces? Not sure now, I haven't read the spec
from cover to cover three times; better go try it.

Okay, super exaggerated example (but I like those; they get the point across).

Also, empirical approaches can appear to confirm intuitions that are wrong;
like printf("%d %d\n", i++, i++) producing the wrongly expected answer.

~~~
maxxxxx
"At some point you have to have confidence in what you know (right or wrong).
You can't be trying every darn thing."

I view it as test. When an interviewee or a new guy at work tells me something
that I don't know or think is wrong I always give him the benefit of the doubt
and verify it together with him. If he is right I know we have somebody who
brings something to the table. If he is wrong that's clearly a negative that
counts against him. If that happens a few times I will stop listening to that
person.

------
santoriv
Interesting read. I quite like the pipe operator as I think it would make a
lot of code easier to read.

I would caution people against using some of these "features" though as
writing clever code that leverages obscure techniques is NOT good for
readability and maintainability.

The person who has to maintain your code will probably be able to more easily
grok some boring if else statements than some weird ternary thing that
leverages the comma operator.

Just because you can doesn't mean you should.

~~~
djedr
I wonder if there is really a need for this operator.

Compare

    
    
      2 |> square |> increment |> square
    

and

    
    
      pipe(2, square, increment, square)
    

where `pipe` is defined as

    
    
      const pipe = (...args) => args.reduce((prev, curr) => curr(prev));
    

So given that what would be a strong argument for introducing the operator to
JavaScript?

~~~
seanwilson
Is there a good way to see the intermediate results at each stage in the pipe
when things go wrong? Pipes are concise but perhaps harder to debug depending
on what tools you have.

~~~
marksomnian

        function tee(arg) {
          console.log(arg);
          return arg;
        }
        
        2 |> square |> tee |> increment |> square;

~~~
seanwilson
So I'm comparing pipe usage to this e.g.

    
    
        const result1 = square(2);
        const result2 = increment(result1);
        const result3 = square(result2);
    

With the above, I can add in a breakpoint and inspect what's going on at each
stage with access to other debugging tools. Log statements don't seem nearly
as good as this. The above is nice as well in that you can give intuitive
names to the intermediate results.

~~~
djedr
If you need names for intermediate results, etc. then you don't want the
pipeline operator/function. In such cases the things you say are true. But
when you wan't to be more concise, with the operator/function, you can.

BTW A nice feature of a code editor would be if you could magically switch
back and forth between code with intermediate named variables and pipelined
version of the same code, e.g. by selecting the code and invoking an option.

------
ChrisSD
I'm surprised the author hadn't heard of void. There was a time when using it
in links (aka `javascript:void(0)`) was very common.

Also yeah javascript has labels but using them is usually a bad idea. While
they may seem useful they can be harder to reason about in all but the
simplest code. You're almost always better off restructuring your code instead
of using labels.

~~~
tgb
How did the void(0) thing work in links? I remember being frustrated by it
when I couldn't see where the link would take me, but never understood what
was going on.

~~~
ChrisSD
Basically it defers to a javascript function instead of using the web's normal
way of linking. An example of such a link would be:

    
    
        <a href="javascript:void(0)" onclick="dostuff()">Click me</a>
    

href="javascript:void(0)" basically tells the browser to do nothing when a
link is clicked. It's like returning false from an event listener.

onclick="dostuff()" will then listen for clicks and call the `dostuff`
function to update the page or load a new one.

Nowadays it's considered bad practice and to be honest it wasn't exactly good
practice in those days but it was very commonly used.

------
kurtisc
IMO it seems unwise to use features like these which you wouldn't expect other
people to know on a shared codebase. C also has the comma operator and, while
I find it can be used to write things elegantly, I've yet to find a place
where it's easier for another person to understand at first scan than using
more common idioms.

~~~
tomxor
I dislike this reasoning, I've heard it many times with all kinds of things
but mostly programming languages. I dislike it because the threshold you pick
is completely arbitrary, what is to stop you from lowering yourself to the
lowest common denominator.

As a counter argument... switch this reasoning from syntax to algorithm, if an
algorithm is too complex for most people to understand at first glance, do you
throw it away in favour of a simple but inferior choice for the problem at
hand?

~~~
hk__2
> switch this reasoning from syntax to algorithm, if an algorithm is too
> complex for most people to understand at first glance, do you throw it away
> in favour of a simple but inferior choice for the problem at hand?

This is not the same problem. Syntax is only a way of writing the _same_ code
in a different way.

~~~
tomxor
An algorithm also solves the same problem. But that doesn't really matter. The
point it: It is the same problem, there are many attributes, many choices
beyond syntactic choice that affect the comprehension to people unfamiliar to
your code.

Many of them opinionated and arbitrary, but it's easy to draw the line based
on your own experience and unwittingly cast out people with more or less
knowledge than yourself as being more obscure or more common.

------
always_good

        const x = (1, 2, 3) // 3
        x === (1, 2, 3)
    

Javascript's tuples have some great compression!

~~~
yorwba
When I was just a neophyte, I wondered whether JavaScript supported
multidimensional arrays, so I wrote _array[x, y] = something_ and it appeared
to work (reading _array[x, y]_ returned the written value, after all). It was
only when I tried to store multiple values with the same _y_ -coordinate that
I realized my mistake.

------
the_gipsy
The pipe operator exists exactly like the proposal in Elm, and I miss it so
much in js.

It doesn’t really make sense to put it in the article, it is completely
unrelated to the other arcane and unsafe features that precede it.

~~~
nerdponx
Out of curiosity, what makes these features unsafe?

~~~
the_gipsy
Sorry, unsafe was a bad choice of words. More something like (programmer)
error-prone.

------
turblety
What a lovely article. Was interesting and learned about the comma operator,
which is really awesome.

------
_pmf_
Using the comma operator for branch specific actions in a ternary operator
expression is actually really nice.

------
dsego
We should only use language features which spark joy.

------
ballenf
So many functional aspects of JS make for an exciting future. If only
chrome/firefox would catch up with webkit with regard to tail calls.

The latest comments from the devs on the bug in chrome is just depressing.

------
tritium
I knew about half of these, and the other half was still pretty awesome. I’m
not entirely enthused by the pipeline operator, but oh well.

------
GordonS
Given how long I've had the misfortune of working with JS, I can't believe I
wasn't aware of the `dataset` one!

------
bugmen0t
Bet you didn't hear about Symbols either, then

------
pg_bot
Glad to see that Elixir's pipe operator is beginning to spread to other
languages!

~~~
scns
[https://en.m.wikipedia.org/wiki/Pipeline_(Unix)](https://en.m.wikipedia.org/wiki/Pipeline_\(Unix\))

First implemented in Unix V3 1973, acording to wikipedia.

~~~
djedr
See also:
[https://en.wikipedia.org/wiki/Forth_(programming_language)](https://en.wikipedia.org/wiki/Forth_\(programming_language\))

Or even:
[https://en.wikipedia.org/wiki/Reverse_Polish_notation](https://en.wikipedia.org/wiki/Reverse_Polish_notation)

