How JavaScript works: the rendering engine and tips to optimize its performance | Hacker News Reader

How JavaScript works: the rendering engine and tips to optimize its performance

blog.sessionstack.com

209 pointszlatkov11 comments

This is somewhat off-topic, but has anyone here used SessionStack?

How well does the service work, and is there a noticeable performance impact for the software to record on mid-range mobile devices?

It looks really interesting and would probably be really helpful, but I can't include anything else in our applications that will further tax our already struggling lower-end devices with more code that needs to run and more data that needs to be transmitted.

Co-founder of SessionStack here :) I'd be happy to show you a personal demo, explain how SessionStack works and explain why it won't impact the performance of your product. Can you ping me at alex@sessionstack.com?

Will do, and I was planning on trying out the service at some point (we use Sentry and discovered you through their integrations page), but I figured I'd take this chance to see what kind of experience others are having.

To explain just briefly, SessionStack is just collecting events from the browser like user interactions, DOM changes, etc. and then tech info like crashes, network, debug messages. All of this data is being batched in memory and sent to our servers every few seconds. And that's all the work that we do on the client-side, almost the same as any analytics tool that you already use. The "magic" happens on our end, where we're reconstructing all of this data, pulling the needed static resources, etc. in order to recreate the same series of events as they happened to your users and show you that information visually. And this happens in real-time.

I'm not sure about the implementation in Session Stack, but I work at LogRocket (https://logrocket.com) where we're solving a similar problem. We use a few methods to ensure that we have a minimal overhead on performance.

- We use worker threads for data encoding and network I/O

- We use the MutationObserver API for capturing diffs of the DOM

- We pull static resources directly from an application's servers (vs uploading from the client)

- Loading method shims first (and later the rest of our SDK asynchronously) to reduce initial loading time

- Batching requests and waiting for network downtime to send data

- We use Protobufs as a wire format for reducing bandwidth

I'm sure Session Stack employs some similar techniques- would be curious to hear about methods they're using as well.

As the first LR evangelist (there are many now) at my workplace I am always curious how you guys do what you do. Looks like pure magic.

I've poked around in the console a fair amount but would be really interested in two things you listed above:

- "We use the MutationObserver API for capturing diffs of the DOM"

- "We use Protobufs as a wire format for reducing bandwidth"

I know you all write pretty awesome JS articles on a regular basis but I have so many questions about how LR works! Spill the beans but not the secret sauce!

> - We use worker threads for data encoding and network I/O

Is this open sourced? I would like to understand how this works? (how do you capture network i/o?)

We've been using SessionStack in our team for around 6 months now (along with their native Sentry plugin) and there hasn't been any impact on our web app (it's a quite heavy React app).

I'm very happy to hear that!

If you have any feedback or need assistance, you can always reach me at alex@sessionstack.com or ping us in our live chat inside the product :)

It's called "layout" in the article, and it's reasonably well represented.

Reply on news.ycombinator.com