Thanks to Val's excellent newsletter, I've had my first glance at
BrowserViz. I'm glad to see something that is more flexible and low-level
than e.g. shiny.
I'm curious about the motivation behind web sockets. I guess any
application with an R-driven web UI actually has two UIs: the R console and
the browser. But what if the R session is headless, or if there is no need
for commands in R to affect the browser? Then the web socket layer brings
mostly unneeded complexity. An interesting comparison to BrowserViz is not
shiny but OpenCPU. It's purely HTTP-based and still manages to maintain
state (not sure how efficiently). I guess one advantage of web sockets is
that one can program imperatively instead of declaratively on the server,
i.e., the server can send a command to show a popup in response to some
event, instead of returning a "declaration" that the popup should be shown.
So essentially web sockets are more natural for implementing server-side
controllers (think MVC), instead of just the data model, but man, it's a
shame to lose the features of HTTP.
Ultimately, I think we want web apps that are easy to develop and maintain,
and run equally well from either a useR's session or a remote client
communicating to a dedicated, headless server. Is the generality of
websockets worth the complexity?
As an aside, it would seem relatively straight-forward to implement a
simple bi-directional RPC mechanism between R and JS using the standard
protocol (i.e., hide details like the callback). Does that sound reasonable?
I was also a bit surprised about the need to copy/paste the JS boilerplate.
Certainly there must be javascript frameworks with a more elegant solution
to extensibility.
[[alternative HTML version deleted]]
_______________________________________________
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
