3 ms·

Actually, what killed both is market size. Internet boom === small simple apps where emphasis is either on looking good or being very responsive. That meant t

Actually, what killed both is market size. Internet boom === small simple apps where emphasis is either on looking good or being very responsive. That meant that vast majority of developers where not in a market for rich GUI stuff, but for better CSS and smaller size. OTOH desktop never rewarded simple apps. Distribution and marketability asked for more features exposed via GUI, thus most developers where OK with bigger in scope GUI stuff. As for "next browser breaks your stuff" excuse, I think it wasn't true for a very long time now. Include polyfills, css defaults reset, do transpiling into less features and you are good to go. OTOH, web underwent multiple groundbreaking shifts in computational models. This is why complex but somewhat encapsulized/localized Angular/Ember won over spaghetti inducing predecessors and why truly encapsulated/localized Reacts eats old Anguler for breakfast. One last point would be about crazy stuff in programming languages / programming paradigms that was already available in 60's and 70's at least as a statements of need. Those made for very stable platform on which GUI ecosystems could be build. Relative instability of JS with generational changes can explain why it gets a new ecosystem every few years.

tabtab 6y ago
Big GUI apps don't need a big download packet, assuming a good "GUI browser" that can shift most domain logic to the server. Just make each window/form/panel an independent packet. An application can have say 5,000 forms, but if you only activate 30, then it only downloads 30 (plus a few reference files for constants and defaults. A pre-loading a larger set perhaps can be on option.) Re: "As for "next browser breaks your stuff" excuse, I think it wasn't true for a very long time now." I'm not convinced yet. It may be improved, but not solved (mostly because IE can finally be considered dead.) The current candidates have long learning curves, are version fragile, or both. Corporate products tend to target specific browser(s) to reduce the version risk, but that's not really solving the problem, it's reliance on a mono-culture just like MS-Windows. Regardless, IT still needs a stateful GUI markup standard, at least to help desktops be cross-platform. It would improve desktop standardization even if the Internet ends up ignoring it. The X Window System is a useful idea, but is designed for LAN's instead of WAN's and internet, partly because it doesn't buffer UI i/o, creating too much interaction latency.

tabtab 6y ago

Big GUI apps don't need a big download packet, assuming a good "GUI browser" that can shift most domain logic to the server. Just make each window/form/panel an independent packet. An application can have say 5,000 forms, but if you only activate 30, then it only downloads 30 (plus a few reference files for constants and defaults. A pre-loading a larger set perhaps can be on option.) Re: "As for "next browser breaks your stuff" excuse, I think it wasn't true for a very long time now." I'm not convinced yet. It may be improved, but not solved (mostly because IE can finally be considered dead.) The current candidates have long learning curves, are version fragile, or both. Corporate products tend to target specific browser(s) to reduce the version risk, but that's not really solving the problem, it's reliance on a mono-culture just like MS-Windows. Regardless, IT still needs a stateful GUI markup standard, at least to help desktops be cross-platform. It would improve desktop standardization even if the Internet ends up ignoring it. The X Window System is a useful idea, but is designed for LAN's instead of WAN's and internet, partly because it doesn't buffer UI i/o, creating too much interaction latency.