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 19 Jul 2010 03:37 On 2010-07-18 08:26 PM, David Mark wrote: > On Jul 18, 10:15 pm, Garrett Smith<dhtmlkitc...(a)gmail.com> wrote: >> On 2010-07-18 02:42 PM, David Mark wrote: >> >>> On Jul 18, 5:18 pm, Garrett Smith<dhtmlkitc...(a)gmail.com> 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 >> | * E:prev(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
From: Ry Nohryb on 19 Jul 2010 03:41 On Jul 19, 9:04 am, Garrett Smith <dhtmlkitc...(a)gmail.com> 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.
From: David Mark on 19 Jul 2010 03:42 On Jul 19, 3:14 am, David Mark <dmark.cins...(a)gmail.com> wrote: > On Jul 19, 3:12 am, Ry Nohryb <jo...(a)jorgechamorro.com> wrote: > > > On Jul 19, 8:25 am, David Mark <dmark.cins...(a)gmail.com> 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.
From: David Mark on 19 Jul 2010 03:43 On Jul 19, 3:29 am, Ry Nohryb <jo...(a)jorgechamorro.com> wrote: > On Jul 19, 9:04 am, Garrett Smith <dhtmlkitc...(a)gmail.com> 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!
From: David Mark on 19 Jul 2010 04:28
On Jul 19, 3:37 am, Garrett Smith <dhtmlkitc...(a)gmail.com> wrote: > On 2010-07-18 08:26 PM, David Mark wrote:> On Jul 18, 10:15 pm, Garrett Smith<dhtmlkitc...(a)gmail.com> wrote: > >> On 2010-07-18 02:42 PM, David Mark wrote: > > >>> On Jul 18, 5:18 pm, Garrett Smith<dhtmlkitc...(a)gmail.com> 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 > >> | * E:prev(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. |