"History never repeats", but you can certainly look over it again when when you have a chart.
It also helps quite a deal when you have a data source to fetch it from. However fetching price history from an exchange only provides you with the raw price history. It's all numbers and thus hard to discern the trends.
Thus with the "magic" of mathematical equations, we can crunch the numbers and graph patterns that make more sense to our visually orientated minds. These are referred to as indicators, because, they indicate some sort of trend in the price. With this you can make an educated guess and make some trades that are a little more informed.
It is these indicators that I've started implementing in the chart.
Now, I have the "pipeline" for indicator implementation, but... have hit a snag. The chart is reliant upon the talib for the indicator calculation. I use this library because it is more or less a standard for the breadth of the indicators it uses. Secondly it is written in C so it is speedy when having to process large amounts of data.
To implement this in a browser, the library is compiled to a Web Assembly file (WASM). Great! Or so at least I thought so, until I started to frequently run into issues on various hosting platforms where they are misconfigured or have some sort quirk, leading to the WASM file being served with the incorrect mime type which means the JavaScript libraries can't instantiate them.
I've tried a couple of versions, but so far, none of them perform 100% under all circumstances.
One plays it smart, and has the WASM converted to a string that is then re-encoded as data:application/octet-stream;base64 which JavaScript needs to compile the WASM. So, if I could combine that with the other library, I might have solution that is function in 100% of all instances.
However, to do so, is to learn another level of complexity, that sidetracks the main chart development. I'm currently considering and researching my options.