Thread by @MartinDotNet

Adding to the hills I will eventually die on... RUM is not a tool for engineers. (The tool, not the drink, we definitely need the drink)

Yes, you need to see what real users are doing in production. However, the way that the information is used, and by who, is very different.

Giving engineers an idea that "this page is used a lot", or "the rendering on this page is slow" isn't good enough. We've been through this on the backend with coarse metrics that lack context. It's just not good enough. You're doing your users and operators a disservice.

We're in a world where we have entire applications on the frontend in javascript with React and Vue (as SPAs) becoming the de facto standard. These aren't individual pages anymore, even if you appear to transition between them. These are now complex application models!

Engineers have rich information about their APIs and microservices using tracing on the server. We've proven that it's the only way to have the level of observability of their systems they need to support them. Yet, on the clientside, we're giving them page views and render time?

We need to look at the clientside as a firstclass application in our stacks. We need to give it the attention we give the backend in terms of #observability (if not more, really)

RUM is for user analytics, marketeers, and conversion specialists.
Frontend Tracing is for engineers

We need to have visibility of the logic paths that our customer click event takes, what APIs it hits, with all the context of those and deep casuality flows

We need to correlate browser versions with applications flows so we can see the common paths failing for each

We need to be better. Logging errors is not enough.

Slow is the new down, and if your API is fast, but your frontend is slow and buggy, IT DOESNT MATTER.

Demand more from your tools. Demand more from your frameworks. Stop guessing and start instrumenting more.