Because, with currently available components, there is no way to ensure the PLC gets its bit released (in a reasonably short bounded time, typically ~100ms) if:
-
The browser hard crashes while the button is pressed,
-
The browser encounters a javascript bug or sandbox violation while the button is pressed,
-
Some other javascript operation hogs the CPU(s) (charts for the win!), delaying recognition of the mouse release,
-
The websocket gets cut off between browser and gateway (for any reason).
PLC I/O protocols use a fast, continuous stream of repeating messages to indicate continued health in each direction, and PLC firmware has built-in support for relaying that health information to the logic that needs it.
No such beast is built into any PLC's request/response protocols, nor built into any browser.
You can approximate it by sending precise timestamps (or similar messaging) along with the desired state at close intervals from the front end. But Perspective doesn't run scripts on the real front end, so there's no way to cobble this together. (You can in Vision.)
Adding such a component to Perspective is on my to-do list for my EtherNet/IP module, similar to the button with that robust functionality I created for Vision. It is part of that module because a UI component can only cover the gap between client and gateway. To cover the gap from gateway to PLC across numerous non-robust protocols is a nightmare I don't want to touch or have any association with. So my component (future components) only works with variables in my class 1 communications drivers, where the GW-PLC gap uses an I/O protocol.