- From: Sylvain Galineau <sylvaing@microsoft.com>
- Date: Thu, 20 Dec 2012 21:16:58 +0000
- To: François REMY <francois.remy.dev@outlook.com>, "Ian Hickson" <ian@hixie.ch>
- CC: CSS WG <www-style@w3.org>, Tobie Langel <tobie@fb.com>, Tab Atkins Jr. <jackalmage@gmail.com>
>I’m not saying JavaScript-based layout managers are bad (actually, I think they’re going to be more popular over time, >particularly when tools will support them better) but that most designers will probably want to use the layout managers >they know and love instead of relying on JavaScript code they can’t understand. Not sure what you mean by 'good' or 'bad'. As in perf? As usual the answer is that it depends on your use-case. We've had some experience with the kind of model described by Tab for the type of control you describe in your doc e.g. a large grid of movie or book tiles, for instance, or any data set for which user activity involves much panning while your app pools and recycles nodes etc. Pretty quickly you may find yourself spending a lot of time running your JS layout code. Even if that layout is simple it's not hard to reach a point where you spend more time running it than you've saved in engine layout time. (Some of which, to be fair, may also have to do with the aging clumsy string-based APIs we still use to do this kind of work today). But as in everything there are trade-offs. It's quite possible that some scenarios would benefit from letting the app do its thing in JS at runtime. But I suspect this will also take better, newer APIs and, as Tab pointed out, some additional primitives to optimize a few common building blocks.
Received on Thursday, 20 December 2012 21:18:35 UTC