16 ms·

Node.js 16 Available Now

305 points by ilkkao 5y ago

murukesh_s 5y ago
Are there anyone in HN community using Node.js for mission critical backends? Even though I am perfectly happy to do that and does, especially with Typescript support, I have seen increasing number of backend devs who are more comfortable to use a static typed stack like Java or Go. Wonder if Node.js will ever get wider adoption like Java got.
- kvz 5y ago
  We (Transloadit) have been running Node.js in production the longest, since 2008, processing many petabytes, globally, hundreds of machines when not thousands, and it has not let us down. Lot of faith in Node over here.
  - murukesh_s 5y ago
    Wow thats very heartening to hear. With such use case have you ever considered moving to other stack, like Go? or does any part of your stack already uses more performant runtimes?
    - kvz 5y ago
      We do use Go in three places yes (launching instances, as there was a better go aws sdk available at the time; uploading to s3, long story but we want this out of our main processes and go has faster startup times; and tusd for receiving resumable file uploads, mostly because our tus.io lead loved Go so much :) But this is (way) less than 1% of code and typically performance is not the problem with Node, even for our use case. ~Everything we build feels fast the first time. If on rare occasion it does not, it’s a matter of rearranging the building blocks, not swapping them out for something else entirely.
- eat_veggies 5y ago
  The spaceX rockets use node for parts of their user interface—which is as close to the spirit of "mission critical" as you can get
  - lunfard00 5y ago
    Do they? Nodejs is only backend/builders, so they could be just running javascript on a chrome-like instance, no nodejs involve at first. They probably have the services running on nodejs that poll sensors (or read messages queues) to reduce complexity but not 100% certain.
    - Me1000 5y ago
      Yeah, the parent comment here is a little off. Node is not for UIs, so they're definitely not using Node for that. It was confirmed that the UIs in the Dragon capsule (which, sorry for being pedantic, is not really the "rocket") ran on top of Chromium. It's possible SpaceX uses Node under the hood somewhere, but I don't believe that has been confirmed anywhere. Also kind of interesting to note that it's only the Dragon capsule with humans that has controls, the capsule (and rocket) are both autonomous. The controls on the capsule are only there "just in case".
      - jonathanlydall 5y ago
        Electron’s “main” thread uses Node. You can then communicate between it and browser windows over IPC easily with their APIs. So if they’re running their UI on Electron, it could be on Node.
  - joelbluminator 5y ago
    Ah I was wondering why their missiles keep crashing...
- slivanes 5y ago
  Yes, running 24/7 as a daemon using builtin cluster module processing tens of thousands of requests per second. Also as a data service for connection pooling databases that don't support connection pooling with supplied drivers or server-side.
- aloisdg 5y ago
  If you are looking for a typed stack, you can give a spin to TypeScript.
- comprev 5y ago
  I've worked at several fintech companies who all used NodeJS at the backend. Engineering management decided it was suitable for the high IO demands of payments processing.
  - hanniabu 5y ago
    Is IO the same as requests? i.e. high request demand?
    - comprev 5y ago
      The payment processing was literal parsing of data files on the local disks. It was where modern fintech interfaced with archaic banking technology. Apparently they ran benchmarks and concluded NodeJS was the most suitable for their requirements.
    - sly010 5y ago
      Not necessarily, you could have a few large requests that each do a lot of database work at the backend, that would also be high IO. IO is just any low level network or disk activity that is typically done by the kernel, not the userspace (nodejs) itself.
  - murukesh_s 5y ago
    Thats very encouraging to hear. I have been trying to sell our product to enterprise companies and few Fintech companies showed interest, however they are almost 100% Java stack still. In fact I got a big list of concerns/requirements when we said we are based on Node.js - starting with XML processing and distributed transaction.. They cannot imagine using our stack for core business logic because of lack of enterprise features like distributed transaction support. That's when I realized how mature Java is in enterprise adoption compared to other stacks (With .net as an exception.). Wonder if a common standard like JDBC and JMS would help Node.js gain more adoption with enterprises
    - coldtea 5y ago
      >and few Fintech companies showed interest I said Node is dominant in web/APIs, but Fintech I don't expect to go for Node, if we're talking trading, but also for CRUD work.
- fatbird 5y ago
  I'm using it for a major system in the industrial process control segment--our piece is a dashboard displaying timestream data and KPIs based on it, and detecting alert conditions and notifying people. Were I to do it over again, I probably wouldn't choose node, but my problems with it haven't had to do with static typing or type errors--we don't use typescript. Where we've continually struggled is indeterminacy in process control and error handling and writing robust services in light of that.
  - chrisdsaldivar 5y ago
    Can you provide some more details wrt issues with error handling?
    - stickfigure 5y ago
      Not the parent poster, but I'll tell you some of the pain points I've experienced: * Async operations destroy stack information. * It's very easy for someone to miss an error handler and end up with your process in an ugly state. * Default error handling is "crash the process", no matter what else is going on. * Lots of libraries that rely on buggy native code.
      - fatbird 5y ago
        All of these, plus not being guaranteed that an error will actually be thrown to be caught rather than just hanging the process. In our case, we have a variety of tasks to carry out repeatedly on a set of entities, and the only reliable way we found to do it was to spawn new processes per task per entity. Reliable recovery from errors is basically impossible in long-running processes; you need to rely on idemptotent tasks and short-lived processes that are actively reaped if they take too long (in part this is also a consequence of the single-threaded execution model for JavaScript entailing co-operative multi-tasking).
- lucideer 5y ago
  > Are there anyone in HN community using Node.js for mission critical backends? Using Node.js for (large scale) mission critical backends, mostly in JS, but (on the topic of typed stacks) more and more of it is becoming Typescript. > Wonder if Node.js will ever get wider adoption like Java got. I'm not sure if it it will ever go as wide but it does seem to be going that way.
- 120bits 5y ago
  A year ago I worked on an analytics project and uses NodeJS as the backend. It has been really good so far and we are happy with the performance we get.
  - murukesh_s 5y ago
    Good to hear that..
- coding123 5y ago
  We're microservice based, 100% of our backend code is Typescript, including all of our REST APIs. Everything runs on Express. All in Kubernetes which provides rock solid uptime for us - easy to scale too. Front end uses GQL, which is backed by Apollo server for us. Everything can scale horizontally.
- shubik22 5y ago
  Uber was using Node for a good portion of their backend services back when I worked there (2016-2017). I’m not sure what they’re doing now, but when I left there was a project to move a lot of stuff to Go. IIRC, the performance of Node was ok but clearly worse than Go/Java/etc. Uber was using JS not TS back then, but the real issue (at least when I started) was lack of a defined interface for the API/mobile app communication. That was eventually addressed by adopting a forked version of Thrift.
  - lhorie 5y ago
    It still uses Node.js as a glue between microservices if the project frontend is web (the eats website, for examples). It also used Node for a very core part of the app, and it was Node 0.10 to boot, but my understanding is that that's on the way to deprecation. Microservices themselves are all in go or java these days.
- bstar77 5y ago
  Many thousands of people and companies use Node for mission critical backends everyday. When I worked at a very large publisher (for 10 years), most of the backend was moved to node and it was far better than our previous Java backend. It doesn't mean Node is better than Java, it just means it was adapted well to suit our needs. I personally ran mission critical node services that interfaced with over 100,000 simultaneous compute nodes in AWS.
- hn_throwaway_99 5y ago
  We use it for a mission-critical backend in TypeScript. After 20 years (was previously primarily a Java programmer for the first part of my career) I feel I have finally hit environment "nirvana" with having our front-end in React/TypeScript, backend in Node/TypeScript with API in Apollo GraphQL, DB is Postgres. Having the same language across our entire stack has huge, enormous, gargantuan benefits that shouldn't be underestimated, especially for a small team. Being able to easily move between backend and frontend code bases has had a gigantic positive impact on team productivity. Couple that with auto-generating client and server-side typescript files from our GraphQL API schema definition has made our dev process pretty awesome.
  - camjohnson26 5y ago
    I’ve got a similar stack, what are you using for ORM? Started using Prisma to replace TypeORM/TypeGraphQL but it’s new and unproven. Also are you caching with Redis, any other utilities helping with that? GraphQL-codegen is a lifesaver for generating gql types and resolvers.
    - hn_throwaway_99 5y ago
      We are not using an ORM. I am a pretty strong advocate against ORMs, but that is a topic for a different discussion. We have a set of DAO components that access the DB using Slonik, https://github.com/gajus/slonik https://github.com/gajus/slonik (overview explaining the rationale for this library is at https://medium.com/@gajus/bf410349856c https://medium.com/@gajus/bf410349856c ). Our app doesn't have a huge need for caching, but we use a mix of in-server-memory caching ( https://github.com/isaacs/node-lru-cache https://github.com/isaacs/node-lru-cache ) and Redis when we need a global cache.
      - tolmasky 5y ago
        I highly recommend you not use node-lru-cache: https://github.com/isaacs/node-lru-cache/issues/63 https://github.com/isaacs/node-lru-cache/issues/63 (as you can see from the last comment on that bug, these truly bizarre performance characteristics were not solved, and I would recommend drop-in replacing the fast-lru library we use).
- SavantIdiot 5y ago
  Walmart (the company) switched to NodeJS in ~2013 and saw a >80% reduction in cloud compute compared to LAMP. Source? I saw the dude from give a talk at Mozilla about the transition. Here was the meeting: https://www.meetup.com/pdxnode/events/142646682/ https://www.meetup.com/pdxnode/events/142646682/ * Ben Acker will share about some awesome drawings and tales of Nodejs within Walmart Labs.
  - megous 5y ago
    That's pretty meaningless. It all depends on how bloated your code is, not on the stack. I have production PAMP apps that process requests in 1-2ms. Most of the request roundtrip time tends to be network latency. It's pretty similar peformance wise to equivalent node code. Except that PAMP is naturally multi-core capable, while node is not. It's much easier to mess up node's performance (latency) by doing too much compute, compared to the PHP app, where the multi-process model will save you, to a point.
    - tandr 5y ago
      Please forgive my ignorance, but what does PAMP stand for?
      - megous 5y ago
        Sorry, LAPP. Just postgresql instead of mysql. Not sure what I was thinking... I still love Linux. ;)
    - SavantIdiot 5y ago
      How is it meaningless when it is literally the metric by which to determine if a stack is bloated? And I'm not going to argue with the dude that is responsible for Walmart's online shopping platform. Maybe you should talk to him.
      - megous 5y ago
        It's meaningless to compare platforms based on just one implementation pre-rewrite and post-rewrite. If they re-wrote it into the same stack with performance as a goal, they'd get significantly less compute resource usage, too.
- yitianjian 5y ago
  At AWS, we use Node.js with Typescript for several mission critical backends in our service - especially for lambda architecture, it's a strong use case
- throwanode1337 5y ago
  After starting my career in Ocaml/C#/Java, for the last 10 years I've worked primarily in node in critical systems. Live medical data processing, large ETL pipelines, and coordination systems that set 100% uptime as a goal and any incident would have _very_ thorough RCA, retrospectives, and accountability reports. While traditionally these were built with things like Erlang, Java Ecosystem tools (Camel, etc), the only time that using node had serious downsides was when integrating to particular languages ecosystems as a second class citizen. Examples: • Kafka. Until recently the node-rdkafka wrapper had quite a few bugs compared to the java client. We ended up writing our own internal client in typescript. Performance was worse, but we had easy scalability of our producer services and we were able to track down and resolve any issues quickly. • z3. There hasn't been an official build for node yet. We had built a wrapper to use a specific fork of z3 that we had, which allowed identification and distribution of shared subsets of problems. This worked with an etcd-like streaming consumer where you would get live-pushed keyed-problem subsets and utilize those in a local in-memory cache to speed up solvers that overlapped. • Distributed Actor-Like framework. Obviously Erlang, Akka, Akka.NET, etc are the prior art here. It didn't take too long to have our team analyze these and build out mimics in typescript. • Wrappers for specific C++ statistics libraries. Some of our ETL pipelines would enrich data with a pass on certain identifiers/classifiers/aggregators. For a few of these we created js/ts wrappers, but it would have been nice if they existed. • Standard Library. We took a microsoft-like approach and just created a standard library for ourselves. Tested and with lots of features, it meant that we rarely had to reach outside of our ecosystem for Collections, Encoders, Crypto, etc, and that they were all documented to our internal standards. If there was an issue, you had someone you could ask and get an answer within the hour. Unfortunately all of the above is proprietary and we weren't allowed to release any of it. We did retrospectives on technology choices and limitations once a year, to learn from decisions made going into the future. Each time when Node came up, the general consensus was "we could have done it in Java I suppose, but the Typescript/Node combination was much quicker to iterate on and we felt more confident in the solution after the fact".
- coldtea 5y ago
  >Wonder if Node.js will ever get wider adoption like Java got. Huh? Node is almost dominant for all kinds of API and web backends...
- Pandabob 5y ago
  Pretty sure Substack uses node in their backend, at least based on the information from their jobs page[0]. [0]: https://jobs.lever.co/substackinc/69f5ed72-9a51-404d-9db1-20aedb329798 https://jobs.lever.co/substackinc/69f5ed72-9a51-404d-9db1-20...
- tyingq 5y ago
  There's no shortage of mission critical PHP backends, so I suspect that's the same for other popular dynamically typed languages. That is, where "mission critical" means "critical to some particular business". Not guiding rockets or critical medical use, etc.
- Seich 5y ago
  We were using Node.js for pretty much all critical services at Azlo; It worked really well. Other than switching from Javascript to Typescript I don't think switching was ever considered. At this point Node is a well established platform and with a huge ecosystem that's easy to leverage.
- qaq 5y ago
  We are using Node for a lot of mission critical backends but if it was up to me I would rather use Go :)
- pimterry 5y ago
  I spent years working in Java, I've entirely moved to TypeScript as a replacement in recent years in the front and back end and it's been a huge improvement. The dramatically larger ecosystem and community is great, but notably the static typing is far more powerful in practice. I really wouldn't pick Java to improve type safety nowadays.
- golergka 5y ago
  All of our backend is built on node. And to be honest, Typescript is one of the best languages that I've ever worked with. And for Node's niche — IO-heavy, CPU-light servers that have complicated and rapidly evolving business requirements, respond to HTTP requests and do a lot of RDBMS/cache requests in the process — even better than Rust.
- mirekrusin 5y ago
  We do for for managing stuff with many $1... zeros for serious top fortune companies in business critical projects. Java/Go type systems are primitive compared to typescript. Shallow or no dependencies, functional, ocaml like modules, pervasive use of algebraic types provided by ts (previously flow), several years in production, nice codebase, several successful, non-trivial major releases, constant updates with codebase worked on every day by many people, several deployments per month. Problems I personally have with it: 1. no exact object types in ts as in flow - means they have to be emulated by destructing, sad, but you can live with it/you have to be careful 2. transpile times - but recent experiments with swc for tranpilation and deferring typecheck to run concurrently while tests are kicked off after swc finishes look promising 3. type system could be a bit smarter in few places, but no blockers so far I'd recommend but with caution - spectrum of developer's competency is closer to php (almost anybody can do it) than the one of languages like ocaml/haskell/rust and others (where entry bar is higher). Vet your dependencies, hire competent developers and it can work very well. Some of libraries we're using: - https://github.com/appliedblockchain/assert-combinators https://github.com/appliedblockchain/assert-combinators - light, runtime type assertions ("parse, don't validate" style to avoid illusion of type safety at io boundaries) - https://github.com/appliedblockchain/tsql https://github.com/appliedblockchain/tsql - functional, tagged template based combinators for sql generation
- tnolet 5y ago
  At https://checklyhq.com https://checklyhq.com we run millions of monitoring workloads - HTTP checks and Puppeteer / Playwright scripts - each day using just Node.
  - rcurry 5y ago
    Out of curiosity, what do you use for job scheduling?
    - tnolet 5y ago
      AWS Lambda. With custom job scheduling logic.
- deleted 5y ago
  [deleted]
- softfalcon 5y ago
  Yup! We do that at Coral! Typescript/Node.js/GraphQL back-end with React/Relay/Typescript on the front end. https://github.com/coralproject/talk https://github.com/coralproject/talk It's pretty nice having the whole code base share types, syntax, structure, etc. It's served us well for many years! Some of our clients include: The Washington Post, New York Times, Wired, USA Today, and Financial Times
- DigitalSea 5y ago
  Plenty of us. While Node.js might not be talked about as much as Go or Rust is, it's battletested in my opinion and a breeze to work with. I'm currently using Node for a large-scale content platform that is comprised of an ingestion engine, a parser, a queue and scraper. 4 Node servers powering 40k+ sites, sitting behind a load balancer, NGINX and PostgreSQL. It's not using anything overly fancy, but is stable and easy to fix if anything goes wrong.
synergy20 5y ago
I have always been wondering how Node.js will do as a backend option. I feel it's in decline, a quick google trend confirms it: https://trends.google.com/trends/explore?date=today%205-y&q=%2Fm%2F0bbxf89 https://trends.google.com/trends/explore?date=today%205-y&q=... I invested quite some time on node.js and eventually bailed out and now am using other alternatives. It did not work out as not all applications need those async-logics which made code unnecessarily difficult. Nowadays for me, nodejs along with npm/yarn are just more of a frontend tool, which are still very useful and essential.
- TameAntelope 5y ago
  Are you meaning to refer to JavaScript rather than Node.js? I don't know of a way to use the Node.js runtime inside of a browser (the frontend), my feeling is that's pretty redundant.
  - bstar77 5y ago
    I took the comment to mean it's only useful for something like npm/webpack (dependency management and hot loading), which I strongly disagree with.
  - ysavir 5y ago
    I think they mean using Node.js tools like yarn/NPM for compilers, linters, etc, as opposed to using it for a server.
    - synergy20 5y ago
      yes it is, it's still essential for frontend devel, actually it's pretty much a must-have scenario.
- lxe 5y ago
  With serverless functions being the hype, along with things like Next.js, Node isn't going away as a popular "backend for frontend" technology.
macando 5y ago
Node.js v16.0.0 will be the first release where we ship prebuilt binaries for Apple Silicon. While we’ll be providing separate tarballs for the Intel (darwin-x64) and ARM (darwin-arm64) architectures the macOS installer (.pkg) will be shipped as a ‘fat’ (multi-architecture) binary. Apple presenting some major hardware news today. Perfect time to release v16 :)
endisneigh 5y ago
I love Node - does anyone have good experiences with using Node with Rust/Java/C++ for interop as necessary performance wise? I know it's possible and that some teams do it, but the story wasn't great with (much) earlier versions of node. Some teams just wrote their stuff in another language and just use a child process in node to call it, serializing everything as a string and DE serializing it in the other language. The problem with that though is that you suffer a pretty decent performance penalty serializing and deserializing, and though it still might be worth it, it's also not great since some teams actually just called similarly to how you'd call a shell script. Is it much better than that now?
- maga 5y ago
  Node has always supported native addons, and since 2017 it also provides a stable ABI making the process a whole lot easier[1]. That said, in my own experience it was seldom worth it to rewrite something in C++ for performance sake. After rewriting some computationally heavy part as a native addon, I often ended up gaing only ~20% more perfomance at best when compared to properly optimized JS implementation, and even that was not guaranteed since V8 improved rapidly. That was not a good enough reason to keep a whole different tool chain around, so I'd end up going back to JS. [1] https://medium.com/netscape/javascript-c-modern-ways-to-use-c-in-javascript-projects-a19003c5a9ff https://medium.com/netscape/javascript-c-modern-ways-to-use-...
  - gargarplex 5y ago
    I have written a native C++ module to speed up JSON parsing and manipulation by a factor of 10x+
    - whatever_dude 5y ago
      Sell it to Rockstar. Their native C++ JSON parsing seems to be 10x slower than JS/Node.
  - brundolf 5y ago
    What about with wasm? I assume there's a good interop story there like there is in the browser, and you don't have to worry about building for different platforms
dfabulich 5y ago
The new stable timers API in Node 16, combined with top-level await, means that you can now easily sleep in an ESM Node script, like this: import { setTimeout } from 'timers/promises'; await setTimeout(1000); console.log("awake"); (But note that you'll have to activate ESM mode to write this script, e.g. by writing it in a `.mjs` file instead of a `.js` file or by adding a setting to package.json.) https://redfin.engineering/node-modules-at-war-why-commonjs-and-es-modules-cant-get-along-9617135eeca1 https://redfin.engineering/node-modules-at-war-why-commonjs-...
- capableweb 5y ago
  The question is, why bloat the standard library with something that would take a couple of lines to implement yourself or as a library? More languages should release new features as libraries instead of forcing it into the "global" space of the standard library.
  - geewee 5y ago
    I think this is the only "Javascript has too few third party libraries" take I've ever heard.
    - capableweb 5y ago
      Never said it should be a third party library, the core team can release libraries as well if they wanted to you know.
      - hn_throwaway_99 5y ago
        I think what you are arguing (which I agree with) is that the Node ecosystem would benefit from a set of "core" libraries that could just be installed as a separate NPM module, that are blessed by the Node core maintainers, but aren't part of a specific Node version. Deno basically does this with the Deno standard library, e.g. https://deno.land/std@0.93.0 https://deno.land/std@0.93.0, and I agree that I think it's the right approach. There is nothing "special" about wrapping setTimeout as a Promise, indeed pretty much everyone has done it at some point, so would be nice if there was a single, blessed standard version that I could just add as @node/standard in my package.json as long as I was on any supported Node version.
SavantIdiot 5y ago
Still hoping for official promise-kill+timeout support.
- Me1000 5y ago
  This is something TC39 would be responsible for, not the Node project.
  - SavantIdiot 5y ago
    Do you mean it is a language issue and not an implementation issue?
- Oddskar 5y ago
  Wouldn't Observables be a lot better for this kind of use case? "The right tool for the right job" and all that jazz.
  - azangru 5y ago
    > Wouldn't Observables be a lot better for this kind of use case? Observables are neither a part of the language nor a part of the Node api. I suppose that was what the parent's criterion.
    - SavantIdiot 5y ago
      Correct, NodeJS native. I can't edit my post now, but thanks for clarifying.
- megous 5y ago
  What's that? Some alternative to AbortSignal to gently prevent async code from continuing all the way to its logical conclusion? Also please be sensitive and don't use "kill" in new code. ;) We already have to deal with "abort".
  - steve_adams_86 5y ago
baybal2 5y ago
I want to have control over the nodejs mainloop to integrate it with GUI toolkits in C
- josh3736 5y ago
  I've done this kind of work in node before. You don't want that. The correct way to do this is to write a native addon that uses libuv to create your own thread (`uv_thread_create`) that does all the interaction with the GUI APIs. You then manage your own message queue to pass messages between your GUI thread and the V8 thread (using `uv_async_send` to invoke a C function that dispatches events from the queue into JS-land).
- tengbretson 5y ago
  I've worked with tools that do this sort of thing and the only way to get the sort of synchronization your asking for was to essentially peg an entire CPU core to 100% utilization.
tester756 5y ago
Why they still show '#BlackLivesMatter' on their page?
- o_m 5y ago
  Because racism is still a thing
  - tester756 5y ago
    but I'm not the citizen of apparently racist US, then why you(?) try to push me to solve your core problems? I've no interest in trying to make you less racists, especially that your BLM is focused on one specific group instead of universal values like - equality of opportunity
- nfadili 5y ago
  Probably because black lives still matter
  - nicofcurti 5y ago
    underrated comment
  - tester756 5y ago
    but I'm not the citizen of apparently racist US, then why you(?) try to push me to solve your core problems? I've no interest in trying to make you less racists, especially that your BLM is focused on one specific group instead of universal values like - equality of opportunity
    - codsane 5y ago
      Well if it bothers you that much, it would take less work to Right Click -> Block Element via your adblocker than it did to write your comment.
      - tester756 5y ago
travellingprog 5y ago
What excites me most about Node upgrades are the introduction of new native Javascript capabilities, because of the underlying V8 upgrade. You can figure out what those capabilities are on this website: https://node.green/ https://node.green/. You have to scroll down all the way to "Node.js ES2021 Support" to start seeing features that work in Node 16 but not Node 14 (the current LTS version). Of course, it's possible to use Babel to bring those features into Node 14, but I enjoy leaving it out of my toolchain when possible.
sleepy_keita 5y ago
Ooh, and there's an official darwin-arm64 binary too :) https://nodejs.org/dist/v16.0.0/ https://nodejs.org/dist/v16.0.0/
- ericlewis 5y ago
  Indeed! It works great.
bilekas 5y ago
> This update brings the ECMAScript RegExp Match Indices, which provide the start and end indices of the captured string. The I'm curious, because I'm useless at RegEx.. But will this break current RexEx implementations ??
- lioeters 5y ago
  Apparently it's an additional property "indices" on the returned array. > ..We propose the adoption of an additional indices property on the array result (the substrings array) of the RegExpBuiltInExec abstract operation (and thus the result from RegExp.prototype.exec(), String.prototype.match, etc.). > This property would itself be an indices array containing a pair of start and end indices for each captured substring. Any unmatched capture groups would be undefined, similar to their corresponding element in the substrings array. In addition, the indices array would itself have a groups property containing the start and end indices for each named capture group. > NOTE: For performance reasons, indices will only be added to the result if the d flag is specified. https://github.com/tc39/proposal-regexp-match-indices https://github.com/tc39/proposal-regexp-match-indices From given example: const re1 = /a+(?<Z>z)?/d; const s1 = "xaaaz"; const m1 = re1.exec(s1); // indices are relative to start of the input string: m1.indices[0][0] === 1; m1.indices[0][1] === 5; s1.slice(...m1.indices[0]) === "aaaz";

305 points by ilkkao 5y ago

Are there anyone in HN community using Node.js for mission critical backends? Even though I am perfectly happy to do that and does, especially with Typescript support, I have seen increasing number of backend devs who are more comfortable to use a static typed stack like Java or Go. Wonder if Node.js will ever get wider adoption like Java got.

kvz 5y ago
We (Transloadit) have been running Node.js in production the longest, since 2008, processing many petabytes, globally, hundreds of machines when not thousands, and it has not let us down. Lot of faith in Node over here.
- murukesh_s 5y ago
  Wow thats very heartening to hear. With such use case have you ever considered moving to other stack, like Go? or does any part of your stack already uses more performant runtimes?
  - kvz 5y ago
    We do use Go in three places yes (launching instances, as there was a better go aws sdk available at the time; uploading to s3, long story but we want this out of our main processes and go has faster startup times; and tusd for receiving resumable file uploads, mostly because our tus.io lead loved Go so much :) But this is (way) less than 1% of code and typically performance is not the problem with Node, even for our use case. ~Everything we build feels fast the first time. If on rare occasion it does not, it’s a matter of rearranging the building blocks, not swapping them out for something else entirely.
eat_veggies 5y ago
The spaceX rockets use node for parts of their user interface—which is as close to the spirit of "mission critical" as you can get
- lunfard00 5y ago
  Do they? Nodejs is only backend/builders, so they could be just running javascript on a chrome-like instance, no nodejs involve at first. They probably have the services running on nodejs that poll sensors (or read messages queues) to reduce complexity but not 100% certain.
  - Me1000 5y ago
    Yeah, the parent comment here is a little off. Node is not for UIs, so they're definitely not using Node for that. It was confirmed that the UIs in the Dragon capsule (which, sorry for being pedantic, is not really the "rocket") ran on top of Chromium. It's possible SpaceX uses Node under the hood somewhere, but I don't believe that has been confirmed anywhere. Also kind of interesting to note that it's only the Dragon capsule with humans that has controls, the capsule (and rocket) are both autonomous. The controls on the capsule are only there "just in case".
    - jonathanlydall 5y ago
      Electron’s “main” thread uses Node. You can then communicate between it and browser windows over IPC easily with their APIs. So if they’re running their UI on Electron, it could be on Node.
- joelbluminator 5y ago
  Ah I was wondering why their missiles keep crashing...
slivanes 5y ago
Yes, running 24/7 as a daemon using builtin cluster module processing tens of thousands of requests per second. Also as a data service for connection pooling databases that don't support connection pooling with supplied drivers or server-side.
aloisdg 5y ago
If you are looking for a typed stack, you can give a spin to TypeScript.
comprev 5y ago
I've worked at several fintech companies who all used NodeJS at the backend. Engineering management decided it was suitable for the high IO demands of payments processing.
- hanniabu 5y ago
  Is IO the same as requests? i.e. high request demand?
  - comprev 5y ago
    The payment processing was literal parsing of data files on the local disks. It was where modern fintech interfaced with archaic banking technology. Apparently they ran benchmarks and concluded NodeJS was the most suitable for their requirements.
  - sly010 5y ago
    Not necessarily, you could have a few large requests that each do a lot of database work at the backend, that would also be high IO. IO is just any low level network or disk activity that is typically done by the kernel, not the userspace (nodejs) itself.
- murukesh_s 5y ago
  Thats very encouraging to hear. I have been trying to sell our product to enterprise companies and few Fintech companies showed interest, however they are almost 100% Java stack still. In fact I got a big list of concerns/requirements when we said we are based on Node.js - starting with XML processing and distributed transaction.. They cannot imagine using our stack for core business logic because of lack of enterprise features like distributed transaction support. That's when I realized how mature Java is in enterprise adoption compared to other stacks (With .net as an exception.). Wonder if a common standard like JDBC and JMS would help Node.js gain more adoption with enterprises
  - coldtea 5y ago
    >and few Fintech companies showed interest I said Node is dominant in web/APIs, but Fintech I don't expect to go for Node, if we're talking trading, but also for CRUD work.
fatbird 5y ago
I'm using it for a major system in the industrial process control segment--our piece is a dashboard displaying timestream data and KPIs based on it, and detecting alert conditions and notifying people. Were I to do it over again, I probably wouldn't choose node, but my problems with it haven't had to do with static typing or type errors--we don't use typescript. Where we've continually struggled is indeterminacy in process control and error handling and writing robust services in light of that.
- chrisdsaldivar 5y ago
  Can you provide some more details wrt issues with error handling?
  - stickfigure 5y ago
    Not the parent poster, but I'll tell you some of the pain points I've experienced: * Async operations destroy stack information. * It's very easy for someone to miss an error handler and end up with your process in an ugly state. * Default error handling is "crash the process", no matter what else is going on. * Lots of libraries that rely on buggy native code.
    - fatbird 5y ago
      All of these, plus not being guaranteed that an error will actually be thrown to be caught rather than just hanging the process. In our case, we have a variety of tasks to carry out repeatedly on a set of entities, and the only reliable way we found to do it was to spawn new processes per task per entity. Reliable recovery from errors is basically impossible in long-running processes; you need to rely on idemptotent tasks and short-lived processes that are actively reaped if they take too long (in part this is also a consequence of the single-threaded execution model for JavaScript entailing co-operative multi-tasking).
lucideer 5y ago
> Are there anyone in HN community using Node.js for mission critical backends? Using Node.js for (large scale) mission critical backends, mostly in JS, but (on the topic of typed stacks) more and more of it is becoming Typescript. > Wonder if Node.js will ever get wider adoption like Java got. I'm not sure if it it will ever go as wide but it does seem to be going that way.
120bits 5y ago
A year ago I worked on an analytics project and uses NodeJS as the backend. It has been really good so far and we are happy with the performance we get.
- murukesh_s 5y ago
  Good to hear that..
coding123 5y ago
We're microservice based, 100% of our backend code is Typescript, including all of our REST APIs. Everything runs on Express. All in Kubernetes which provides rock solid uptime for us - easy to scale too. Front end uses GQL, which is backed by Apollo server for us. Everything can scale horizontally.
shubik22 5y ago
Uber was using Node for a good portion of their backend services back when I worked there (2016-2017). I’m not sure what they’re doing now, but when I left there was a project to move a lot of stuff to Go. IIRC, the performance of Node was ok but clearly worse than Go/Java/etc. Uber was using JS not TS back then, but the real issue (at least when I started) was lack of a defined interface for the API/mobile app communication. That was eventually addressed by adopting a forked version of Thrift.
- lhorie 5y ago
  It still uses Node.js as a glue between microservices if the project frontend is web (the eats website, for examples). It also used Node for a very core part of the app, and it was Node 0.10 to boot, but my understanding is that that's on the way to deprecation. Microservices themselves are all in go or java these days.
bstar77 5y ago
Many thousands of people and companies use Node for mission critical backends everyday. When I worked at a very large publisher (for 10 years), most of the backend was moved to node and it was far better than our previous Java backend. It doesn't mean Node is better than Java, it just means it was adapted well to suit our needs. I personally ran mission critical node services that interfaced with over 100,000 simultaneous compute nodes in AWS.
hn_throwaway_99 5y ago
We use it for a mission-critical backend in TypeScript. After 20 years (was previously primarily a Java programmer for the first part of my career) I feel I have finally hit environment "nirvana" with having our front-end in React/TypeScript, backend in Node/TypeScript with API in Apollo GraphQL, DB is Postgres. Having the same language across our entire stack has huge, enormous, gargantuan benefits that shouldn't be underestimated, especially for a small team. Being able to easily move between backend and frontend code bases has had a gigantic positive impact on team productivity. Couple that with auto-generating client and server-side typescript files from our GraphQL API schema definition has made our dev process pretty awesome.
- camjohnson26 5y ago
  I’ve got a similar stack, what are you using for ORM? Started using Prisma to replace TypeORM/TypeGraphQL but it’s new and unproven. Also are you caching with Redis, any other utilities helping with that? GraphQL-codegen is a lifesaver for generating gql types and resolvers.
  - hn_throwaway_99 5y ago
    We are not using an ORM. I am a pretty strong advocate against ORMs, but that is a topic for a different discussion. We have a set of DAO components that access the DB using Slonik, https://github.com/gajus/slonik https://github.com/gajus/slonik (overview explaining the rationale for this library is at https://medium.com/@gajus/bf410349856c https://medium.com/@gajus/bf410349856c ). Our app doesn't have a huge need for caching, but we use a mix of in-server-memory caching ( https://github.com/isaacs/node-lru-cache https://github.com/isaacs/node-lru-cache ) and Redis when we need a global cache.
    - tolmasky 5y ago
      I highly recommend you not use node-lru-cache: https://github.com/isaacs/node-lru-cache/issues/63 https://github.com/isaacs/node-lru-cache/issues/63 (as you can see from the last comment on that bug, these truly bizarre performance characteristics were not solved, and I would recommend drop-in replacing the fast-lru library we use).
SavantIdiot 5y ago
Walmart (the company) switched to NodeJS in ~2013 and saw a >80% reduction in cloud compute compared to LAMP. Source? I saw the dude from give a talk at Mozilla about the transition. Here was the meeting: https://www.meetup.com/pdxnode/events/142646682/ https://www.meetup.com/pdxnode/events/142646682/ * Ben Acker will share about some awesome drawings and tales of Nodejs within Walmart Labs.
- megous 5y ago
  That's pretty meaningless. It all depends on how bloated your code is, not on the stack. I have production PAMP apps that process requests in 1-2ms. Most of the request roundtrip time tends to be network latency. It's pretty similar peformance wise to equivalent node code. Except that PAMP is naturally multi-core capable, while node is not. It's much easier to mess up node's performance (latency) by doing too much compute, compared to the PHP app, where the multi-process model will save you, to a point.
  - tandr 5y ago
    Please forgive my ignorance, but what does PAMP stand for?
    - megous 5y ago
      Sorry, LAPP. Just postgresql instead of mysql. Not sure what I was thinking... I still love Linux. ;)
  - SavantIdiot 5y ago
    How is it meaningless when it is literally the metric by which to determine if a stack is bloated? And I'm not going to argue with the dude that is responsible for Walmart's online shopping platform. Maybe you should talk to him.
    - megous 5y ago
      It's meaningless to compare platforms based on just one implementation pre-rewrite and post-rewrite. If they re-wrote it into the same stack with performance as a goal, they'd get significantly less compute resource usage, too.
yitianjian 5y ago
At AWS, we use Node.js with Typescript for several mission critical backends in our service - especially for lambda architecture, it's a strong use case
throwanode1337 5y ago
After starting my career in Ocaml/C#/Java, for the last 10 years I've worked primarily in node in critical systems. Live medical data processing, large ETL pipelines, and coordination systems that set 100% uptime as a goal and any incident would have _very_ thorough RCA, retrospectives, and accountability reports. While traditionally these were built with things like Erlang, Java Ecosystem tools (Camel, etc), the only time that using node had serious downsides was when integrating to particular languages ecosystems as a second class citizen. Examples: • Kafka. Until recently the node-rdkafka wrapper had quite a few bugs compared to the java client. We ended up writing our own internal client in typescript. Performance was worse, but we had easy scalability of our producer services and we were able to track down and resolve any issues quickly. • z3. There hasn't been an official build for node yet. We had built a wrapper to use a specific fork of z3 that we had, which allowed identification and distribution of shared subsets of problems. This worked with an etcd-like streaming consumer where you would get live-pushed keyed-problem subsets and utilize those in a local in-memory cache to speed up solvers that overlapped. • Distributed Actor-Like framework. Obviously Erlang, Akka, Akka.NET, etc are the prior art here. It didn't take too long to have our team analyze these and build out mimics in typescript. • Wrappers for specific C++ statistics libraries. Some of our ETL pipelines would enrich data with a pass on certain identifiers/classifiers/aggregators. For a few of these we created js/ts wrappers, but it would have been nice if they existed. • Standard Library. We took a microsoft-like approach and just created a standard library for ourselves. Tested and with lots of features, it meant that we rarely had to reach outside of our ecosystem for Collections, Encoders, Crypto, etc, and that they were all documented to our internal standards. If there was an issue, you had someone you could ask and get an answer within the hour. Unfortunately all of the above is proprietary and we weren't allowed to release any of it. We did retrospectives on technology choices and limitations once a year, to learn from decisions made going into the future. Each time when Node came up, the general consensus was "we could have done it in Java I suppose, but the Typescript/Node combination was much quicker to iterate on and we felt more confident in the solution after the fact".
coldtea 5y ago
>Wonder if Node.js will ever get wider adoption like Java got. Huh? Node is almost dominant for all kinds of API and web backends...
Pandabob 5y ago
Pretty sure Substack uses node in their backend, at least based on the information from their jobs page[0]. [0]: https://jobs.lever.co/substackinc/69f5ed72-9a51-404d-9db1-20aedb329798 https://jobs.lever.co/substackinc/69f5ed72-9a51-404d-9db1-20...
tyingq 5y ago
There's no shortage of mission critical PHP backends, so I suspect that's the same for other popular dynamically typed languages. That is, where "mission critical" means "critical to some particular business". Not guiding rockets or critical medical use, etc.
Seich 5y ago
We were using Node.js for pretty much all critical services at Azlo; It worked really well. Other than switching from Javascript to Typescript I don't think switching was ever considered. At this point Node is a well established platform and with a huge ecosystem that's easy to leverage.
qaq 5y ago
We are using Node for a lot of mission critical backends but if it was up to me I would rather use Go :)
pimterry 5y ago
I spent years working in Java, I've entirely moved to TypeScript as a replacement in recent years in the front and back end and it's been a huge improvement. The dramatically larger ecosystem and community is great, but notably the static typing is far more powerful in practice. I really wouldn't pick Java to improve type safety nowadays.
golergka 5y ago
All of our backend is built on node. And to be honest, Typescript is one of the best languages that I've ever worked with. And for Node's niche — IO-heavy, CPU-light servers that have complicated and rapidly evolving business requirements, respond to HTTP requests and do a lot of RDBMS/cache requests in the process — even better than Rust.
mirekrusin 5y ago
We do for for managing stuff with many $1... zeros for serious top fortune companies in business critical projects. Java/Go type systems are primitive compared to typescript. Shallow or no dependencies, functional, ocaml like modules, pervasive use of algebraic types provided by ts (previously flow), several years in production, nice codebase, several successful, non-trivial major releases, constant updates with codebase worked on every day by many people, several deployments per month. Problems I personally have with it: 1. no exact object types in ts as in flow - means they have to be emulated by destructing, sad, but you can live with it/you have to be careful 2. transpile times - but recent experiments with swc for tranpilation and deferring typecheck to run concurrently while tests are kicked off after swc finishes look promising 3. type system could be a bit smarter in few places, but no blockers so far I'd recommend but with caution - spectrum of developer's competency is closer to php (almost anybody can do it) than the one of languages like ocaml/haskell/rust and others (where entry bar is higher). Vet your dependencies, hire competent developers and it can work very well. Some of libraries we're using: - https://github.com/appliedblockchain/assert-combinators https://github.com/appliedblockchain/assert-combinators - light, runtime type assertions ("parse, don't validate" style to avoid illusion of type safety at io boundaries) - https://github.com/appliedblockchain/tsql https://github.com/appliedblockchain/tsql - functional, tagged template based combinators for sql generation
tnolet 5y ago
At https://checklyhq.com https://checklyhq.com we run millions of monitoring workloads - HTTP checks and Puppeteer / Playwright scripts - each day using just Node.
- rcurry 5y ago
  Out of curiosity, what do you use for job scheduling?
  - tnolet 5y ago
    AWS Lambda. With custom job scheduling logic.
deleted 5y ago
[deleted]
softfalcon 5y ago
Yup! We do that at Coral! Typescript/Node.js/GraphQL back-end with React/Relay/Typescript on the front end. https://github.com/coralproject/talk https://github.com/coralproject/talk It's pretty nice having the whole code base share types, syntax, structure, etc. It's served us well for many years! Some of our clients include: The Washington Post, New York Times, Wired, USA Today, and Financial Times
DigitalSea 5y ago
Plenty of us. While Node.js might not be talked about as much as Go or Rust is, it's battletested in my opinion and a breeze to work with. I'm currently using Node for a large-scale content platform that is comprised of an ingestion engine, a parser, a queue and scraper. 4 Node servers powering 40k+ sites, sitting behind a load balancer, NGINX and PostgreSQL. It's not using anything overly fancy, but is stable and easy to fix if anything goes wrong.

synergy20 5y ago

I have always been wondering how Node.js will do as a backend option. I feel it's in decline, a quick google trend confirms it: https://trends.google.com/trends/explore?date=today%205-y&q=%2Fm%2F0bbxf89 https://trends.google.com/trends/explore?date=today%205-y&q=... I invested quite some time on node.js and eventually bailed out and now am using other alternatives. It did not work out as not all applications need those async-logics which made code unnecessarily difficult. Nowadays for me, nodejs along with npm/yarn are just more of a frontend tool, which are still very useful and essential.

TameAntelope 5y ago
Are you meaning to refer to JavaScript rather than Node.js? I don't know of a way to use the Node.js runtime inside of a browser (the frontend), my feeling is that's pretty redundant.
- bstar77 5y ago
  I took the comment to mean it's only useful for something like npm/webpack (dependency management and hot loading), which I strongly disagree with.
- ysavir 5y ago
  I think they mean using Node.js tools like yarn/NPM for compilers, linters, etc, as opposed to using it for a server.
  - synergy20 5y ago
    yes it is, it's still essential for frontend devel, actually it's pretty much a must-have scenario.
lxe 5y ago
With serverless functions being the hype, along with things like Next.js, Node isn't going away as a popular "backend for frontend" technology.

macando 5y ago

Node.js v16.0.0 will be the first release where we ship prebuilt binaries for Apple Silicon. While we’ll be providing separate tarballs for the Intel (darwin-x64) and ARM (darwin-arm64) architectures the macOS installer (.pkg) will be shipped as a ‘fat’ (multi-architecture) binary. Apple presenting some major hardware news today. Perfect time to release v16 :)

endisneigh 5y ago

I love Node - does anyone have good experiences with using Node with Rust/Java/C++ for interop as necessary performance wise? I know it's possible and that some teams do it, but the story wasn't great with (much) earlier versions of node. Some teams just wrote their stuff in another language and just use a child process in node to call it, serializing everything as a string and DE serializing it in the other language. The problem with that though is that you suffer a pretty decent performance penalty serializing and deserializing, and though it still might be worth it, it's also not great since some teams actually just called similarly to how you'd call a shell script. Is it much better than that now?

maga 5y ago
Node has always supported native addons, and since 2017 it also provides a stable ABI making the process a whole lot easier[1]. That said, in my own experience it was seldom worth it to rewrite something in C++ for performance sake. After rewriting some computationally heavy part as a native addon, I often ended up gaing only ~20% more perfomance at best when compared to properly optimized JS implementation, and even that was not guaranteed since V8 improved rapidly. That was not a good enough reason to keep a whole different tool chain around, so I'd end up going back to JS. [1] https://medium.com/netscape/javascript-c-modern-ways-to-use-c-in-javascript-projects-a19003c5a9ff https://medium.com/netscape/javascript-c-modern-ways-to-use-...
- gargarplex 5y ago
  I have written a native C++ module to speed up JSON parsing and manipulation by a factor of 10x+
  - whatever_dude 5y ago
    Sell it to Rockstar. Their native C++ JSON parsing seems to be 10x slower than JS/Node.
- brundolf 5y ago
  What about with wasm? I assume there's a good interop story there like there is in the browser, and you don't have to worry about building for different platforms

dfabulich 5y ago

The new stable timers API in Node 16, combined with top-level await, means that you can now easily sleep in an ESM Node script, like this: import { setTimeout } from 'timers/promises'; await setTimeout(1000); console.log("awake"); (But note that you'll have to activate ESM mode to write this script, e.g. by writing it in a `.mjs` file instead of a `.js` file or by adding a setting to package.json.) https://redfin.engineering/node-modules-at-war-why-commonjs-and-es-modules-cant-get-along-9617135eeca1 https://redfin.engineering/node-modules-at-war-why-commonjs-...

capableweb 5y ago
The question is, why bloat the standard library with something that would take a couple of lines to implement yourself or as a library? More languages should release new features as libraries instead of forcing it into the "global" space of the standard library.
- geewee 5y ago
  I think this is the only "Javascript has too few third party libraries" take I've ever heard.
  - capableweb 5y ago
    Never said it should be a third party library, the core team can release libraries as well if they wanted to you know.
    - hn_throwaway_99 5y ago
      I think what you are arguing (which I agree with) is that the Node ecosystem would benefit from a set of "core" libraries that could just be installed as a separate NPM module, that are blessed by the Node core maintainers, but aren't part of a specific Node version. Deno basically does this with the Deno standard library, e.g. https://deno.land/std@0.93.0 https://deno.land/std@0.93.0, and I agree that I think it's the right approach. There is nothing "special" about wrapping setTimeout as a Promise, indeed pretty much everyone has done it at some point, so would be nice if there was a single, blessed standard version that I could just add as @node/standard in my package.json as long as I was on any supported Node version.

SavantIdiot 5y ago

Still hoping for official promise-kill+timeout support.

Me1000 5y ago
This is something TC39 would be responsible for, not the Node project.
- SavantIdiot 5y ago
  Do you mean it is a language issue and not an implementation issue?
Oddskar 5y ago
Wouldn't Observables be a lot better for this kind of use case? "The right tool for the right job" and all that jazz.
- azangru 5y ago
  > Wouldn't Observables be a lot better for this kind of use case? Observables are neither a part of the language nor a part of the Node api. I suppose that was what the parent's criterion.
  - SavantIdiot 5y ago
    Correct, NodeJS native. I can't edit my post now, but thanks for clarifying.
megous 5y ago
What's that? Some alternative to AbortSignal to gently prevent async code from continuing all the way to its logical conclusion? Also please be sensitive and don't use "kill" in new code. ;) We already have to deal with "abort".
- steve_adams_86 5y ago

baybal2 5y ago

I want to have control over the nodejs mainloop to integrate it with GUI toolkits in C

josh3736 5y ago
I've done this kind of work in node before. You don't want that. The correct way to do this is to write a native addon that uses libuv to create your own thread (`uv_thread_create`) that does all the interaction with the GUI APIs. You then manage your own message queue to pass messages between your GUI thread and the V8 thread (using `uv_async_send` to invoke a C function that dispatches events from the queue into JS-land).
tengbretson 5y ago
I've worked with tools that do this sort of thing and the only way to get the sort of synchronization your asking for was to essentially peg an entire CPU core to 100% utilization.

tester756 5y ago

Why they still show '#BlackLivesMatter' on their page?

o_m 5y ago
Because racism is still a thing
- tester756 5y ago
  but I'm not the citizen of apparently racist US, then why you(?) try to push me to solve your core problems? I've no interest in trying to make you less racists, especially that your BLM is focused on one specific group instead of universal values like - equality of opportunity
nfadili 5y ago
Probably because black lives still matter
- nicofcurti 5y ago
  underrated comment
- tester756 5y ago
  but I'm not the citizen of apparently racist US, then why you(?) try to push me to solve your core problems? I've no interest in trying to make you less racists, especially that your BLM is focused on one specific group instead of universal values like - equality of opportunity
  - codsane 5y ago
    Well if it bothers you that much, it would take less work to Right Click -> Block Element via your adblocker than it did to write your comment.
    - tester756 5y ago

travellingprog 5y ago

What excites me most about Node upgrades are the introduction of new native Javascript capabilities, because of the underlying V8 upgrade. You can figure out what those capabilities are on this website: https://node.green/ https://node.green/. You have to scroll down all the way to "Node.js ES2021 Support" to start seeing features that work in Node 16 but not Node 14 (the current LTS version). Of course, it's possible to use Babel to bring those features into Node 14, but I enjoy leaving it out of my toolchain when possible.

sleepy_keita 5y ago

Ooh, and there's an official darwin-arm64 binary too :) https://nodejs.org/dist/v16.0.0/ https://nodejs.org/dist/v16.0.0/

ericlewis 5y ago
Indeed! It works great.

bilekas 5y ago

> This update brings the ECMAScript RegExp Match Indices, which provide the start and end indices of the captured string. The I'm curious, because I'm useless at RegEx.. But will this break current RexEx implementations ??

lioeters 5y ago
Apparently it's an additional property "indices" on the returned array. > ..We propose the adoption of an additional indices property on the array result (the substrings array) of the RegExpBuiltInExec abstract operation (and thus the result from RegExp.prototype.exec(), String.prototype.match, etc.). > This property would itself be an indices array containing a pair of start and end indices for each captured substring. Any unmatched capture groups would be undefined, similar to their corresponding element in the substrings array. In addition, the indices array would itself have a groups property containing the start and end indices for each named capture group. > NOTE: For performance reasons, indices will only be added to the result if the d flag is specified. https://github.com/tc39/proposal-regexp-match-indices https://github.com/tc39/proposal-regexp-match-indices From given example: const re1 = /a+(?<Z>z)?/d; const s1 = "xaaaz"; const m1 = re1.exec(s1); // indices are relative to start of the input string: m1.indices[0][0] === 1; m1.indices[0][1] === 5; s1.slice(...m1.indices[0]) === "aaaz";