@dashrender said in VDI Options - Modernization:
@scottalanmiller said in VDI Options - Modernization:
@pete-s said in VDI Options - Modernization:
@scottalanmiller said in VDI Options - Modernization:
@pete-s said in VDI Options - Modernization:
I'm not talking cached files here but client side databases and local storage as defined in html5. Another reason you might insert VDI into the chain.
Worth pointing out that this "should be" a configuration thing and not something you need heavy VDI to work around. But here in the real world, it isn't always configurable and VDI can be used to deal with that.
Yeah, it depends entirely on what the html/javascript code looks like. Which in most cases depends on what framework was used.
It was easier to keep track of the data when a html browser was as dumb as a vt100 terminal.
Wanna take bets that a new "HTML-lite" protocol surfaces that has modern GUI and graphical components, but none of the heavy data-handling components so that people can be confident that no data leaks beyond what is seen on the screen?
why did some move away from that model in the first place? to put the processing power onus on the end user?
Oh it makes TONS of sense. If you saw every day apps built both ways side by side you'd chose this "every" time. First, it saves the hosts and the ISPs tons of money because it shifts lots of processing power out to the end units where typically there is loads of excess power. Why do something in an expensive way when there is a free way waiting to be utilized?
Second, it makes websites a lot faster. I mean a LOT faster. It means you can do lightning fast calculations without waiting for long internet round trips, you can cache data, etc.
Third, you can work offline. People always complained that apps were unable to work offline. This is what allows things like email or document editing when you still lose your Internet connection, and what allows many things to keep working when your Internet might be flaky.