Yet another user agent parser
As of time of writing (3rd june 2018), the fastest user agent parser.
$ node benchmark/benchmark-parse.js trie-uaparser v1.0.5 x 106,078 ops/sec ±0.82% useragent v2.3.0 x 9,442 ops/sec ±1.10% useragent_parser v1.0.0 x 59,402 ops/sec ±0.98% useragent-parser v0.1.1 x 21,017 ops/sec ±1.39% ua-parser v0.3.5 x 41,224 ops/sec ±1.33% Fastest is trie-uaparser v1.0.5
Examples
const parse = ; const ua = "Mozilla/5.0 (Linux; U; Android 4.1.2; fr-fr; G740-L00 Build/HuaweiG740-L00) AppleWebKit/534.30 (KHTML, like Gecko) Version/4.0 Mobile Safari/534.30";to; const match = ; notto;to;to;notto;to;to;to;
Differences with existing user agent parsers
Most of the user agents parser use multiple regular expressions, each of them associated to a particular software/os.
This library instead, split the user agent into tokens and determines the software/os using a trie data structure.
It leads to:
Speed
Search using trie data structure will always be faster than looping through regexes execution. And if you have lots of data to analyse, speed is not only a nice thing to have.
Evolution
Adding a new pattern does not conflict with existing patterns.
In regexes based parsers, to detect Edge in "Mozilla/5.0 (Windows NT 10.0; Win64; x64; ServiceUI 11) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36 Edge/16.16299", /edge/ has to be tested before /chrome/ to detect Safari without conflicting with Edge, /safari/ has to be between /chrome/ and /edge/
The more patterns you add, the harder it is to make it play well with existing patterns.
More over, adding a new pattern has a small impact on speed because it is similar to add an entry in a hashmap which is not the case for regexes based parsers.