silesky
commented
4 months ago @gajus Thanks for your comment. This is good feedback and a good future data point, and is actually something we thought about. I totally understand the ugliness. (FTR also considered analytics-fetch). Ultimately, here is what drove us to retain the node label was practical considerations:
- we were deprecating the OG 'analytics-node', so the path of least resistance was to use a similar name (SEO, support). Overwhelmingly, people use this lib in node.
- From the outset, we were mainly thinking about CF workers and server-environments. There are certain features that are server specific, like OAuth, and the 'batch-by-default' is a server convention. Node is still 'synonymous' with js on the server (even though that's changing, as it's got many competitors).
- Some other companies like stripe folded support for non-node runtimes into their node SDK, so I didn't feel like it was totally off-base.
Ultimately, this is something that we're still open to. I've even mulled the idea of retaining analytics-node and adding another library like 'analytics-javascript' (like a base library) or 'analytics-web-worker' (maybe just a thin wrapper around analytics node).
gajus
Based on @silesky 's comments in this thread, looks like @segment/analytics-node is perfectly fine to be used in browser.
https://github.com/segmentio/analytics-next/issues/771#issuecomment-1386987317
We want to minimize tracking impact on our website and we are considering several things:
@segment/analytics-node)@segment/analytics-nodeis better designed for this)We will try to replace
@segment/analytics-nextwith@segment/analytics-nodefor these reasons, but I wanted to flag that the current package name is causing confusion as we are adding this to React application.