SSHing into a terminal with your phone is terrible UX. Very low bandwidth. Voice input into a native app is not. We are not talking about fine grained control of your system by running explicit commands. We are talking about programming in plain English.
I can use ssh as the transport and authentication layer over any internet connection through a fairly easily learnable set of ssh flags that can be further simplified through aliasing. As a bonus it's e2ee. The overhead from that affects latency but not bandwidth. Let's set aside ssh for a second. Streaming voice over the internet is a long-solved problem, I've been able to host a mumble server on a toaster since forever ago. So if the local machine can recognize voice commands, talking through a phone shouldn't make a difference. Like, if this works locally, and it works on the phone or whatever, why is having it talk over the internet the hard part? Whatever you think of the application itself, this is a weird failure mode
I can't believe this isnt better understood. Style definitions on reusable components are good. The idea that your css doesn't have to know about your html just creates tons of problems and complexity. Global themes and reusable styled are fine.
If we are talking about statically defined html then sure. make your global css files.
>Here, we don't have winter, fall or anything anymore. The acid rain from the 90s destroyed most of green on adjacent cities and when it is hot it gets in unbearably hot and when it is cold it gets stupidly cold.
How is it you dont have winter anymore but when it gets cold it gets stupidly cold?
> To test DOM access speed simply compare processing speed during test automation of a large single page app with all DOM references cached to variables versus the same application with no such caching. I have done this and there is a performance difference, but that performance difference cannot be noticed until other areas of the application are very well optimized for performance.
This was my instinct. Remember, the author is a hammer. His role is to find performance issues in the frontend. His role is not to find performance bottlenecks in the whole system.
reply