Pros

• Less subdependencies and smaller size:
  • ~1MB (qs) vs. ~30 kB (fast-querystring)
  • https://npmgraph.js.org/?q=qs vs https://npmgraph.js.org/?q=fast-querystring
  • Also less bloat (14 deps vs 1 deps)
    • qs's subdeps have a lot of recursion in require cycles as well
    • all of qs and it's dependencies is maintained by the same developer (could be a security concern)
  • Might be useful for serverless folks that use express (if there's platform that allows express to be used, at least)

Cons

• fast-querystring requires at least Node 8:
  • it uses object destructuring and trailing commas
    • it might be possible to convince the author to remove the trailing commas, then it would be usable with Node 6
  • Node 8 has been out of support for more than 5 years now (support stopped on Jan 1st 2019, according to endoflife.date/nodejs)
  • Node 0.10 is even older, I can't even find an EOL date for it
• fast-querystring doesn't support setting prototypes
  • this is unsafe either way, though it can probably get released in express v5

Notes

• Slightly better performance:
  
  • this test was done using the benchmark folder in this repo and just replacing the require call to fast-querystring on a idling 7950X running Node v8.17.0
• It might be useful to maybe port to using URLSearchParams which has been supported since Node 10
  • just looked at Replacing querystring with fast-querystring #4990 which mentioned URLSearchParams to be pretty slow, though, this needs to be benchmarked first