analytics-next
analytics-next copied to clipboard
Rename @segment/analytics-node to @segment/analytics-javascript
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:
- disabling loading of device-mode destinations (looks like this would be the default with
@segment/analytics-node) - adopting Partytown (looks like this
@segment/analytics-nodeis better designed for this)
We will try to replace @segment/analytics-next with @segment/analytics-node for these reasons, but I wanted to flag that the current package name is causing confusion as we are adding this to React application.
@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).
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).
This would be the preferred option overall. However, also the biggest overhead. So just being respectful of the effort when composing my suggestions/asks.
Also used this post as sort of sanity validation to ensure that we are not way off-course by adopting this in browser. Seems like not the case.