Hacker News new | past | comments | ask | show | jobs | submit login

I'm the original author of the post.

I was talking about Parse.ly's analytics engine, where most of the data we provide to our customers on first-party analytics around their audience stems from some lightweight JavaScript code they embed in their websites. It's now installed on thousands of high-traffic sites[1] and provides analytics on over a billion web/mobile browsers per month (as described in this Strata talk[2], for example).

I wrote a little bit about my experience writing that code in this HN comment: https://news.ycombinator.com/item?id=10206956#10207998

It was a fascinating piece of code to work on because not only did it have to be lightweight and fast across all browsers, but it also had to be tiny to embed, and it needed to be x-browser tested all the way back to IE6 and strange mobile browsers. Plus, at the time it was originally written (2010-2012), there were hardly any good JS build tools outside of early versions of uglifyjs.

Over the years, other engineers have improved the performance even further, while retaining the kernel of the code. We even did a change last year which improved client-side performance through a number of clever build/CDN tricks. We've also had to hold our ground firmly on privacy, which it turns out is one of the key areas third-party JavaScript started to take a turn in the wrong direction, especially in the adtech universe. (We are a content analytics company, with a similar SaaS business model to MixPanel for product analytics and NewRelic for performance analytics. So, for us, privacy is paramount.) I wrote about this here: https://blog.parse.ly/post/3394/analytics-privacy-without-co...

[1]: https://trends.builtwith.com/analytics/Parse.ly

[2]: https://conferences.oreilly.com/strata/strata-ny-2018/public...

Very cool and interesting stuff. Many thanks for the reply and info.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact