> Oh, who knows what will happen. But there are indicators that this time > may be different: > > 1. WebAssembly is a web standard > 2. General support for web applications is getting better (e.g. service > workers) > 3. Canvas-rendering web apps now exist (Google Sheets) > 4. Better connectivity makes “large” web apps more feasible. > > 5. The project _may_ end up providing limited value to Qt users, but I think > it would be a mistake to conclude so up front,
I have taken the liberty of changing your bulleted list to an ordered one. 1. True ActiveX was extremely limiting, NaCL less so, Emscripten/asm.js less so. I can't really argue much difference between WebAssembly and asm.js though, given asm.js's previous performance claims. 2. I have no comment 3. Such apps are designed from ground-up for canvas. I don't know that a Qt app will scale accordingly. I tried WebGL for my app and it simply did not work. Maybe there are large gains, but he approaches are in the same vein. 4. a. While true, it hasn't been exponentially true like with most things in computing ( in terms of average speed https://www.pcmag.com/Fastest-Mobile-Networks ) Maybe with 5G that will change. Additionally, unless you can very slickly progressively load it, no one wants a 5-second delay or even 3 second delay. It's also rather biased to first-world countries and metropolitain customers. I doubt that's who Nokia had in mind for their "next billion". (The point being while now not technically limited by spec, you're still limited in practice) b. Another point here is that the mobile web is taking off with less powerful ARM processors... c. on Data plans that meter data... 5. Given the effort required it may be considered "low-hanging fruit" and provide value in the interim. However the maximally utilitarian solution is to stop cramming binaries into browsers, and run apps that properly utilize the browser no matter how twisted standards it uses. Given the limitations outlined above, and considering the ecosystem implications, I am left to conclude that Qt needs to include a proper web component. _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
