Sencha Touch--Support 2 browsers in just 228K!
in [JavaScript]
|
Prev: FAQ Topic - What is JScript? (2010-07-16)
Next: How to find if statusbar is hidden or visible in firefox?
From: Garrett Smith on 18 Jul 2010 16:22 On 2010-07-18 06:10 AM, kangax wrote: > On 7/18/10 2:18 AM, Garrett Smith wrote: >> On 2010-07-17 06:25 PM, David Mark wrote: > [...] >>> >>> /** >>> * Forces the browser to repaint this element >>> >> >> The name "repaint" has the outward indication of a mystical incantation. >> We know that there is no way to force a repaint, and so when I see a >> name like that, I know that the method won't directly cause the browser >> to repaint and that it will, at best, perform an unrelated action that >> was associated with addressing a perceived problem. > > I'm not sure where you coming from with this. > Was there anything not right about that? > There certainly are observable ways to trigger both � reflow and > repaint; at least in WebKit (as that's the layout engine being discussed > here). > > In Chrome you can use Speed Tracer > (<http://code.google.com/webtoolkit/speedtracer/>, developed by Google > themselves, IIRC) to take a peek into when browser reflows the document > and when it repaints the screen. > So there are things that have been associated with reflow an repaint. > Try something like this, to see both � reflow and repaing hapenning at > ~3085ms: > [...] A repaint occurring there wouldn't be surprising at all. The browser is in a place where it it has new layout information and will need to queue up a repaint. After the stack of execution contexts has completed would be a good opportunity to do that recalc. The recalc is not guaranteed there. What the code does to trigger a recalc is probably pretty far from whatever it was that they perceived as a need for a recalc. > > Or am I missing something? > I don't know. What's wrong with the criticism I provided? Garrett
From: Garrett Smith on 18 Jul 2010 17:18 On 2010-07-18 02:06 AM, David Mark wrote: > On Jul 18, 2:18 am, Garrett Smith<dhtmlkitc...(a)gmail.com> wrote: > > [...] > >> >> That error will happen in IE but since IE is not supported they don't >> care. That exception won't happen in webkit so they get away with it there. > > Yes, this is yet another case of script developers hiding (current or > potential) problems from *themselves*. I cringe every time I hear "I > don't care about browser XYZ" or "Nobody uses browser XYZ" as an Improving quality reduces costs in the long run. Testing more browsers improves quality. Given an an unknown browser X the likelihood of the application failing in browser X inversely correlated to the number of browsers that it the app is tested working in. Testing in older shows how the app degrades or fails (degrading is preferred, failure and errors should be avoided). The marginal cost of testing in a desktop browser is low. The cost of fixing the bugs can be high initially, and for the inexperienced, this can seem not worth it, but as this is repeated, it becomes easier because the type of constructs that are known to trigger problems can be avoided. Limiting the set of tested browsers may initially reduce costs (because there is less work done), but at the cost of quality, which leads to increases in costs. [...] >> Sencha, or Ext for TouchScreen devices, supports only a couple devices, >> and at a nearly 500k, what does it do? > > So as not to cause confusion, I prefer to compare minified sizes (and > I can't see penalizing scripts for using long variable names). It's > bad enough that marketers report sizes after compression. I assume > you are referring to the size with white space and without comments. > Of course, it is 228K minified, but the CSS and graphics easily push > the payload over 500K. Add the application script, markup and assets ext-touch-debug.js..............458k ext-touch-debug-w-comments.js...928k [...] [...] >> >> The first problem is that it creates invalid selectors out of any >> perfectly valid selector that contains a comma. For example, Sencha will >> convert the selector '[title="Hey, Joe"]' to '[title="Hey,' and ' Joe"], >> both of which are invalid. Sencha then passes each item to >> document.querySelectorAll which throws an uncaught error on the invalid >> '[title="Hey,' selector. > > Oh for Christ's sake; that's right. They didn't even bother to wrap > the QSA call in a try-catch. Probably too elitist for them. Such > incompetence makes me bitter (and jealous). :) > Throwing an error for invalid syntax is fine. Throwing an error for '[title="Hey, Joe"]' is introducing an error that is not present in the browsers. [...] > >> >> There is no apparent reason for such design decision; the results are >> surprising and probably undesirable for most. > > Probably?! > I can assume that the intention of the program was not realized in the code. The documentation does not match the code and the code does not do anything sensible. It is hard to make assertions of what the author was thinking when the code looks mostly unintentional. The code explains what it does well enough. Extra effort was required to split on "," and create a loop and for what possible benefit? I really can't say. >> This appears to be a yet >> another careless mistake and one that adds the overhead of creating an >> array and looping through the result. > > All for no reason, unless they were literally *trying* to fall flat on > their face. > The function could have instead called `root.querySelectorAll` unfettered by the splitting and looping, and would have avoided all of those problems. Of course, it should be first checked that `root` is not null, as calls to `document.getElementById` can return null. >> >> Misleading Comment >> The code comment documents the selector param as a selector/xpath query. > > Hard to tell whether that is a misconception or a copy/paste mistake. I suspect it may be a holdover from previous jQuery-inspired efforts. Remember that older versions of jQuery supported XPath. [...] -- Garrett
From: David Mark on 18 Jul 2010 17:27 On Jul 18, 4:22 pm, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote: > On 2010-07-18 06:10 AM, kangax wrote: > > > > > > > On 7/18/10 2:18 AM, Garrett Smith wrote: > >> On 2010-07-17 06:25 PM, David Mark wrote: > > [...] > > >>> /** > >>> * Forces the browser to repaint this element > > >> The name "repaint" has the outward indication of a mystical incantation. > >> We know that there is no way to force a repaint, and so when I see a > >> name like that, I know that the method won't directly cause the browser > >> to repaint and that it will, at best, perform an unrelated action that > >> was associated with addressing a perceived problem. > > > I'm not sure where you coming from with this. > > Was there anything not right about that? > > > There certainly are observable ways to trigger both reflow and > > repaint; at least in WebKit (as that's the layout engine being discussed > > here). > > > In Chrome you can use Speed Tracer > > (<http://code.google.com/webtoolkit/speedtracer/>, developed by Google > > themselves, IIRC) to take a peek into when browser reflows the document > > and when it repaints the screen. > > So there are things that have been associated with reflow an repaint. > > > Try something like this, to see both reflow and repaing hapenning at > > ~3085ms: > > [...] > > A repaint occurring there wouldn't be surprising at all. The browser is > in a place where it it has new layout information and will need to queue > up a repaint. After the stack of execution contexts has completed would > be a good opportunity to do that recalc. They typically address this on exiting execution contexts, not at the end of the stack.
From: David Mark on 18 Jul 2010 17:42 On Jul 18, 5:18 pm, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote: [...] > > ext-touch-debug.js..............458k Not sure what sort of "debugging" they had in mind. All it does is hide mistakes, rather than throwing exceptions for unexpected usage patterns. But that measurement includes white space and penalizes long variable names. That's why I prefer the equalizer of a minification when making comparisons. jQuery (which does virtually nothing but queries) is 70K+; Sencha (which supports only two WebKit variations) is 225K+ and the full build of My Library (which does more than the two *combined* and works in virtually every browser known to man) is 140K +. And unlike the other two, mine is not hopelessly tangled up in interdependencies, which makes it easy to create much smaller custom builds. The marketers take the opposite tack of touting the sizes after compression, which just confuses the uninitiated. For example, the iPhone's cache limit is not based on the compressed size. For another, if your HTML is 50K and CSS 30K, will the addition of the "80K" Sencha Touch increase the payload by a factor of two or four? Of course, the answer is four; but if you are going by the advertised size, you would have to manually GZIP the HTML and CSS to find this out. The marketers know that many developers will simply assume that 80K of HTML/CSS is equivalent to "80K" of Sencha. [...] > > I suspect it may be a holdover from previous jQuery-inspired efforts. > Remember that older versions of jQuery supported XPath. > How old? I only remember seeing XPath in Prototype. And AFAIK, they are still trying to "support" it (despite the fact that it varies wildly from their other forks).
From: kangax on 18 Jul 2010 19:07
On 7/18/10 4:22 PM, Garrett Smith wrote: > On 2010-07-18 06:10 AM, kangax wrote: >> On 7/18/10 2:18 AM, Garrett Smith wrote: >>> On 2010-07-17 06:25 PM, David Mark wrote: >> [...] >>>> >>>> /** >>>> * Forces the browser to repaint this element >>>> >>> >>> The name "repaint" has the outward indication of a mystical incantation. >>> We know that there is no way to force a repaint, and so when I see a >>> name like that, I know that the method won't directly cause the browser >>> to repaint and that it will, at best, perform an unrelated action that >>> was associated with addressing a perceived problem. >> >> I'm not sure where you coming from with this. >> > > Was there anything not right about that? Well, you said that "repaint" is an indication of a mystical incantation. But browsers do repaint and do reflow; and there are well-known things that trigger these actions. I just don't see what's mystical or magical about that comment. [...] >> >> Or am I missing something? >> > I don't know. What's wrong with the criticism I provided? Oh, nothing is wrong with the rest of the message :) I was only curious about the "repaint" part. -- kangax |