3 ms·
I'm not seeing how thick vs thin clients has anything to do with the html5 vs. native debate. You can build an html5 based app that's just as "thick" as a nativ
by elpool2 14y ago
I'm not seeing how thick vs thin clients has anything to do with the html5 vs. native debate. You can build an html5 based app that's just as "thick" as a native iOS app, it just uses a different technology to render the UI.
- rodion_89 14y agoUI rendering and a sane threading model are two major steps that could end these premature HTML5 vs native debate. I wait for the day when these debates are equivalent to arguments about programming language preference.
- wahnfrieden 14y agoWhat's insane about web workers? (Just curious.)
- rodion_89 14y agoI actually like the way Web Workers can't touch the DOM. It's nice to finally give the DOM it's personal space for UI operations, which often leads to much more responsive apps especially at a large scale. The pain points for me come in the form of shared dependencies. Large pieces of code that are accessible to multiple threads, and perhaps the UI thread, must get imported several times. The lack of access to localStorage hurts in a lot places because any cache access must send data back and forth on the UI thread for operations that are probably entirely unrelated. The lack of console.log makes debugging considerably worse. There are a couple of hacks to get around this but it's a bit crazy to pass messages between threads just to get a log printed. Having to create a file per thread is very much a pain. Certain operations are tiny in terms of code and make more sense in the context of where you want to run theme. It'd be nice to run any function on a separate thread. Conceptually that would get weird because it would violate several properties of JavaScript closures. But it'd be nice to find some acceptable way of doing this sort of thing. Web Workers are pretty good but can be unfriendly to developers at times.
- wahnfrieden 14y agoThanks for elaborating :) Good points.