Hacker News Reader

Comment by selfmodruntime | Hacker News Reader

Congrats on your new role! Currently, I feel like addition to JavaScript is a lot slower than new CSS features, for example. What do you think are the chances that JS will one day get a larger batch of STL functions, instead of about a dozen each year?

View on HN

I hope the pace will accelerate. The real questions is what functions we need though. Some candidates that I would love to see are better helper functions on iterators, and Uint8Array<->base64/hex. Most of the "standard library" in most languages is related to IO, and for JS is dependant on the host (the web, Deno, Node) so not something TC39 will touch directly. Do you have ideas for standard library functions that you think are missing?

'range' a-la python

Range a-la python is a generator and is pretty straightforward in js as is. There is no need for a complicated solution and/or as part of stdlib, imo:

  function* range(x, y) {
    while (x <= y) {yield x++}
    // or ‘<‘ if you want half-open one
  }

  for (let n of range(3, 5)){
    console.log(n)
  }

  array = [...range(3, 5)]
  console.log(array)

It's also straight forward to implement in python. It is common enough to be standard so people won't reinvent the wheel. And it should be available to people learning the language before they learn generators.

Array.prototype.indexOf is also pretty simple as are many core functions.

'reversed' a-la python

Currently in stage 2 as `Array.prototype.toReversed`: https://github.com/tc39/proposal-change-array-by-copy

Nice, I didn't know about that, but in any case note that IMO it should be part of the Iterable protocol. Also note that the proposal above creates a copy on reverse AFAIKT.

'zip' a-la python

I have often needed this too. Noted.

I often miss map, reduce and filter on iterators, though this is already a stage 2 proposal: https://github.com/tc39/proposal-iterator-helpers.

This is definitely something I am interested in pushing too. Iterators have not gotten the love they deserve.

That's great to hear! Congratulations and thank you for your work.

'enumerate', as in Python.

'clamp' and 'sortBy', as in Lodash.

Set methods for union, intersection, difference, etc.

Re set operators: For completeness' sake there would have to be a way to specify how set elements are to be tested for equality.

I miss being able to create a hash from an array in a quick way. You always end up with

let bar = [{id: zz, }, {id: y},...]

let foo = {}

bar.forEach(v => foo[v.id] = v)

I'd love to have something like:

let foo = bar.toMap(v => [v.id, v])

new Map([[k1,v1], [k2, v2]]) can do that. Or Object.fromEntries with the same argument.

Thanks!

You still need to create the middle datastructure ( [[k1,v1], [k2, v2]] ) but it is an improvement :)

Ah yes, true, you always need to map the things ID to the thing itself, so that middle data structure is actually quite annoying :)

const foo = bar.reduce((hash, item) => { hash[item.id] = item; return hash; }, {});

    let foo = Object.fromEntries(bar.map((v) => [v.id, v]));

It is not necessary to create any extraneous data structures to do OP's one-liner. This creates n+1 new arrays that must be garbage-collected.

Object.fromEntries takes iterable, so if you have a map from a handy iterator library you could get rid of the parent array returned from `bar.map`.

    import { map } from "my-iter-lib";
    
    Object.fromEntries(map((v) => [v.id, v], bar));

Or with the proposed iterator-helpers:

    Object.fromEntries(
      Iterator.from(bar).map((v) => [v.id, v]),
    )

However the inner arrays are harder to get rid of... In fact even OP’s oneliner defines the inner arrays. I would hope there were some engine optimizations though which could minimize their footprint.

Please see my other comment in this thread for the `reduce`-based solution that requires no extra data structures. They're not that hard to get rid of!

Immutable data structures are on the agenda over in https://github.com/tc39/proposal-record-tuple and I would vote for that in Deno while I have the chance.

Yup, we'll ship them once they go Stage 3/4 (when Chrome ships them in stable).

Please have someone on your team take a good hard look at the current proposal-pipeline-operator: https://github.com/tc39/proposal-pipeline-operator

It started as a Function Composition proposal (using the pipe operator |>) but after a change of leadership it has turned into something much different. We might need another perspective on the current trajectory of this proposal, as in its current form it seems to many in the community it might take JS in the wrong direction.

Thanks!

If you want a feedback, I do not find |> versions much (if at all) easier to read. The noise is as high as in a regular function-based chaining:

  await chain(
    Object.keys(envars)
      .map(envar => `${envar}=${envars[envar]}`)
      .join(' '),
    text => `$ ${text}`,
    text => chalk.dim(text, 'node', args.join(' ')),
    colored => console.log(colored),
  )

I don’t want to sound too negative, but this seems like a pointless extension only to bring the burden of support for some syntactic flavor.

React example is special though. It feels like very helpful in expr-only context, but in-array ifs and fors would do better there:

  <ul>
    {[
      for (v of vs) {
        const text = foo(v)
        yield <li>{text}</li>
      },
      if (vs.length == 0) {
        yield <li>No items</li>
      },
    ]}

Reply on news.ycombinator.com