add change events?

[ebrensi]

add change events?

[andrepxx]

It's a good idea, if these will be optional - for example, initialize the event handler to an empty function by default.

It's just that "live update" is detrimental for my use case, since I use this control mainly in my go-dsp-guitar application, where I use this to control parameters of audio processors.

In this application, I send an AJAX request to the processing plugin on value change and if I do that too quickly, an earlier event could arrive at the processing backend "later" due to IPC or even network latency. (AJAX is asynchronous.) That in turn could lead to the processing backend still calculating with an "old" value - one that was sent earlier, but arrived later through the IPC. Of course, the frontend could introduce a "counter" and the backend could use that to determine the most recent value, however, I'd still "hit the IPC" pretty hard and produce quite some overhead.

That's the reason why I don't "like" / need "fast updates". ;-)

However, as long as it's optional, it should be okay. :-)

[ebrensi]

Have you considered using a websocket?

[andrepxx]

Well ... not really.

I began working on go-dsp-guitar (which, back then, was just called dsp and wasn't implemented in Go, but rather a wild mixture of Python and C :-) ) in October 2013. In summer 2015, I started over in Go.

I was familiar with the properties / API of XmlHttpRequest (and had "boilerplate code" lying around for it), but not WebSocket (which was fairly new technology back then), so the former was less effort for me to integrate. Changing that after everything was already settled for XHR because it "might" handle updates better would be a non-trivial amount of work - and if you realize that "fast updates" are a problem, then you probably already have a lot of working code. Like most open-source developers, I work on these projects in my spare time and have to do other things to earn a living, so development time is scarce and trying to port this over to WebSockets was definitely not a priority.

Also, the web server in the Go standard library has TLS and HTTP/2 support, but no native WebSocket support. You'd either need "golang.org/x/net/websocket", which has no promise to remain stable and which Google itself claims to be "not well-maintained", or a third-party library, where you might also have to care about long-term stability / availability, potentially quality, and additionally also about legal / licensing stuff. These libraries would bind into the "connection hijacking" interface of the web server, let the web server handle the TLS handshake, etc., and then perform a connection "upgrade" to WebSocket, after which they'd take over.

So yeah, the reason why this is done with XHR instead of WebSocket is basically "inertia". ;-)

It's also very easy send XHRs via, say, curl, for testing. Not sure it's so easy for WebSocket.