3 ms·
I propose not stopping at input-buffering. Keep going, how fast could we get the REPL times if that were the KPI? I doubt we'd be doing full page redraws and s
by MrLeap 2y ago
I propose not stopping at input-buffering. Keep going, how fast could we get the REPL times if that were the KPI?
I doubt we'd be doing full page redraws and slinging json of all things. I think what you'd end up with is something that looked a little more like a game engine than react. That would be a fun project to work on.
- jerf 2y agoA REPL might be an option, you do have Javascript sitting right there, but is not generally the sort of "expert" I'm thinking of. I certainly wouldn't stop at input buffering. Another I'd want is some sort of systematic keypress discoverability. You still probably want a conventional GUI at least mostly available but using the GUI ought to be constantly teaching the user how to do whatever it is they just did with the keyboard instead. This might as well get wrapped into the framework, to standardize it and to make it easy to use.
- mike_hearn 2y agoIt's worth recalling that in the early days, GUIs always had underlined letters showing what the keyboard shortcuts are. That's been lost now, I suppose because it looked messy or confused people or something. Some tools show you the underlines only once you push the modifier key that can activate them. Unfortunately, one of the many shortcomings of the web as an application and GUI platform is (a) no menu bars, (b) no context menus, (c) no accelerator key framework, (d) keyboard focus is often nowhere in particular or somewhere stupid that will do something bad if you touch the keys.