Possible Ways to Extend Browsers
We already do "extend" browsers with things like "external viewers." But there's not a very good integration with the browser. Ideally those external viewers should be rendering in-place inside the document, and be working together with the browser, be tightly integrated with the browser and other parts...
So, a solution is what's been touted under with name "component software". The basic idea is that, rather than buildig one single monolithic application that does everythig from day one, we should be building a framework or architecture that ican be dynamic in its ability to have functionality added or deleted on the fly.
I can't tell how much of the problem is technical and how much is political.
Like, component based applications are in a sense profoundly anti-corporate-capitalist in that nobody can reasonably expect to control the 'look and feel' of a user's actual experience or cockblock their competition on the user's machine.
The unix shell does composability between totally independently developed things well, on the other hand.
What are the limits?
How did / do shell tools fail in them?
What if there were, I don't know, some lightweight application-wrapper that could be tossed around shell tools?
Or does that fail to address concerns of the GUI space?
(I've never designed GUI tools, and always found the space vaguely mystifying.)
@dredmorbius @a_breakin_glass @eliotberriot @natecull
GUI toolkits aren't really designed around composability. combining bits of one widget with bits of another means rewriting both, usually. widgets can't overlap, except special frame-type ones. each window is its own little domain. applications don't by default have the ability to embed each other's components. a non-technical end user certainly can't mash up two apps.
Just for speculation, would a GUI widget be more composable if it were seen as a Unix-like pipe/filter mapping a stream of input events (with initial/accumulating state) to output events?
(Doing so would require a framework where an 'event' or a 'message' is itself an object; which I think Smalltalk can do but not many other OOP systems)
Or can GUI widgets fundamentally not be implemented as a stream/filter model at all?
This is where I'd *like* to think that something like functional reactive programming can simplify the usual GUI-widget object-and-callback mess. But I'm not sure the dust has settled from the various FRP paradigms figuring out what works, yet.