The first prototype of Look at Time was built on a beefy machine with lots of computing power and at the experimental stage this project was I didn’t ever put more than 6 events on the screen.
That changed when I created my first ever timeline for a real use case:
“The history of Virtual Reality headsets”
At some point after adding 10 or more time events to the timeline, the UI got sluggish and it began to dawn on me that I could not proceed with new features until I had significantly improved the visual performance.
Fast is a relative term
Vue was the framework of choice when I started implementing the application because it is said to be fast and lightweight, but fast and lightweight is a relative term. Look at this performance recording I took from a newer version of the application and notice the numbers in the “frames” row.
If you want to move a lot of elements in real-time like we do with Look at Time you have to optimize these parts of your code for efficiency. The zoom mechanism worked in a way where it would calculate the position of each new time event and pass that as a prop to the Vue component. The framework (no framework actually) is not up to this task.
Bypass the framework for everything that needs to be fast.
I removed the position prop from the component to avoid Vues evaluation cycle on every position change. Instead the position is altered through a regular setter call on the time event model which is a typescript class holding information on the time event and it sets the “left” property on the HTML element. It’s less intuitive but 10–100x more efficient.
Lesson learned:
Real-time in browsers isn’t a free lunch.
