On 8/8/07, Pops <[EMAIL PROTECTED]> wrote:
> did was interrnal, no dependencies, plus, how can you compare pcode
> compile server side applets to a slower PHP interpreative environment
> which in reality did yield slower page rendering.
But PHP has always been relatively fast compared to, e.g. Java or even
client-side JavaScript. i started using PHP back in 1998 or 1999, and it was
blazing fast even back then.
Plus, and you might
> related to this with your SpiderApe work, wcBASIC was a multidevice
> system and included template technology that allowed console
> development as well - an important part of a BBS system.
Amen. My first online experiences were the many BBS's of Houston, Texas.
While i never operated one, i was personal friends with a couple of sysops.
> Very impressive work you are doing with SpiderApe. :-)
:D
> "You start with 10 lines of jQuery that would have been 20 lines of
> > tedious DOM JavaScript. By the time you are done it's down to two or
> > three lines and it couldn't get any shorter unless it read your mind."
> > - Dave Methvin
>
> The Layer over layer syndrom. :-) Honestly, it all depends, layers
> are suppose to simplify things, making it easier for programmers to
> cover ideas with less coding.
In general i'm a big fan of layers, as long as...
You still need a basic understanding of
> what it your are wrapping, and also understand when things do not
> react as you expecting.
Amen. My stomach still wrenches at some of the questions which appear on the
jQuery form which demonstrate a complete lack of knowledge, not only of
JavaScript, but also of the fact that JS is a single layer in a very complex
environment. The recurring question that gets me the most is, "how can I
rewrite this to guaranty that it is *completely* flicker-free." Aaarrrggg.
Every time i resist the urge to write back, "you can start by understanding
the environment you're writing code for."
However, once it becomes its own complex
> monster, it defeats the purpose. JQuery needs to pay attention to
> natural tendency to add more "stuff."
Amen, again. Qt is a great example of that. From what i've seen on the list,
the authors are pretty careful about that, though. IMO they could even
remove the Ajax features from the core and move it to a plugin, but my guess
is that 80%+ of the jQuery users do use the Ajax functions, so the core is
probably the best place for it. It would be an interesting exercise to strip
out the Ajax stuff and see how small jQ is without it.
> There is an old great poster with the rethorical question:
>
> What comes first? Marketing or Technology?
That is, unfortunately, unanswerable. Without us (technology) they would
have no products and without them we would never actually release anything.
It would stay in development forever.
> What I think needs to be pointed out, is not what JQUERY offers, but
> the language and syntax it offers. That is whats difference here, in
> my opinion.
That's a fair point, but the time-savings of jQ are not only based in the
(considerable) powers of the language. e.g.:
$('#MyElement').css('background-color','red') is much more elegant than the
equivalent code using the standard DOM API.
The syntax is awkward, of course, until one recognizes that '$' is a legal
variable/function name in JavaScript. (Even then, it takes getting used to.)
I'm speaking for myself, but its powerful syntax is both a blessing
> and a curse.
Amen. Writing structured code with it requires a lot of discipline. Same can
be said for PHP (or many/most other languages, for that matter).
It gives you the technology to work more productively
> with DOM/CSS, but it doesn't help with marketing because you still
> need a pretty good undersstanding of DOM and programming. So its not
> for everyone.
True enough. Most web programmers out there appear to work only with WYSIWYG
HTML editors, and have no clue what those tools really do. Take away their
Dreamweaver and they're reduced to quivering jelly.
In addition, I believe strongly in pareto's principle in my
> development. You are not going to get everyone usiing 100% of its
> feature set. In geneal, most people will begin using only 20% of it
> 80% of the time. Just look at JTIP - it is distributed with a RISC
> (Reduced Instruction Set Computer) version of JQUERY.JS.
i'll have to take a look at jtip. It sounds like it would be a good starting
point for the "remove the ajax" experiment.
> > Then we decide we need More. Now that jQuery has freed us from the
> > Tedium of the DOM, we want our web pages to do More. We want to add
> > animation effects, tabbed controls, and whatnot. Those are a lot of
> > work to implement, and we have not, so far, done so because it is so
> > tedious to do so.
>
> And for others, like myself, we have the vision that the more you
> think like this, someone is going to say "Why not just download a
> specialized frontend and qui?" Its the old Fat vs thin paradign. You
> want to do more with the Browser that in general is already done with
> specific client side coding.
For many years i've been shunning browser-side development. This was
primarily because i grew so frustrated with Java Applet development back in
the late 90's because the cross-browser support was so poor. i was spending
no less than 1/3rd of my time debugging cross-browser (or, more
specifically, Netscape-specific) problems. When i first started with
JavaScript (1999 or 2000) i came across the same problem - fighting with
different browsers, or different versions of MSIE. So i was very
ant-Web 2.0for a long time.
After seeing (and using) applications such as Google Mail, i'm convinced
that there is indeed a place/market/use for browser-based applications.
While, as a general rule, i use normal client-side applications, i have in
fact become spoiled by Google Mail, in that i don't need to set up my mail
accounts on each client PC when i want to check my mail.
Obviously, not all applications are good candidates for web-based apps, but
some (email, calendar/appointments, newsgroup readers (e.g. Google Groups),
and even RSS feed readers) are good candidates.
With have 5-6 different ways or clients that users can use to access
> our application server, a traditional GUI frontend, a Browser HTML
> interface, a JAVA Interface, Dialup ANSI/VT100, Telnet, and with our
> RPC API/SDK.
i wasn't aware that any BBSes were still running. i telnetted in to one
about 7 or 8 years ago, but haven't heard of any since then.
We are constantly challenged one what to give rid of,
> but the bottom line they are all still used. We might throw out for
> debate the idea of getting rid of the GUI frontend and go with the WEB
> 2.0 stuff, including FLEX and/or JAVA. But we are constantly reminded
> that people still want their special GUI applicaiton and don't want to
> use a BROWSER.
A major down-side of browser-side apps is that any given release of a
browser can break them. A major down-side of fat client apps is that any
given release of the underlying client libraries (e.g. UI toolkit) can break
them. So the decision is a calculated risk with no single good answer. That
said, browsers have shown to be a highly volatile environment the past 10+
years, but they have reached a point where stability and maturity are
important to their continued existence. People just don't tolerate
second-rate browsers any more because first-rate ones are available for
free. (*cough*Firefox*cough*)
We are still doing the WEB 2.0, we have too, that
> might explain my presence here, but I as continue to move in this
> direction, adding "dynamic Interactive I/O" with the browser, I can't
> help but think at some people, this basically becomes a special GUI
> download.
i agree completely.
And I don't think I am far off, just look at Adobe's Apollo and Flex -
> they think this is the future. Microsoft thinks the same thing -
> having special downloads to provide full broardband richness.
i'm still not to the point where i agree that a web page has to be 200k+,
and still concentrate on smaller download size. This preference comes from
having run on a modem for so many years (i was on 56k until just 2 or 3
years ago). While i think Flash/Flex are interesting technologies, i'm still
too backwards to move towards that trend yet. Hell, i still use a text-based
browser sometimes (like 'lynx'), and flash can't work in that environment.
Keep in mind I don't disagree with you. I think you will have both.
> The question I ask is how much should JQUERY do? is there a certain
> threshold where it might be more feasible to burn it into a single GUI
> download? I am not sure if I want it to do everything for me that you
> become so dependent on it that it alters your design framework for
> everything else.
One of the beauties of jQ is that it demonstrates that we can have multiple
UI "libraries" built on top of it. For example, there are no less than 3
different tabbed widget implementations, and at least 3 or 4 different
"accordion" widgets. Even the selectors support is extendable via 3rd-party
addons, as demonstrated by the "more selectors" plugin.
> Slick framework. The word "framework" sounds suspiciously like
> > Something from the Marketing Department, but don't let that deter you
> > - simply interpret it as "a collection of pre-defined functionality
> > off of which to build more functionality." (But framework" is a lot
> > easier to say.)
>
> It depends on who you are targeting and what other framework it is
> competing with. :-) You are right, in the one hand, it can scare
> people off.
>
> Personally, and I may be wrong, and I just a few days into it, to help
> push it more, I think it should focus "selling" one what it does best
> - not take away from learning DOM/CSS, but show how how can use JQUERY
> to work with DOM/CSS.
Curiously, though, once you get used to jQ, you find that you never have to
touch the low-level DOM functions. That said, there is still very much
dependency on CSS knowledge - to make best use of any dynamic pages you must
eventually get around to learning CSS to some degree or another. And while
you must understand what a DOM is, in the abstract, you don't need to know
much about the specifics when using jQuery, and you certainly (and
suprisingly) don't need to use the standardized DOM API. However, knowing
the standard API helps one understand what jQuery is doing, which is always
good.
In short, I think, lots and lots of side by side
> example. The idea, show the DOM/CSS way and the JQUERY way. Also for
> me, the language syntax is completely new to me.
Amen on both points. It takes some time for a curious newbie to set up a few
working examples, and this is a definite barrier to entry.
Again, just a few
> days into it, it may want to devote some doc pages to this syntax.
> I am completely amaze that its every possible! I had to study the
> JQUERY.JS (actually JTIP.JS) code to learn how these "function()" as
> parameters work - very complex stuff IMO for most people.
Unfortunately, JavaScript has been an underdog for a long time, and part of
the reason is because people don't generally know about its support for
anonymous functions and closures, both of which are powerful features. i
only learned about its support for closures when i started work on
SpiderApe. That completely changed the way i work with JS.
> > Amen, brothers and sisters.
>
> So are we back to the old APL saying:
Definitely. Every Great New Approach has its fanatics. Hell, even Apple has
more than its fair share of fanatics (though i'm quite certain that i'll
never understand why).
If the JQUERY programmer can not program the WORLD in one line of
> code, he
> won't prrogram at all? :
i think 3 lines of code is the accepted convention ;).
Maybe the poor bastards are using something else that is more code
> documentation friendly? and are saying the JQUERY people, like the old
> APL programmer, are sadistic? <g>
>
i wouldn't say sadistic, but the word "extreme" does come to mind.
Thanks for your long and insightful reply, Pops!
--
----- stephan beal
http://wanderinghorse.net/home/stephan/
