When I found myself spending more and more time researching ways to sidestep the features of React to eek more performance out of the interface, I started to ask myself if this was the best approach for my use case. While I have a great deal of respect for React, and Angular which I used before that, I’m increasingly convinced that such intrusive frameworks are not the right approach to this sort of project. The main reason being that the centerpiece of this application has to be the audio engine. Any CPU cycles lost to a heavy user interface framework, updating, or even checking if something needs to be updated, are cycles that can’t be used to push audio, and reduces the chances of this tool running on a variety of platforms and browsers.
In me previous post, Creating a Simple, Fast Pattern Editor in HTML, I described how I was running some experiments into low latency, high performance rendering of a pattern editor, the primary component of the interface. This experiment took on a life of it’s own. The more I realised it was orders of magnitude faster, and more importantly, predictable, I became more and more convinced this was a better and more appropriate approach to the user interface of WeTracker. To be clear, by predictable, I mean that everything that happens in the system happens in a way that I am intimately aware of and in control of. I’ve been able to achieve more in the few hours of coding in this methodology than I did in days with React. Not because there’s anything wrong with React, in fact I’m certain to work with it again, this has proven to be a useful introduction to the React framework and I’ve enjoyed working with it. The problem I faced was not knowing the conditions under which things were happening. Normally, this would not be an issue, I’ve written large Angular based applications where this feature is indeed a necessity, as keeping track of lots of dependent changes would have been unworkable. However, for WeTracker, the most important thing is to know that only what is needed is being updated, and it’s being updated as fast as feasibly possible.
I’m not being a complete luddite in creating this new reboot, I’ve included a very simple and light signals/slots mechanism that I found, and I’m using ImmutableJS or state management, much like React/Redux, but I’m applying these design principles in a controlled way, and moreover in a way that ensures I have completely clear and understandable picture of what is happening and why.
As of today, I’ve cleared out the old React code (it’s still there in git if anyone wants to look) and moved the experiment up to root. This will now be the basis for ongoing work, and the principle applied at all decision points will be “if I do it this way, am I still going to be in control, and am I still going to know what is happening and why?”.
Onwards and upwards.