[HN Gopher] The triple dot syntax (` `) in JavaScript: rest vs. ...
___________________________________________________________________
The triple dot syntax (` `) in JavaScript: rest vs. spread
Author : kiyanwang
Score : 54 points
Date : 2022-05-07 09:27 UTC (1 days ago)
(HTM) web link (2ality.com)
(TXT) w3m dump (2ality.com)
| wruza wrote:
| This SO page describes that in more history and detail:
| https://stackoverflow.com/questions/44934828/is-it-spread-sy...
|
| But that's just pedantic if you ask me. A constant source of "me
| smart" attitude in conversations with those unfamiliar with the
| concept of grammar. It's okay to drive a car without being a
| qualified engine-eer.
| rauschma wrote:
| For what it's worth: That's not what motivated this blog post.
| It was that I often encounter people who see the three dots
| being used in parameter definitions or destructuring and don't
| understand what is going on (because they think it is
| spreading). The section on triple dots not being operators is
| more of a side note.
| freedomben wrote:
| I don't think GP was saying your blog post was pedantic. I
| think they were referring to the stack overflow answer
| (which, unlike yours, was kind of pedantic). Your post was
| great.
|
| That said, since we're discussing pedantry, I truly do mean
| for this to be constructive. In the US at least, most people
| avoid putting the "Dr." title in their name unless they're in
| a context where it specifically matters (such as on a course
| syllabus that they're teaching in university, for example).
| Medical doctors is an area where this is much less true. The
| "Dr." title can come off to many people as very pedantic
| unless it is specifically relevant to the situation.
|
| Part of that is probably because historically in software
| development/engineering there's been a stigma against people
| that didn't graduate or go to university, so people feel
| insecure about others with a lot more education than them.
| It's gotten a lot better, but there's definitely still some
| of that happening even now.
|
| I also want to say _thank you_ for your books and blog! I've
| found them quite helpful over the years. Javascript isn't my
| primary language so I often have to look things up, and I
| always click on your posts first because I know that they
| will:
|
| 1. Be brief and to the point (not a bunch of extra unrelated
| stuff to sort through)
|
| 2. Be very clear (never adds more confusion)
|
| 3. Be technically accurate
|
| 4. Thoroughly answer the question in the title
|
| Thanks for all you do kind sir!
| reillyse wrote:
| So it seems like the good Doctor does have a doctorate in a
| very relevant field. Informatics is quite closely related
| to programming especially as I understand in continental
| European universities. I find that knowing that the author
| has studied in the field for 10+ years is very relevant and
| adds authority to the blog.
| aiddun wrote:
| Shameless plug, I introduced an ECMA proposal for a conditional
| rest and spread operator a few months ago and would appreciate
| support or suggestions if you would find it useful.
|
| https://es.discourse.group/t/conditionally-add-elements-to-d...
| wruza wrote:
| Not sure about the proposed form, but having proper expression-
| only ifs in arrays and objects would be nice. Including the
| spread syntax. [ "foo", if
| (cond1) bar, if (cond2) ...baz, ]
|
| Pretty sure it was already proposed and rejected, but still.
| melony wrote:
| How efficient is spread? Is the underlying data copied by value?
| Copied on write? Or copied by reference only?
| ridiculous_fish wrote:
| It's bad and overused.
|
| Example: the top SO answers for "find max of an array" suggest
| using spread [1]: Math.max(...array)
|
| but this runs into implementation-defined limits on the number
| of arguments you can pass to a function, which is often as low
| as 65k; now your function is needlessly limited and works
| differently across browsers.
|
| 1: https://stackoverflow.com/questions/1669190/find-the-min-
| max... and https://stackoverflow.com/questions/45123468/max-of-
| array-in...
| culi wrote:
| is `.reduce` the preferred method then?
| [deleted]
| zeroonetwothree wrote:
| You could use `reduce` but it's a lot slower than a normal
| loop. And if your array is tiny (such that perf doesn't
| matter) you can just do the spread operator, so there's no
| real reason to ever use it.
| goto11 wrote:
| The semantics are pass-by-value, but objects are always
| references, so only the references are copied. That said the
| JavaScript spec does not require any specific implementation
| and implementation may chose various optimizations.
| brundolf wrote:
| In JS there's no such thing as a reference to a primitive, and
| there's no such thing as an automatic deep-copy of a non-
| primitive
| Tehnix wrote:
| If you are using the spread operator to copy data to create a
| new JS object in a performance sensitive loop, it will actually
| have a big enough overhead that you'll have performance gains
| by listing the fields explicitly.
|
| Spreading introduces an overhead at runtime since the object
| has to be traversed to figure out what it contains before JS
| will know what to copy over.
|
| Edit: just to be clear, unless you're looping over a million
| items or something up there, you should not care :)
| mst wrote:
| I wonder if v8 can optimise that if the object is constructed
| such that it can infer a 'type' for it (IIRC if v8 can see
| the list of keys at object construction time it remembers
| what they are for a bunch of things, no idea if this is one
| of them.)
| kevingadd wrote:
| Less efficient than classic JS 'arguments' in the case where
| you would use that, but in most cases it won't be a problem.
| adam_arthur wrote:
| Copies the value of the reference if pointing to objects, or
| copies the value directly if primitive.
|
| There is no "pass by reference" in javascript, following the
| traditional definition, just the same as Java
| oblak wrote:
| Life was hard before these sugars.
|
| Just a couple of years ago I spent a few months with people stuck
| in the late 2000s, technologically speaking. Their JS was your
| typical jQuery spaghetti from that time period. Did not have any
| fun explaining the new stuff, not to mention Promises, to people
| who were somehow convinced they knew better than me.
| dimgl wrote:
| Yeah I had an argument on here about callbacks vs. Promises.
| I'm pretty convinced the ones making the pro callbacks
| arguments have never actually used JavaScript in a professional
| capacity, especially in large codebases. I thought the
| callbacks vs Promises using `async/await` debate was settled.
| ericlewis wrote:
| I've never heard anyone argue for callbacks. But the
| async/await problem isn't entirely dead since folks still
| argue generators should be doing they job. They're similar
| flavors of cooperative multitasking I guess. But callbacks..
| they're really hard to test without abusing entirely
| different parts of js. Not that promises are much better.
| klabb3 wrote:
| Yes, but async await isn't really complete without good
| support for streaming ops and APIs that support them first
| class. That includes merging streams, canceling them, etc
| (kinda like Rx). It probably needs both push and pull
| streams as well. We're not there yet, so in the meantime we
| have to use events and event listeners, in addition to
| async/await. I think that's perfectly fine.
| nameisname wrote:
| I couldn't agree more and I've been in this same situation.
| When your codebase is hundreds of thousands of lines of
| JavaScript suddenly promises with async await make a lot of
| sense.
| BiteCode_dev wrote:
| Await is nice, but even with promises, I'd settle with
| people using them correcly: return something in the promise
| to the next one can use it without nesting.
|
| But people use promises... and keep nesting.
| wppick wrote:
| > stuck in the late 2000s
|
| jQuery is still the dominant paradigm. It's used on like 80% of
| websites. Wordpress is also still very widely used
| dgb23 wrote:
| Many of the bigger libraries like bootstrap but also
| individual, rich plugins and widgets have moved to a JS
| native implementation, which is slightly more verbose but
| clearer, well supported and has no bundle size / dependency
| overhead.
|
| If I want/need "something more than native" today then I
| first ask myself again whether I _really_ need it and then
| maybe I will look for focused/small libraries and polyfills.
| WXLCKNO wrote:
| Right, but not for new projects.
| have_faith wrote:
| Isn't jQuery mostly dominant in stats because it's included
| in WordPress by default (definitely in 90% of Wordpress
| themes). It's been a while since I checked so this could be
| out of date.
| MBCook wrote:
| Until very recently it was also a dependency of Bootstrap.
| That's why it's in my project (can't upgrade yet).
| mst wrote:
| When using classic Angular (some time ago) with Bootstrap
| I ended up rewriting the JS parts of any bit of Bootstrap
| we used as Angular components for ease of debugging (I
| know lots of people hated Angular but it was still easier
| to only debug one framework-ish thing at once).
|
| The existence today of e.g. react-bootstrap suggests that
| I'm not the only one to have had this idea.
| tweetle_beetle wrote:
| Yes, it's in core. And was only upgraded from a very
| outdated version fairly recently ( in terms of its
| lifetime) -
| https://make.wordpress.org/core/2020/06/29/updating-
| jquery-v...
| cmg wrote:
| Interesting, does the HN system replace three dots (...) with a
| space in titles? The title of the article contains (`...`), but
| the title here just has a space.
| andrethegiant wrote:
| OP's OS may have replaced three periods (`...`) with an
| ellipsis character (`...`), which HN probably filters out in
| titles.
| cmg wrote:
| Oh that's interesting. I assumed people copy/pasted titles
| when they submit!
| hombre_fatal wrote:
| macOS has ellipsis autocorrection, for example. I've had it
| turned off forever but perhaps it applies to <input
| type="text"> boxes like in the submission form.
| Izkata wrote:
| The article title doesn't have backtick-quotes either, so
| it certainly looks like they did something manually.
| zerocrates wrote:
| The actual <title> does have backticks. They're in there
| to make the periods in the on-the-page title display in a
| <code> tag, it looks like.
|
| I'd put my money on an automatic HN thing, it massages
| titles a fair amount.
| freedomben wrote:
| I wondered that too for a while as well. I then had two
| people on my team, one on windows and one on macos, and we
| discovered that macos (or something on the computer) was
| converting those automatically.
|
| macos (or some application(s) on macos) also seems to use a
| unicode version of double quotes " instead of the standard
| ascii one. I spent a ridiculous amount of time debugging a
| line in a shell script that had the unicode quotes instead
| of "normal" ones and broke in ways that were horrible to
| figure out. Eventually I discovered that he had composed
| the line in Slack and pasted it in. Definitely something to
| watch out for!
| kevin_thibedeau wrote:
| The quote problem has been a long standing issue since
| before Unicode became the dominant encoding. You will
| often see older web pages with mojibake caused by
| MacRoman encoding of smart quotes.
| david_allison wrote:
| I've had the same problem with contributors corrupting
| JSON.
|
| For reference:
|
| TextEdit - Preferences - Disable 'Smart Quotes' and
| 'Smart Dashes'
| hombre_fatal wrote:
| You can do it at the OS level with Preferences ->
| Keyboard -> Text tab -> Uncheck "Use smart quotes and
| dashes".
| mst wrote:
| We also used to have fun with MacOS' perldoc command
| rendering things cleverly and breaking copy-paste out of
| the documentation - this resulted in the "hilarious" code
| here: https://metacpan.org/release/HAARG/local-
| lib-2.000029/source...
| [deleted]
| kevingadd wrote:
| rest/spread is a nice bit of syntax worth using in code, but when
| refactoring be aware that it is not a 1:1 replacement for use of
| the classic JS 'arguments' builtin. They have different
| performance characteristics, and in particular a
| `Function.apply(this, arguments)` and `Function.call(this,
| ...args)` have different underlying implementations by spec even
| if they appear to do the same thing, which can mean the latter
| may be much much slower than you expect, potentially triggering
| additional garbage collections. I've had to flag this in code
| review a couple times :(
| leeoniya wrote:
| for high perf code, i've found Object.assign() to be
| significantly faster than spread *. it also invoke getters,
| whereas spread does not.
|
| * this statement will self-invalidate in 180 days.
| eurasiantiger wrote:
| So you're p<0.05 sure that it's faster?
| [deleted]
| captainmuon wrote:
| "..." in JS is a lot like "*args" in Python, isn't it?
| jakear wrote:
| It unifies *args and **kwargs.
| Tagbert wrote:
| Supersymmetry syntax
| ludamad wrote:
| I'm not sure I understand the point about kwargs. That's a
| feature specific to python keyword params - what's the JS
| equivalent with ... here?
| brundolf wrote:
| They're probably talking about the fact that it also works
| on objects (JS equivalent of dicts)
| jakear wrote:
| Yes, {**{'hello':1}, **{'world':2}} === {...{hello:1},
| ...{world:2}}
|
| The name "kwargs" is unimportant, I'm referring to the **
| operator itself.
|
| Edit: worth mentioning this applies in the consuming
| named arguments sense as well: ({arg1, arg2, ...rest}) =>
| {}
| culi wrote:
| except it's not just for function arguments/parameters. It can
| be used in all sorts of contexts to spread out an array or
| object. E.g.
|
| ```js const object1 = { field1: true,
| field2: 42 }; const object2 = {
| ...object1, field3: 'the meaning of life, the universe,
| and everything' };
|
| ```
___________________________________________________________________
(page generated 2022-05-08 23:01 UTC)