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

[Garrett Smith]

On 2010-07-20 03:44 PM, David Mark wrote:
On 2010-07-20 12:24 PM, David Mark wrote:

On 2010-07-20 11:33 AM, David Mark 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<[email protected]>
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.

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.

Technical criticism littered with such mudslinging reduce the s/n ratio.
What's worse is that a non-technical observer might dismiss the
discussion as crazed zealotry.

I will publish an article on some of this stuff soon. It is the same
article I was going to publish three weeks ago. The article will contain
some of the things that I have posted here. Give me one more week.

 

[David Mark]

On 2010-07-20 04:24 PM, David Mark wrote:
On 2010-07-20 03:44 PM, David Mark wrote:
On 2010-07-20 12:24 PM, David Mark wrote:
On 2010-07-20 11:33 AM, David Mark 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<[email protected]>
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.

Technical criticism littered with such mudslinging reduce the s/n ratio.
What's worse is that a non-technical observer might dismiss the
discussion as crazed zealotry.

Good thing the lion's share of the useful information is in the first
message in the thread.

I will publish an article on some of this stuff soon. It is the same
article I was going to publish three weeks ago.

Yes, yes.

The article will contain
some of the things that I have posted here. Give me one more week.

Whatever.

 

[Garrett Smith]

On 21/07/2010 12:44 PM, Garrett Smith wrote:
On 2010-07-20 04:24 PM, David Mark wrote:
On 2010-07-20 03:44 PM, David Mark wrote:
On 2010-07-20 12:24 PM, David Mark wrote:

On 2010-07-20 11:33 AM, David Mark 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<[email protected]>
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.

 

[David Mark]

On 2010-07-20 03:44 PM, David Mark wrote:
On 2010-07-20 12:24 PM, David Mark wrote:
On 2010-07-20 11:33 AM, David Mark 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<[email protected]>
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.

 

[Garrett Smith]

<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.

[...]