Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Javascript > Sencha Touch--Support 2 browsers in just 228K!

Reply
Thread Tools

Sencha Touch--Support 2 browsers in just 228K!

 
 
Ry Nohryb
Guest
Posts: n/a
 
      07-19-2010
On Jul 19, 8:25*am, David Mark <(E-Mail Removed)> wrote:
> (...) The
> question is why you would need to do that with the styling equivalent
> of a no-op. *The answer is that you wouldn't unless you were stuck and
> resorting to programming by mystical incantation.


I always read before posting: it was a reply to Garrett's assertion
"We know that there is no way to force a repaint", which is -plainly-
false. See:

"Faster HTML and CSS: Layout Engine Internals for Web Developers",
David Baron.
http://www.youtube.com/v/a2_6bGNZ7bA

>
> Please read before posting next time. *Thanks!


You're welcome.
--
Jorge.
 
Reply With Quote
 
 
 
 
David Mark
Guest
Posts: n/a
 
      07-19-2010
On Jul 19, 3:12*am, Ry Nohryb <(E-Mail Removed)> wrote:
> On Jul 19, 8:25*am, David Mark <(E-Mail Removed)> wrote:
>
> > (...) The
> > question is why you would need to do that with the styling equivalent
> > of a no-op. *The answer is that you wouldn't unless you were stuck and
> > resorting to programming by mystical incantation.

>
> I always read before posting: it was a reply to Garrett's assertion
> "We know that there is no way to force a repaint", which is -plainly-
> false.


Which was pointless.

> See:
>
> "Faster HTML and CSS: Layout Engine Internals for Web Developers",
> David Baron.http://www.youtube.com/v/a2_6bGNZ7bA
>


As is that. You are your videos.
 
Reply With Quote
 
 
 
 
Ry Nohryb
Guest
Posts: n/a
 
      07-19-2010
On Jul 19, 9:04*am, Garrett Smith <(E-Mail Removed)> wrote:
> On 2010-07-18 10:51 PM, Ry Nohryb wrote:
> (...)
>
> > For example, this (google groups) page can be forced to repaint with:

>
> No, it cannot. About the best you can do is hope that the browser will
> repaint.
>
> So you've made observations of what happened in the browser and
> concluded that those observations are premises for causality, huh?
> (...)


What I said is not based on any "mystical incantation" but on what the
author of Mozilla's rendering engine explains in this video:

"Faster HTML and CSS: Layout Engine Internals for Web Developers",
David Baron.
http://www.youtube.com/v/a2_6bGNZ7bA

Obviously you too (I told Mark already) ought to see it in order to
learn the fundamentals of the inner workings of rendering engines, and
once you begin to see through the black box, you (and Mark) will be
able to stop thinking about it any more in terms of mystical
incantations.

HTH,
--
Jorge.
 
Reply With Quote
 
Garrett Smith
Guest
Posts: n/a
 
      07-19-2010
On 2010-07-18 08:26 PM, David Mark wrote:
> On Jul 18, 10:15 pm, Garrett Smith<(E-Mail Removed)> wrote:
>> On 2010-07-18 02:42 PM, David Mark wrote:
>>
>>> On Jul 18, 5:18 pm, Garrett Smith<(E-Mail Removed)> wrote:

>>
>>> [...]

>>
>>>> ext-touch-debug.js..............458k

>>

[...]

>
> And speaking of the other efforts; you mentioned that ExtJS was the
> worst of the worst with respect to queries. But I don't know how you
> could get much more inept than Dojo's, which relies on their "attr"


I did not review Dojo's in depth, but the overall design approach makes
more sense. From memory, dojo uses its own engine first, and if that
works, then it tries to use NodeSelector the next time.

> function, which has always been complete gibberish. It's only a
> couple of dozen lines of code and I once tried to explain its illogic
> to them, but they just kept chirping: "show me where it fails". I was
> reluctant to do that as it would predictably lead to patches without
> understanding (or fixing) the general problem. But even after
> producing a couple of failure cases, they were still hesitant to
> change anything, lest they break compatibility. Of course,
> "compatibility" that produces one result in IE8 standards mode and
> another in its compatibility view is not something to preserve.
> Furthermore, their "vaunted" widgets and parser rely heavily on this
> function, so the mistakes manifest themselves in virtually everything
> they do. Their forums, mailing lists, etc. are full of confused
> questions (and even more confused answers) related to these issues.
>


The predicament is that fixing the broken abstraction affects the
dependencies.

Changes to low-level abstractions propagate to higher level abstractions
and the result is instability.

The alternative to causing such instability -- and which Dojo has seemed
to favor here -- is to not fix the bugs.

Of course the problem with that is that everything is broken and as you
pointed out, broken differently across different browsers, rendering
mode, etc.

An low level abstraction that is fundamentally broken is a serious problem.

>> Regardless, NFD is a design mistake, no matter how
>> popular it becomes and no matter many libraries copy it.

>
> Of course it is. A child could see that.
>
>> The reason I
>> mention this is it seems that Ext-JS has been following what jQuery
>> does, copying the mistakes and adding its own mistakes to that.

>
> It appears that way. And they have the gall to charge people to use
> recycled garbage.
>


Well, if it is coming at premium cost, there will be those who think
that it must be better.
[...]

>>
>> | Provides high performance selector/xpath processing by compiling
>> | queries into reusable functions. New pseudo classes and matchers can
>> | be plugged. It works on HTML and XML documents (if a content node is
>> | passed in).

>
> That sounds like an optimistic appraisal of ExtJS, but Sencha Touch
> does nothing of the sort. It "compiles" nothing and certainly won't
> work with XML documents.
>


Ext-JS -- not Sencha -- dynamically create functions that they reuse.
This is what they mean by "compiled". that doesn't apply to Sencha, but
just an FYI about what they mean by "compile".

[...]

>
> That's not right. For one, a checked attribute cannot be
> "true" (except in an invalid document) and the :checked pseudo queries
> the *property* so as to take user input into account. Fortunately, I
> think that's what they all do anyway; but unfortunately, they do the
> same thing when querying the CHECKED attribute. In my experience,
> most of the participants in these projects don't know the difference.
>


Not all, and there are some that check attributes. NWMatcher is
cognizant of that, at least.

[...]

>
>>
>> | * E:not(S) an E element that does not match simple selector S
>> | * E:has(S) an E element that has a descendent that matches simple
>> | selector S
>> | * E:next(S) an E element whose next sibling matches simple selector S
>> | * Erev(S) an E element whose previous sibling matches simple
>> | selector S
>> | * E:any(S1|S2|S2) an E element which matches any of the simple
>> | selectors
>> | S1, S2 or S3//\\
>> |
>> | CSS Value Selectors:
>> |
>>
>> These will all throw errors in Sencha and they do not work in Ext,
>> either, as you've reviewed the section of code the reads styles, and
>> that returns different results, when trying to read:
>>
>> {visibility=visible}
>>
>> - the result returned depends on the browser and how styles are calculated.

>
> Yes, using these things to query by style values is even less
> predictable than querying by attribute values.
>


It is.

The selector engine can be accessed from both
Ext.Element.selectorFunction and Ext.query. These are core abstractions
in the library and are accessed from two core parts of the library, both
of which express a package interdependency.

A selector engine that offers no deliberate syntax extensions is safer,
because it does not have as much deviation from the spec.

Any library that uses custom selectors, selectors that match attributes,
and anything that uses native-first dual approach cannot be easily
fixed. Continuing to use such library either changed or unchanged would
be unsafe.

Any library that uses a broken query selector at the core is just as
broken as its query engine. Fixing the bugs causes instability. Problems
are not limited to queries, however.

When changes to low-level abstractions propagate to higher level
abstractions the result is instability.

Each bug in Ext-JS's selector engine necessarily propagates to a higher
level. When the selector engine's behavior is changed, that change is
propagated to all of the higher level dependencies. Such behavioral
changes cause instability. The alternative to causing such changes is to
not fix the bugs.

Buyer Beware.
The alternative for the end user is to not use include such things on
the page. As I have always advised for the developer who is considering
using a js library: Carefully review the source code of any js library
before using it.

<https://groups.google.com/group/comp.lang.javascript/msg/c23d62071aad2626>

>>
>> For example, if the default value for visibility is used, the element's
>> visibility is calcualted as "inherit" (which is correct) and in that
>> case, the result won't include that element. Except where it does, and
>> that depends on the browser.

>
> No, "inherit" would be incorrect for getComputedStyle. For elements
> without a visibility rule, "visible" is the expected result. Now,
> IE's "cascaded styles" will indeed return "inherit" as IE doesn't
> compute styles at all, simply returning whatever is specified in
> applicable rules (or the default value, which is "inherit" in this
> case).
>


That's correct.

var a = Ext.query("{visibility=inherit}");

The result of that in Ext shows that it does not work consistently
either, and a.length will be 0, depending on the browser. This is due to
the fact that it relies on Ext.Dom.getStyle, which, like most everything
in Ext-JS, is very broken.

> Regardless, I'm sure that ExtJS fails to account for this (among many
> other things). Just like jQuery!
>
>>
>> But that is about Ext-JS (big version), not Sencha. In Sencha, all of
>> this stuff throws errors.

>
> Of course as it has no query engine; it simply hands off all queries
> to QSA.
>


If it had simply handed queries off to `querySelectorAll`, it would not
have created as many problems.

Extra effort was required to split on "," and create a loop, adding
duplicates to the returned result.

So while they do use querySelectorAll, they go to a lot of extra effort
to complicate it and create problems. Why they expended this extra
effort, I cannot say.

The code with comments being blatantly false could be attributed to haste.

>>
>> (I've got a some errands to do, so I'm going to post the rest of this
>> here wihout editing)
>>
>> | * E{display=none} css value "display" that equals "none"
>> | * E{display^=none} css value "display" that starts with "none"
>> | * E{display$=none} css value "display" that ends with "none"
>> | * E{display*=none} css value "display" that contains the substring
>> | "none"

>
> There's not a chance in hell they got any of those right cross-
> browser.
>


You reviewed Ext.Dom.getStyle and, as you pointed out,
`hasRightMarginBug` is completely missing for the script.

"hasRightMarginBug" in Ext.platform

false

It seems they forgot to include that property, though continue to
reference it. Since the resolution results in undefined and since
undefined evaluates to false, any code that uses that identifier in a
boolean context is completely useless and dead code.

And so all of the:

| if (Ext.platform.hasRightMarginBug && marginRightRe.test(prop) && out
| != '0px') {
| display = this.getStyle('display');
| el.style.display = 'inline-block';
| result = view.getComputedStyle(el, '');
| el.style.display = display;
| }

is dead code and will never be evaluated.

>> | * E{display!=none} css value "display" that does not equal "none"
>> |
>> |
>> |
>> | This class is a singleton and cannot be created directly.

>
> It's neither a class nor a singleton.
>
>> | Public Properties

>
> All JS properties are public.
>
>> | Property Defined By
>> | matchers : Object
>> | Collection of matching regular expressions and code snippets. Each
>> | capture group within () will be replace the {} in ...
>> | Collection of matching regular expressions and code snippets. Each
>> | capture group within () will be replace the {} in the select statement
>> | as specified by their index.
>> | DomQuery
>> | pseudos : Object
>> | Object hash of "pseudo class" filter functions which are used when
>> | filtering selections. Each function is passed two ...

>
> Oh God. As usual, these types of projects get ten steps ahead of
> themselves. I mean, it's 2010 and their basic queries are still
> broken. What's the point of piling all of this other nonsense on top?
>
> [snip more delusions]
>


Although library author is free to make any design decision he chooses,
if the design decisions violate the CSS specifications and drafts (and
these do), then the code cannot honestly be said to be CSS3 compliant.

Ext-JS claims "DomQuery supports most of the CSS3 selectors spec, along
with some custom selectors and basic XPath". Whether Ext supports more
than half of CSS3 selectors depends on the browser and the claim of
"basic XPath" support is false (possibly outdated documentation from
previous jQuery copying).

>> |
>> | DomQuery
>> | selectNumber( String selector, [Node root], Number defaultValue ) :
>> | Number
>> | Selects the value of a node, parsing integers and floats. Returns the
>> | defaultValue, or 0 if none is specified.
>> | Selects the value of a node, parsing integers and floats. Returns the
>> | defaultValue, or 0 if none is specified.
>> | Parameters:
>> |
>> | * selector : String
>> | The selector/xpath query
>> | * root : Node
>> | (optional) The start of the query (defaults to document).
>> | * defaultValue : Number
>> |
>> | Returns:
>> |
>> | * Number
>> |
>> | DomQuery
>> | selectValue( String selector, [Node root], String defaultValue ) :
>> | String
>> | Selects the value of a node, optionally replacing null with the
>> | defaultValue.
>> | Selects the value of a node, optionally replacing null with the
>> | defaultValue.
>> | Parameters:
>> |
>> | * selector : String
>> | The selector/xpath query
>> | * root : Node
>> | (optional) The start of the query (defaults to document).
>> | * defaultValue : String
>> |
>> | Returns: String
>> |
>> | DomQuery
>>
>> The `selectValue` and `selectNumber` methods are missing altogether from
>> Sencha.

>
> There's a lot of that going on. They were clearly pressed for time.
>


Seems so. Yet another framework rushed to market, marketed heavily,
using fancy demos with nice images.

The difference between marketing and engineering seems to not very well
perceived.

Looking at demos is much more accessible than being able to make
assessments of front end code quality.

The number of individuals who look at the demos is going to be larger
than the number of individuals who review the code. This is not surprising.

What is surprising is that prior to the recent angel investment into
Sencha, they did not a few qualified individuals to do code review on
it. This would not have been much investment and could have helped avoid
such an amazing waste of money[1].

From the perspective of the investor who does not have any idea of the
code quality, he could employ two highly qualified individuals for a
maximum of one week each to review and assess the code at a cost under
10,000 USD. In reality, it is not hard to look at the code and find a
mistake at line 1:

window.undefined = window.undefined;

- and continue to find a very high defect rate and significantly bad
defects that we have covered and other glaring errors and design
mistakes that were covered by RobG[2].

Having volunteered so much free time over the years to spread knowledge
of web development, it seems that too few care about the code.

The financial losses from projects debilitated by bad code is real.

Bad code costs money.

Bad code hides bugs that might not surface immediately.

Tangled messy code can't be changed easily. The time involved to add a
new feature can be double, and then coming back to regression testing,
bugfixes for all of the change propagation.

This can lead to losing customers from bugs and even project failure
(and I have swam from such sunken ships, having failed to inspire the
captain into smart choices). It is not easy to measure how much money
was wasted by bad code. There is never a "good code" control group and
problems and debt compound.

Ext-JS is very buggy. It is awful code.

Any javascript developer who Ext-JS either has not read the source code
enough, is not capable of understanding the problems, or has read and
understood the problems but has not appreciated the consequences deeply.
The choice to use Ext-JS is a substantially irresponsible and uninformed
decision that puts quality and long-term success of his project at risk.

[1] <http://techcrunch.com/2010/06/23/sencha-html5-funding-sequoia/>
[2] "jquery vs dojo vs yui etc"
<http://groups.google.com/group/comp.lang.javascript/msg/d49c2a6b9a01c55c>
--
Garret
 
Reply With Quote
 
Ry Nohryb
Guest
Posts: n/a
 
      07-19-2010
On Jul 19, 9:04*am, Garrett Smith <(E-Mail Removed)> wrote:
>
> Did you need more explanation, after all that I have explained to you
> already?


The answer, my friend, is blowin' in the wind.
--
Jorge.
 
Reply With Quote
 
David Mark
Guest
Posts: n/a
 
      07-19-2010
On Jul 19, 3:14*am, David Mark <(E-Mail Removed)> wrote:
> On Jul 19, 3:12*am, Ry Nohryb <(E-Mail Removed)> wrote:
>
> > On Jul 19, 8:25*am, David Mark <(E-Mail Removed)> wrote:

>
> > > (...) The
> > > question is why you would need to do that with the styling equivalent
> > > of a no-op. *The answer is that you wouldn't unless you were stuck and
> > > resorting to programming by mystical incantation.

>
> > I always read before posting: it was a reply to Garrett's assertion
> > "We know that there is no way to force a repaint", which is -plainly-
> > false.

>
> Which was pointless.
>
> > See:

>
> > "Faster HTML and CSS: Layout Engine Internals for Web Developers",
> > David Baron.http://www.youtube.com/v/a2_6bGNZ7bA

>
> As is that. *You are your videos. *


Sorry for the confusion, you *and* your videos.
 
Reply With Quote
 
David Mark
Guest
Posts: n/a
 
      07-19-2010
On Jul 19, 3:29*am, Ry Nohryb <(E-Mail Removed)> wrote:
> On Jul 19, 9:04*am, Garrett Smith <(E-Mail Removed)> wrote:
>
> > On 2010-07-18 10:51 PM, Ry Nohryb wrote:
> > (...)

>
> > > For example, this (google groups) page can be forced to repaint with:

>
> > No, it cannot. About the best you can do is hope that the browser will
> > repaint.

>
> > So you've made observations of what happened in the browser and
> > concluded that those observations are premises for causality, huh?
> > (...)

>
> What I said is not based on any "mystical incantation" but on what the
> author of Mozilla's rendering engine explains in this video:
>
> "Faster HTML and CSS: Layout Engine Internals for Web Developers",
> David Baron.http://www.youtube.com/v/a2_6bGNZ7bA
>
> Obviously you too (I told Mark already) ought to see it in order to
> learn the fundamentals of the inner workings of rendering engines, and
> once you begin to see through the black box, you (and Mark) will be
> able to stop thinking about it any more in terms of mystical
> incantations.
>
> HTH,


Nope. I don't need to watch the video. You need to learn to read.
Thanks!
 
Reply With Quote
 
David Mark
Guest
Posts: n/a
 
      07-19-2010
On Jul 19, 3:37*am, Garrett Smith <(E-Mail Removed)> wrote:
> On 2010-07-18 08:26 PM, David Mark wrote:> On Jul 18, 10:15 pm, Garrett Smith<(E-Mail Removed)> *wrote:
> >> On 2010-07-18 02:42 PM, David Mark wrote:

>
> >>> On Jul 18, 5:18 pm, Garrett Smith<(E-Mail Removed)> * *wrote:

>
> >>> [...]

>
> >>>> ext-touch-debug.js..............458k

>
> [...]
>
>
>
> > And speaking of the other efforts; you mentioned that ExtJS was the
> > worst of the worst with respect to queries. *But I don't know how you
> > could get much more inept than Dojo's, which relies on their "attr"

>
> I did not review Dojo's in depth, but the overall design approach makes
> more sense. From memory, dojo uses its own engine first, and if that
> works, then it tries to use NodeSelector the next time.


Its own engine is the problem. Certainly it isn't aware of whether it
works or not (unless "works" means avoiding exceptions).

>
> > function, which has always been complete gibberish. *It's only a
> > couple of dozen lines of code and I once tried to explain its illogic
> > to them, but they just kept chirping: "show me where it fails". *I was
> > reluctant to do that as it would predictably lead to patches without
> > understanding (or fixing) the general problem. *But even after
> > producing a couple of failure cases, they were still hesitant to
> > change anything, lest they break compatibility. *Of course,
> > "compatibility" that produces one result in IE8 standards mode and
> > another in its compatibility view is not something to preserve.
> > Furthermore, their "vaunted" widgets and parser rely heavily on this
> > function, so the mistakes manifest themselves in virtually everything
> > they do. *Their forums, mailing lists, etc. are full of confused
> > questions (and even more confused answers) related to these issues.

>
> The predicament is that fixing the broken abstraction affects the
> dependencies.


The problem is that their abstraction is inconsistent cross-browser,
so is nothing to cling to. The other problem is that none of them can
define what it is supposed to be doing.

>
> Changes to low-level abstractions propagate to higher level abstractions
> and the result is instability.


But when you are already getting two different results for the same
browser (e.g. IE8 depending on rendering mode), it indicates you
better change something. I went through all of the dependencies and
certainly none are written to expect two different results in IE8.

>
> The alternative to causing such instability -- and which Dojo has seemed
> to favor here -- is to not fix the bugs.


There's not a chance in hell that fixing the bugs I am referring to
would cause instability. In fact, I rewrote virtually every module
and add-on and demonstrated that all of the unit tests still passed.
Hard to argue with that. Yet somehow they managed.

>
> Of course the problem with that is that everything is broken and as you
> pointed out, broken differently across different browsers, rendering
> mode, etc.


Right.

>
> An low level abstraction that is fundamentally broken is a serious problem.


Yes, and for them it remains a problem to this day. That indicates
that nobody on that project has a clue what they are doing. They
can't even fix simple problems when handed the solutions on a silver
platter (see also jQuery).

>
> >> Regardless, NFD is a design mistake, no matter how
> >> popular it becomes and no matter many libraries copy it.

>
> > Of course it is. *A child could see that.

>
> >> The reason I
> >> mention this is it seems that Ext-JS has been following what jQuery
> >> does, copying the mistakes and adding its own mistakes to that.

>
> > It appears that way. *And they have the gall to charge people to use
> > recycled garbage.

>
> Well, if it is coming at premium cost, there will be those who think
> that it must be better.


Yes, snob appeal. But I think it is the graphics that are the biggest
draw. Of course, choosing a framework based on pretty widgets is like
choosing a car based on its radio.

> [...]
>
>
>
> >> | Provides high performance selector/xpath processing by compiling
> >> | queries into reusable functions. New pseudo classes and matchers can
> >> | be plugged. It works on HTML and XML documents (if a content node is
> >> | passed in).

>
> > That sounds like an optimistic appraisal of ExtJS, but Sencha Touch
> > does nothing of the sort. *It "compiles" nothing and certainly won't
> > work with XML documents.

>
> Ext-JS -- not Sencha -- dynamically create functions that they reuse.


I know.

> This is what they mean by "compiled". that doesn't apply to Sencha, but
> just an FYI about what they mean by "compile".


I've seen it elsewhere as well.

>
> [...]
>
>
>
> > That's not right. *For one, a checked attribute cannot be
> > "true" (except in an invalid document) and the :checked pseudo queries
> > the *property* so as to take user input into account. *Fortunately, I
> > think that's what they all do anyway; but unfortunately, they do the
> > same thing when querying the CHECKED attribute. *In my experience,
> > most of the participants in these projects don't know the difference.

>
> Not all, and there are some that check attributes. NWMatcher is
> cognizant of that, at least.


Yes, that thing works better than most of the "majors". Certainly
mine does too. Perhaps Dojo's will some day too as one of their
owners informed me long after his contributors had refused to
implement my recommendations that they were sniffing around my
attributes primer (a la John Resig). I had to remind him that it was
copyrighted. I'll be keeping my eye on them too.

>
> [...]
>
>
>
> >> | * E:not(S) an E element that does not match simple selector S
> >> | * E:has(S) an E element that has a descendent that matches simple
> >> | selector S
> >> | * E:next(S) an E element whose next sibling matches simple selector S
> >> | * Erev(S) an E element whose previous sibling matches simple
> >> | selector S
> >> | * E:any(S1|S2|S2) an E element which matches any of the simple
> >> | selectors
> >> | S1, S2 or S3//\\
> >> |
> >> | CSS Value Selectors:
> >> |

>
> >> These will all throw errors in Sencha and they do not work in Ext,
> >> either, as you've reviewed the section of code the reads styles, and
> >> that returns different results, when trying to read:

>
> >> {visibility=visible}

>
> >> - the result returned depends on the browser and how styles are calculated.

>
> > Yes, using these things to query by style values is even less
> > predictable than querying by attribute values.

>
> It is.
>
> The selector engine can be accessed from both
> Ext.Element.selectorFunction and Ext.query. These are core abstractions
> in the library and are accessed from two core parts of the library, both
> of which express a package interdependency.
>
> A selector engine that offers no deliberate syntax extensions is safer,
> because it does not have as much deviation from the spec.
>
> Any library that uses custom selectors, selectors that match attributes,
> and anything that uses native-first dual approach cannot be easily
> fixed. Continuing to use such library either changed or unchanged would
> be unsafe.


Where does this "native-first dual approach" term come from? I know
what you mean, but I've never heard it called that.

>
> Any library that uses a broken query selector at the core is just as
> broken as its query engine.


Of course. And Dojo uses theirs incessantly. That's why virtually
every "module" in their core requires dojo.query. How ominous is
that?

> Fixing the bugs causes instability. Problems
> are not limited to queries, however.


The fixes I recommended would not have destabilized anything. They
would have simply fixed the inconsistencies, which were not results
that were expected by the rest of the "modules".

>
> When changes to low-level abstractions propagate to higher level
> abstractions the result is instability.


Not in the case I'm speaking of. The result would have been exactly
the opposite (as was demonstrated in my branch of the code).

>
> Each bug in Ext-JS's selector engine necessarily propagates to a higher
> level. When the selector engine's behavior is changed, that change is
> propagated to all of the higher level dependencies. Such behavioral
> changes cause instability. The alternative to causing such changes is to
> not fix the bugs.


I haven't bothered tracking down all of their problems as nobody has
offered me any money to do so.

>
> Buyer Beware.
> The alternative for the end user is to not use include such things on
> the page. As I have always advised for the developer who is considering
> using a js library: Carefully review the source code of any js library
> before using it.


And in the case of a GP library, consider why in the hell you would
want such a thing in the first place.

>
> <https://groups.google.com/group/comp.lang.javascript/msg/c23d62071aad...>
>
>
>
> >> For example, if the default value for visibility is used, the element's
> >> visibility is calcualted as "inherit" (which is correct) and in that
> >> case, the result won't include that element. Except where it does, and
> >> that depends on the browser.

>
> > No, "inherit" would be incorrect for getComputedStyle. *For elements
> > without a visibility rule, "visible" is the expected result. *Now,
> > IE's "cascaded styles" will indeed return "inherit" as IE doesn't
> > compute styles at all, simply returning whatever is specified in
> > applicable rules (or the default value, which is "inherit" in this
> > case).

>
> That's correct.
>
> var a = Ext.query("{visibility=inherit}");
>
> The result of that in Ext shows that it does not work consistently
> either, and a.length will be 0, depending on the browser. This is due to
> the fact that it relies on Ext.Dom.getStyle, which, like most everything
> in Ext-JS, is very broken.


But they do have some nice graphics.

>
> > Regardless, I'm sure that ExtJS fails to account for this (among many
> > other things). *Just like jQuery! *

>
> >> But that is about Ext-JS (big version), not Sencha. In Sencha, all of
> >> this stuff throws errors.

>
> > Of course as it has no query engine; it simply hands off all queries
> > to QSA.

>
> If it had simply handed queries off to `querySelectorAll`, it would not
> have created as many problems.


Yes, I forgot about their inexplicable preprocessing.

>
> Extra effort was required to split on "," and create a loop, adding
> duplicates to the returned result.


Clearly tacked on my author(s) who had no idea what they were doing (a
common theme with these things). Who knows what they were thinking as
there are no explanatory comments.

>
> So while they do use querySelectorAll, they go to a lot of extra effort
> to complicate it and create problems. Why they expended this extra
> effort, I cannot say.


Only they can and they haven't. I suspect they will quietly remove
that code some time in the near future.

>
> The code with comments being blatantly false could be attributed to haste..


For such a Frankenstein-like effort it probably is. Much of it sounds
like it is describing ExtJS.

>
>
>
> >> (I've got a some errands to do, so I'm going to post the rest of this
> >> here wihout editing)

>
> >> | * E{display=none} css value "display" that equals "none"
> >> | * E{display^=none} css value "display" that starts with "none"
> >> | * E{display$=none} css value "display" that ends with "none"
> >> | * E{display*=none} css value "display" that contains the substring
> >> | "none"

>
> > There's not a chance in hell they got any of those right cross-
> > browser.

>
> You reviewed Ext.Dom.getStyle and, as you pointed out,
> `hasRightMarginBug` is completely missing for the script.


Haste makes waste.

>
> "hasRightMarginBug" in Ext.platform
>
> false
>
> It seems they forgot to include that property, though continue to
> reference it. Since the resolution results in undefined and since
> undefined evaluates to false, any code that uses that identifier in a
> boolean context is completely useless and dead code.


In a way, that describes the entire script. I can't think of one
thing they did right. And there's so much blatantly wrong that it
might as well be rewritten from scratch.

>
> And so all of the:
>
> | if (Ext.platform.hasRightMarginBug && marginRightRe.test(prop) && out
> | != '0px') {
> | * * display = this.getStyle('display');
> | * * el.style.display = 'inline-block';
> | * * result = view.getComputedStyle(el, '');
> | * * el.style.display = display;
> | }
>
> is dead code and will never be evaluated.


Yes, dead weight.

>
> >> | * E{display!=none} css value "display" that does not equal "none"
> >> |
> >> |
> >> |
> >> | This class is a singleton and cannot be created directly.

>
> > It's neither a class nor a singleton.

>
> >> | Public Properties

>
> > All JS properties are public.

>
> >> | Property Defined By
> >> | matchers : Object
> >> | Collection of matching regular expressions and code snippets. Each
> >> | capture group within () will be replace the {} in ...
> >> | Collection of matching regular expressions and code snippets. Each
> >> | capture group within () will be replace the {} in the select statement
> >> | as specified by their index.
> >> | DomQuery
> >> | pseudos : Object
> >> | Object hash of "pseudo class" filter functions which are used when
> >> | filtering selections. Each function is passed two ...

>
> > Oh God. *As usual, these types of projects get ten steps ahead of
> > themselves. *I mean, it's 2010 and their basic queries are still
> > broken. *What's the point of piling all of this other nonsense on top?

>
> > [snip more delusions]

>
> Although library author is free to make any design decision he chooses,
> if the design decisions violate the CSS specifications and drafts (and
> these do), then the code cannot honestly be said to be CSS3 compliant.


There's very little CSS3 in Sencha, despite the disingenuous ad
campaign. Not much HTML5 either. Who knew marketers lied?

>
> Ext-JS claims "DomQuery supports most of the CSS3 selectors spec, along
> with some custom selectors and basic XPath". Whether Ext supports more
> than half of CSS3 selectors depends on the browser and the claim of
> "basic XPath" support is false (possibly outdated documentation from
> previous jQuery copying).


Probably.

>
> >> |
> >> | DomQuery
> >> | selectNumber( String selector, [Node root], Number defaultValue ) :
> >> | Number
> >> | Selects the value of a node, parsing integers and floats. Returns the
> >> | defaultValue, or 0 if none is specified.
> >> | Selects the value of a node, parsing integers and floats. Returns the
> >> | defaultValue, or 0 if none is specified.
> >> | Parameters:
> >> |
> >> | * selector : String
> >> | The selector/xpath query
> >> | * root : Node
> >> | (optional) The start of the query (defaults to document).
> >> | * defaultValue : Number
> >> |
> >> | Returns:
> >> |
> >> | * Number
> >> |
> >> | DomQuery
> >> | selectValue( String selector, [Node root], String defaultValue ) :
> >> | String
> >> | Selects the value of a node, optionally replacing null with the
> >> | defaultValue.
> >> | Selects the value of a node, optionally replacing null with the
> >> | defaultValue.
> >> | Parameters:
> >> |
> >> | * selector : String
> >> | The selector/xpath query
> >> | * root : Node
> >> | (optional) The start of the query (defaults to document).
> >> | * defaultValue : String
> >> |
> >> | Returns: *String
> >> |
> >> | DomQuery

>
> >> The `selectValue` and `selectNumber` methods are missing altogether from
> >> Sencha.

>
> > There's a lot of that going on. *They were clearly pressed for time.

>
> Seems so. Yet another framework rushed to market, marketed heavily,
> using fancy demos with nice images.


I can't think of one of those that has really made an impact on the
Web though. Hopefully this will be just one more whale on the beach.

>
> The difference between marketing and engineering seems to not very well
> perceived.


If at all. The first question on the mind of Web developers seems to
be about popularity. They seem to think that popularity implies
continuous improvement and easy support, despite overwhelming evidence
to the contrary (see jQuery).

>
> Looking at demos is much more accessible than being able to make
> assessments of front end code quality.


Yes, by a long shot. And once they fall in love with the demos, most
developers don't want to hear about the bad code, compatibility
issues, lack of competent support, etc. They want something they can
copy and paste and ship today (and never mind the ramifications for
their clients).

>
> The number of individuals who look at the demos is going to be larger
> than the number of individuals who review the code. This is not surprising.


Yes. What is surprising is that anyone would listen to "experts" who
advocate scripts based on pretty graphics and snazzy demos.

>
> What is surprising is that prior to the recent angel investment into
> Sencha, they did not a few qualified individuals to do code review on
> it.


The Ext people think they are qualified, though that misconception has
likely been shaken at this point (unless they are locked up in sound-
proof booths with blinders on).

> This would not have been much investment and could have helped avoid
> such an amazing waste of money[1].


Yes. It's a shame to see people throwing good money after bad.

>
> *From the perspective of the investor who does not have any idea of the
> code quality, he could employ two highly qualified individuals for a
> maximum of one week each to review and assess the code at a cost under
> 10,000 USD.


Hell, I did it for free. Well, not really. I just touched on the
highlights here. I charged for the full analysis. Some people
realize that spending a little money to avoid wasting a lot makes good
business sense. It didn't take me a week and I didn't charge anywhere
near $5,000. But I could definitely write a similar (and much better)
framework in that neighborhood (and did so for one client about a year
back).

> In reality, it is not hard to look at the code and find a
> mistake at line 1:
>
> * *window.undefined = window.undefined;


Yeah, that was a bad omen.

>
> - and continue to find a very high defect rate and significantly bad
> defects that we have covered and other glaring errors and design
> mistakes that were covered by RobG[2].


No, not hard at all. So you have to wonder about the *best*
developers they have on the project and what the hell they are doing
all day.

>
> Having volunteered so much free time over the years to spread knowledge
> of web development, it seems that too few care about the code.


Oh, I bet somebody from Sencha is taking notes. The question is
whether they have anyone on the payroll who can interpret them in a
timely fashion.

>
> The financial losses from projects debilitated by bad code is real.
>
> Bad code costs money.
>
> Bad code hides bugs that might not surface immediately.
>
> Tangled messy code can't be changed easily. The time involved to add a
> new feature can be double, and then coming back to regression testing,
> bugfixes for all of the change propagation.


Sure. Ask anyone unfortunate enough to be saddled with Dojo.

>
> This can lead to losing customers from bugs and even project failure
> (and I have swam from such sunken ships, having failed to inspire the
> captain into smart choices).
> It is not easy to measure how much money
> was wasted by bad code. There is never a "good code" control group and
> problems and debt compound.
>
> Ext-JS is very buggy. It is awful code.


As improbably as it may seem. that's an understatement.

>
> Any javascript developer who Ext-JS either has not read the source code
> enough, is not capable of understanding the problems, or has read and
> understood the problems but has not appreciated the consequences deeply.


Happens all the time.

> The choice to use Ext-JS is a substantially irresponsible and uninformed
> decision that puts quality and long-term success of his project at risk.


And the choice to use Sencha Touch is exponentially worse, which could
only be described as insane.
 
Reply With Quote
 
Garrett Smith
Guest
Posts: n/a
 
      07-19-2010
On 2010-07-19 12:29 AM, Ry Nohryb wrote:
> On Jul 19, 9:04 am, Garrett Smith<(E-Mail Removed)> wrote:
>> On 2010-07-18 10:51 PM, Ry Nohryb wrote:
>> (...)
>>
>>> For example, this (google groups) page can be forced to repaint with:

>>
>> No, it cannot. About the best you can do is hope that the browser will
>> repaint.
>>
>> So you've made observations of what happened in the browser and
>> concluded that those observations are premises for causality, huh?
>> (...)

>
> What I said is not based on any "mystical incantation" but on what the
> author of Mozilla's rendering engine explains in this video:
>
> "Faster HTML and CSS: Layout Engine Internals for Web Developers",
> David Baron.
> http://www.youtube.com/v/a2_6bGNZ7bA
>
> Obviously you too (I told Mark already) ought to see it in order to
> learn the fundamentals of the inner workings of rendering engines, and
> once you begin to see through the black box, you (and Mark) will be
> able to stop thinking about it any more in terms of mystical
> incantations.
>

That's not a standard and not any browser documentation. It does not
explain how to force a repaint. I find it painful to watch that man
speak. Is there particular citation that you would like to reference?
You can enter the text.
--
Garrett
 
Reply With Quote
 
David Mark
Guest
Posts: n/a
 
      07-20-2010
On Jul 19, 9:52*pm, kangax <(E-Mail Removed)> wrote:
> On 7/19/10 3:32 PM, Garrett Smith wrote:
>
>
>
>
>
> > On 2010-07-19 12:29 AM, Ry Nohryb wrote:
> >> On Jul 19, 9:04 am, Garrett Smith<(E-Mail Removed)> wrote:
> >>> On 2010-07-18 10:51 PM, Ry Nohryb wrote:
> >>> (...)

>
> >>>> For example, this (google groups) page can be forced to repaint with:

>
> >>> No, it cannot. About the best you can do is hope that the browser will
> >>> repaint.

>
> >>> So you've made observations of what happened in the browser and
> >>> concluded that those observations are premises for causality, huh?
> >>> (...)

>
> >> What I said is not based on any "mystical incantation" but on what the
> >> author of Mozilla's rendering engine explains in this video:

>
> >> "Faster HTML and CSS: Layout Engine Internals for Web Developers",
> >> David Baron.
> >>http://www.youtube.com/v/a2_6bGNZ7bA

>
> >> Obviously you too (I told Mark already) ought to see it in order to
> >> learn the fundamentals of the inner workings of rendering engines, and
> >> once you begin to see through the black box, you (and Mark) will be
> >> able to stop thinking about it any more in terms of mystical
> >> incantations.

>
> > That's not a standard and not any browser documentation. It does not
> > explain how to force a repaint. I find it painful to watch that man
> > speak. Is there particular citation that you would like to reference?
> > You can enter the text.

>
> What he talks about is also partially present in these documents (by
> same author):
>
> <https://developer.mozilla.org/en/Notes_on_HTML_Reflow>
> <https://developer.mozilla.org/en/Introduction_to_Layout_in_Mozilla>
>
> I would also like to (once again) quote Dave Hyat of WebKit fame
> (<www.stubbornella.org/content/2009/03/27/reflows-repaints-css-performa....>):
>
> <quote>
>
> [...]
>
> element.style.width = 50px;
> var v = element.offsetWidth;
> element.style.width = 55px;
> v = element.offsetWidth;
>
> You just caused two reflows to happen, since asking for offsetWidth
> forced the element to reflow in order to answer you question (because it
> had a pending change to style).


Of course, if the element is absolutely positioned, the browser won't
have to re-flow the entire document. That's something else to keep in
mind.

>
> This is the real performance bottleneck to be wary of. Browsers are
> smart about avoiding reflows when they can, but if you create code that
> forces a reflow in order to answer a question, then you can create
> severe performance bottlenecks.
>


Yes and unnecessary repaints are even worse. Not just for
performance, but they can wreak havoc on aesthetics as well.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Not just different browsers that sites need testing in? Tim W HTML 11 08-08-2012 09:29 PM
Browsers, browsers! Quo vadis? El Kabong HTML 23 05-13-2007 08:55 PM
Is there something RoboForm that works for all programs, not just browsers? Jimmy Dean Computer Support 6 02-28-2006 04:20 AM
Two Browsers work! Two browsers won't load. Internet game service won't load jimmie Computer Support 1 02-26-2006 08:36 AM
allow you to move just about any music to your iPud, MP3 player , or just burn it to disk sbcmynews Computer Support 4 05-01-2005 03:53 PM



Advertisments