HN Explorer

5 comments

[ 3.9 ms ] story [ 77.6 ms ] thread
k3n
On a related note, something I've always wondered about is why there isn't a native host object that represents the UA? Is there anything, save for tons of live code parsing UA strings, preventing this?

Seriously, even this 'lightweight' parser is around 7.6kb and a couple hundred lines of code -- and I'm not trying to knock the OP's work by any stretch. It just seems crazy that we still have to muck with this manual string parsing!

Why can't we just have:

    UA = {
        name: "Chrome",
        vendor: "Google",
        version: [24, 0, 1312, 14], // "24.0.1312.14",
        renderer: {
            name: "WebKit",
            vendor: "Apple",
            version: [537, 17],
        },
        javascript: {
            name: "V8",
            vendor: "Google",
            version: [3, 14, 5, 1],
        },
        os: {
            name: "Windows 7",
            vendor: "Microsoft",
            version: ["NT", 6, 1], // "NT 6.1"
        },
        user: {
            locale: "en-US",
            timezone: "America/Chicago",
            utc: -6,
        }
    };
tantalor
Perhaps because the User-Agent is intended for an HTTP request header, which doesn't lend itself to a complex structure.
k3n
The HTTP header would be disconnected from this effort, and wouldn't necessarily have to change. The UA object would be populated from what the browser knows about its own operating environment. Not looking to change the way anything works, just looking for a solution to the 100's of different UA parsers that are out there.
thwarted
Where does the "required" Mozilla/5.0 compatible fit into that structure?
k3n
Leave it as it is, since it's also used for webservers that would also be a different problem to solve (if it needs solving at all).

The idea would be to relieve the JS community from having to continually support this meta-data retrieval.