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 21 Jul 2010 18:27 On 2010-07-21 01:58 PM, David Mark wrote: > On Jul 21, 4:46 pm, Garrett Smith<dhtmlkitc...(a)gmail.com> wrote: >> On 2010-07-20 08:26 PM, Andrew Poulos wrote: >> >> >> >> >> >>> On 21/07/2010 12:44 PM, Garrett Smith wrote: >>>> On 2010-07-20 04:24 PM, David Mark wrote: >>>>> On Jul 20, 7:15 pm, Garrett Smith<dhtmlkitc...(a)gmail.com> wrote: >>>>>> On 2010-07-20 03:44 PM, David Mark wrote: >>>>>>> On Jul 20, 6:06 pm, Garrett Smith<dhtmlkitc...(a)gmail.com> wrote: >>>>>>>> On 2010-07-20 12:24 PM, David Mark wrote: >> >>>>>>>>> On Jul 20, 3:15 pm, Garrett Smith<dhtmlkitc...(a)gmail.com> wrote: >>>>>>>>>> On 2010-07-20 11:33 AM, David Mark wrote: >> >>>>>>>>>>> On Jul 20, 4:24 am, Garrett Smith<dhtmlkitc...(a)gmail.com> wrote: >>>>>>>>>>>> On 2010-07-19 11:57 PM, kangax wrote: >> >>>>>>>>>>>>> On 7/20/10 1:04 AM, Garrett Smith wrote: >>>>>>>>>>>>>> On 2010-07-19 06:52 PM, kangax 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<dhtmlkitc...(a)gmail.com> >>>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>>>> On 2010-07-18 10:51 PM, Ry Nohryb wrote: >>>>>>>>>>>>>>>>>> (...) >> >>>>>>>>>> [snip massive over quote] >> >>> Do you guys know how it reads when a js library that is being marketed >>> as something its not is rightly exposed as such and to then have a bunch >>> of js "experts" playing with and/or insulting each other? I'd say that >>> for the Sencha people it gives them sufficient grounds to not even >>> bother to refute any of the claims. >> >> No doubt. > > I doubt whether that follow. But you do have a habit of burying > useful threads in confused nonsense, which then has to be sorted out, > else newcomers won't understand the original points. > >> >> Name-calling and downtalking others hurts technical discussion and hurts >> the person doing those things probably much more than the intended >> recipient of such insults. > > Yeah, so stop doing it. And don't bother posting back with one of > your innocent routines. Your modus operandi is well-known at this > point. You post thinly disguised attempts at insults, get called on > them and then whine and point fingers like a child. > I'll agree to disagree on that. -- Garrett
From: David Mark on 21 Jul 2010 23:50 On Jul 20, 11:26 pm, Andrew Poulos <ap_p...(a)hotmail.com> wrote: > On 21/07/2010 12:44 PM, Garrett Smith wrote: > > > > > > > On 2010-07-20 04:24 PM, David Mark wrote: > >> On Jul 20, 7:15 pm, Garrett Smith<dhtmlkitc...(a)gmail.com> wrote: > >>> On 2010-07-20 03:44 PM, David Mark wrote: > >>>> On Jul 20, 6:06 pm, Garrett Smith<dhtmlkitc...(a)gmail.com> wrote: > >>>>> On 2010-07-20 12:24 PM, David Mark wrote: > > >>>>>> On Jul 20, 3:15 pm, Garrett Smith<dhtmlkitc...(a)gmail.com> wrote: > >>>>>>> On 2010-07-20 11:33 AM, David Mark wrote: > > >>>>>>>> On Jul 20, 4:24 am, Garrett Smith<dhtmlkitc...(a)gmail.com> wrote: > >>>>>>>>> On 2010-07-19 11:57 PM, kangax wrote: > > >>>>>>>>>> On 7/20/10 1:04 AM, Garrett Smith wrote: > >>>>>>>>>>> On 2010-07-19 06:52 PM, kangax 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<dhtmlkitc...(a)gmail.com> > >>>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>>> On 2010-07-18 10:51 PM, Ry Nohryb wrote: > >>>>>>>>>>>>>>> (...) > > >>>>>>> [snip massive over quote] > > Do you guys know how it reads when a js library that is being marketed > as something its not is rightly exposed as such and to then have a bunch > of js "experts" playing with and/or insulting each other? Yes, but luckily the important parts were posted before the thread degenerated into another reflow/repaint "argument". :) > I'd say that > for the Sencha people it gives them sufficient grounds to not even > bother to refute any of the claims. Fine by me. Ext must D-I-E. :) To that end, I've recently added (very basic) touch and geolocation add-ons to My Library. Wrapping up a storage bit as well (supporting Web and cookie transports and open to add more). I'll be adding progressive enhancement for HTML5 soon and have already leveraged CSS3 considerably (widget skins, transform add-on, etc.) What I haven't done (and won't do) is publish dubious hyperbole and graphics-laden demos to create a Wizard of Oz effect. I want prospective users to think for themselves and realize that graphics have nothing to do with JS/CSS (except as an optional embellishment). And having just finished a standards-based iPhone/iPad Web app (to be wrapped for the app store) that uses HTML/CSS with only a tiny bit of JS, I am again reminded of the futility of using something like Sencha Touch (or JQTouch, IUI, etc.) My app works in every browser I tried (all of the majors going back two or three versions), used no sniffing, no XHR, allowed the content to reside in the HTML (where it belongs) and looks just as dazzling as any native app. ISTM that with CSS media queries, I could make any Web app or site animate and contort itself to fit the smaller screens and iPhone look/ feel (in the same way that I use handheld style sheets to suit "normal" phones). Well, that's assuming they are lightweight enough and don't use table (or JS) based layouts. And now that I think about it, as far as bloat (e.g. tons of Flash, heavy images, etc.), I wonder if display:none prevents downloads in these devices. Probably not.
From: Garrett Smith on 22 Jul 2010 02:33
On 2010-07-16 10:16 AM, Richard Cornford wrote: > KCL wrote: >> On Jul 15, 10:38 pm, David Mark wrote: >>> Sencha Touch is a bizarre mish-mash of ExtJS and a jQuery >>> plug-in called JQTouch. It is advertised as the first >>> "HTML5 framework" based on "standards" like HTML5 and CSS3. > <snip> [...] >> Given the depth of your review, it would seem you have >> some time on your hands. > > It didn't look like it need much time, or to achieve any depth. Just The initial could have benefited from a little more effort and care to avoid wrapping. > copy the source text and work down it inserting comments on the things > that stand out. When the first line of code is a 'fix' for pre-ECMA 262 > 3rd edition browsers (a standard that came out in 1999 and where the > most recent browser that needed the 'fix' is IE 4, in a system that does > not support IE in any version) then you don't need depth to see fault. > Including Sencha on any page results in errors in IE due to addEventListener. So it is not like a graceful degradation strategy could even be employed. [...] > > Personally, I have been writing about and discussing strategies to > maximise the efficiency of code re-use in browser scripting, publishing > examples and testing my ideas in my work for more than half a decade. My > ideas in this regard do not lead to the large scale interdependent > general purpose browser scripting libraries (that is where my thinking > started nearly a decade ago, and is the thing I have been moving away > from ever since). Instead they were directed toward the creation of > browser scripts as a hierarchical structure of loosely coupled modules > specified as interfaces, where particular interfaces may have numerous > implementations, none of which attempt to be more general than a > particular context calls for, but each suited to a different context. > Thus I avoid the bloat and performance hit associated with attempts to > be truly general; implementations of interfaces do not even need to > consider issues that are not part of the context in which they are used, > and if the issue is in the context a different implementation of the > interface is used instead. Given this approach it is not too surprising > that I would be the person to introduce the "module pattern" back in > 2003, as it is the ideal packaging unit for many of those interface > implementations. > The performance hit is not just in download, but in keeping the functions in memory, and then the chance that it may not be cached, and on a mobile device, a possible extra cost of data plan, depending if the user's plan or connection (roaming). Performance is an issue, but I think it's not the only reason. An interface that has a lot of behavior, if something changes, then anything that depends on that must be retested. But what about cross-browser DOM abstraction code -- for things such as reading styles, traversal, events? What sort of advice you could offer for for organizing DOM abstraction code? Can you provide any advice for how I've organized APE JS Library? > This design strategy results in what is in effect a 'library' of > (easily, as in real life common contexts reoccur frequently) re-useable > code modules, but its concepts and architecture are quite difficult for > some to recognise as a 'library', it could not easily be packaged and > distributed, and indeed it is the intention of the design that the whole > never needs to be finished (in terms of creating an implementation of > every interface for every possible context, as some contexts are so > unlikely that I am unlikely to ever encounter them). The collected code > 'library' is also not a framework, but it can be used to build > frameworks where they are needed, and those frameworks gain the > robustness of being made from well tried modules plus the possibility of > being well suited to their specific tasks/context. > While I am aware of the benefits from interface-based design and of using the SOLID principles, I feel like I struggle with applying them. How do you define "framework" from a mechanical standpoint? I think of a framework as being some sort of container that holds the system together. [...] -- Garrett |