Build web apps in Javascript - new service open for beta

[AppPad]

Hello,
This is a new website I am involved with, and we are seeking to open
up to a shortlist of users.

http://apppad.com

The basic overview of the service is:
- You define Object Type models & can use a Javascript API to persist
object data.
- You create HTML+Javascript applications (everything is provided for
you - no hosting or DB needed)

Hoping to find a few curious/interested Javascript gurus out there
who'd like to try it out.
Thanks & regards.

 

[Peter Michaux]

Hello,
This is a new website I am involved with, and we are seeking to open
up to a shortlist of users.

http://apppad.com

The basic overview of the service is:
- You define Object Type models & can use a Javascript API to persist
object data.
- You create HTML+Javascript applications (everything is provided for
you - no hosting or DB needed)

That is a neat idea. I'm sure there are people that know front-end
technology but not the database side of things. Adobe Air is trying to
leverage this knowledge to build desktop apps.

Hoping to find a few curious/interested Javascript gurus out there
who'd like to try it out.

Unfortunately I don't have the time but good luck!

Peter

 

[David Mark]

Hello,
This is a new website I am involved with, and we are seeking to open
up to a shortlist of users.

http://apppad.com

[snip]

An application framework based on HTML and JavaScript will require, at
the very least, developers who can write valid HTML and solid cross-
browser JavaScript. Best of luck in finding some.

 

[rf]

Hello,
This is a new website I am involved with, and we are seeking to open
up to a shortlist of users.

http://apppad.com

[snip]

An application framework based on HTML and JavaScript will require, at
the very least, developers who can write valid HTML and solid cross-
browser JavaScript. Best of luck in finding some.

They are certainly not living at the above URL

Not even a bloody doctype!

background-color: 666666; is probably why I get my shocking pink background

 

[David Mark]

They are certainly not living at the above URL

Not even a bloody doctype!

Yes, it is a bizarre melange of HTML 3.2 and XHTML-style markup. No
doctype (what would it be anyway?), no character encoding specified,
tables-in-tables (despite the spartan layout), no top-level headline,
  entitities in odd places, hyperlinks that break without script,
etc., etc. The really irony here is that the pages are clearly
template-driven and very small, so they only had a to get a very
limited amount of markup right once.

Here is an interesting sample:

<a href=""><a href="#" onClick="alert('Coming soon...')"
fref="feedback.jsp?appid=28">[App Feedback]</a><br/>

Then there is the script. This is a new one:

window.onload = document.onload = appCallOnLoad;

I can see why somebody might feel compelled to do such a thing, but at
the very least there should be logic to account for the fact that
appCallOnLoad might be called twice (there isn't.)

The most shocking display of incompetence can be found on the feedback
page, which features half a dozen lines of client-side validation,
which require (drum roll please) Prototype. (!)

Developing applications to run in this framework would be akin to
developing a condo complex in a swamp.

background-color: 666666; is probably why I get my shocking pink background

I didn't bother to look at the CSS, but that sample doesn't surprise
me. Perhaps the devil made them do it (twice.)

Back to the drawing board guys!

 

[AppPad]

Thanks for the feedback. This definitely seems like a knowledgeable
group.

The goal has been to test functionality on IE6+ and Firefox2+ (will
add that info to the docs). Prototype was used for some account areas,
but not running the "Apps".

Thanks for pointing out the appCallOnLoad - will give it a further
look.

[snip]

They are certainly not living at the above URL

Not even a bloody doctype!

Yes, it is a bizarre melange of HTML 3.2 and XHTML-style markup.  No
doctype (what would it be anyway?), no character encoding specified,
tables-in-tables (despite the spartan layout), no top-level headline,
&nbsp; entitities in odd places, hyperlinks that break without script,
etc., etc.  The really irony here is that the pages are clearly
template-driven and very small, so they only had a to get a very
limited amount of markup right once.

Here is an interesting sample:

    <a href=""><a href="#" onClick="alert('Coming soon...')"
fref="feedback.jsp?appid=28">[App Feedback]</a><br/>

Then there is the script.  This is a new one:

window.onload = document.onload = appCallOnLoad;

I can see why somebody might feel compelled to do such a thing, but at
the very least there should be logic to account for the fact that
appCallOnLoad might be called twice (there isn't.)

The most shocking display of incompetence can be found on the feedback
page, which features half a dozen lines of client-side validation,
which require (drum roll please) Prototype. (!)

Developing applications to run in this framework would be akin to
developing a condo complex in a swamp.

background-color: 666666; is probably why I get my shocking pink background

I didn't bother to look at the CSS, but that sample doesn't surprise
me.  Perhaps the devil made them do it (twice.)

Back to the drawing board guys!

 

[David Mark]

[snip]

They are certainly not living at the above URL
Not even a bloody doctype!

Yes, it is a bizarre melange of HTML 3.2 and XHTML-style markup. No
doctype (what would it be anyway?), no character encoding specified,
tables-in-tables (despite the spartan layout), no top-level headline,
&nbsp; entitities in odd places, hyperlinks that break without script,
etc., etc. The really irony here is that the pages are clearly
template-driven and very small, so they only had a to get a very
limited amount of markup right once.

Here is an interesting sample:

<a href=""><a href="#" onClick="alert('Coming soon...')"
fref="feedback.jsp?appid=28">[App Feedback]</a><br/>

Then there is the script. This is a new one:

window.onload = document.onload = appCallOnLoad;

I can see why somebody might feel compelled to do such a thing, but at
the very least there should be logic to account for the fact that
appCallOnLoad might be called twice (there isn't.)

The most shocking display of incompetence can be found on the feedback
page, which features half a dozen lines of client-side validation,
which require (drum roll please) Prototype. (!)

Developing applications to run in this framework would be akin to
developing a condo complex in a swamp.

I didn't bother to look at the CSS, but that sample doesn't surprise
me. Perhaps the devil made them do it (twice.)

Back to the drawing board guys!

[Post order restored]

Please do not top-post. It makes it difficult to follow the
conversation.

Thanks for the feedback. This definitely seems like a knowledgeable
group.

Nice attitude. There may be hope for your app yet.

The goal has been to test functionality on IE6+ and Firefox2+ (will

Realize you are testing in quirks mode due to the lack of a doctype.
Of course, before you add a doctype, you need to decide what flavor of
markup is appropriate for your needs (HTML 4.01 strict) and change the
existing markup so it will validate according to the chosen schema.

add that info to the docs). Prototype was used for some account areas,
but not running the "Apps".

Get rid of Prototype. You certainly don't need it.

Thanks for pointing out the appCallOnLoad - will give it a further
look.

Just lose the document.onload part. You don't need it.

 

[AppPad]

[snip]
They are certainly not living at the above URL
Not even a bloody doctype!
Yes, it is a bizarre melange of HTML 3.2 and XHTML-style markup. No
doctype (what would it be anyway?), no character encoding specified,
tables-in-tables (despite the spartan layout), no top-level headline,
&nbsp; entitities in odd places, hyperlinks that break without script,
etc., etc. The really irony here is that the pages are clearly
template-driven and very small, so they only had a to get a very
limited amount of markup right once.
Here is an interesting sample:
<a href=""><a href="#" onClick="alert('Coming soon...')"
fref="feedback.jsp?appid=28">[App Feedback]</a><br/>
Then there is the script. This is a new one:
window.onload = document.onload = appCallOnLoad;
I can see why somebody might feel compelled to do such a thing, but at
the very least there should be logic to account for the fact that
appCallOnLoad might be called twice (there isn't.)
The most shocking display of incompetence can be found on the feedback
page, which features half a dozen lines of client-side validation,
which require (drum roll please) Prototype. (!)
Developing applications to run in this framework would be akin to
developing a condo complex in a swamp.
background-color: 666666; is probably why I get my shocking pink background

I didn't bother to look at the CSS, but that sample doesn't surprise
me. Perhaps the devil made them do it (twice.)
Back to the drawing board guys!

[Post order restored]

Please do not top-post. It makes it difficult to follow the
conversation.

Thanks for the feedback. This definitely seems like a knowledgeable
group.

Nice attitude. There may be hope for your app yet.

The goal has been to test functionality on IE6+ and Firefox2+ (will

Realize you are testing in quirks mode due to the lack of a doctype.
Of course, before you add a doctype, you need to decide what flavor of
markup is appropriate for your needs (HTML 4.01 strict) and change the
existing markup so it will validate according to the chosen schema.

add that info to the docs). Prototype was used for some account areas,
but not running the "Apps".

Get rid of Prototype. You certainly don't need it.

Thanks for pointing out the appCallOnLoad - will give it a further
look.

Just lose the document.onload part. You don't need it.

Thanks again for the feedback. You are right about Prototype... it was
minimally used, so stripped it out. The doctype seems to be validating
alright as well.

Still have on the (fairly long) to-do list the onload calls. IE &
firefox didn't seem to play nicely on the same onload calls, so that
will take a bit more research on the best way to do it.

In case anyone is interested, there is now a Demo account you can try
from the AppPad homepage (which should give you a better idea what
this tool is about). The goal is to create a service that DHTML savvy
folks could use so they don't need to hassle with hosting for small
simple apps. It's true - not your everyday Joe knows this stuff, but
if it eventually helps a few folks out... then mission accomplished.

Regards, Steve

 

[David Mark]

Thanks again for the feedback. You are right about Prototype... it was

Good riddance to bad baggage.

minimally used, so stripped it out. The doctype seems to be validating
alright as well.

You should really use HTML strict. The steps required to make your
document validate against that doctype will be well worth it. You
will need to replace the old-fashioned presentational markup
attributes and elements with CSS.

Still have on the (fairly long) to-do list the onload calls. IE &
firefox didn't seem to play nicely on the same onload calls, so that

How so? Removing the document.onload bit shouldn't have any effect on
any browser that I know of (certainly not IE or FF.)

will take a bit more research on the best way to do it.

Not really.

window.onload = myfunction;

In case anyone is interested, there is now a Demo account you can try
from the AppPad homepage (which should give you a better idea what
this tool is about). The goal is to create a service that DHTML savvy
folks could use so they don't need to hassle with hosting for small
simple apps. It's true - not your everyday Joe knows this stuff, but

Well, savvy Web developers probably already have hosting accounts.
You will need to add more value. The Flickr mashup demo is a step in
the right direction. Provide a "gallery" of mashup tools and perhaps
you will have something, but the idea isn't new.

if it eventually helps a few folks out... then mission accomplished.

Best of luck.

 

[David Mark]

David Mark said the following on 2/21/2008 3:00 AM:




Don't let Thomas know that

Proprietary and error-prone approach. I know.

BTW, based on a recent post of yours, I take it that you now consider
this inferior to an onload attribute in the body tag. Something about
unobtrusive JS being a joke. Granted, it is a fairly ambiguous term
and the techniques associated with it are often misused, but I fail to
see the humor in it.

 

[David Mark]

David Mark said the following on 2/21/2008 4:31 AM:



Only in Thomas' warped mind is it.
Agreed.


No. I don't. You are using the onload event of two entirely different
objects. One is the body element, the other is the window.

However, in some browsers they amount to the same thing. For example,
setting window.onload cancels out the listener created in the body's
onload attribute.

In the context and post that I made that statement, it was a script that
was attempting to add an event handler to a single element. There are
three reasons I can think of, easily, for doing it that way:

1) An exercise in trying to dynamically add event handlers.
2) Lack of knowing better.
3) The guise of "unobtrusive javascript".

If you are adding multiple, duplicated, event handlers, then by all
means do it by script. Make it simpler on yourself. Then put the JS code
in an external file so that non script UA's don't have to download a lot
of code it will never use.

Right. It makes maintenance easier and is a more flexible structure
as well.

When people take it too far then it becomes a joke to me. I find it
humorous in a strange kind of way. Dynamically adding an event handler
to a single element instead of just coding it? Yeah, it is humorous to me.

I don't know. I don't like to mix script in with the markup.

It didn't help matters for me to have my weekly Monday meeting at work,
leave, open up my Intranet site Wednesday morning last week, encounter
error messages. Right Click>View Source, lets find the problem. What I
found was these two lines:

<script type="text/javascript" src="prototype-1.6.0.2"></script>
<script type="text/javascript" src="jquery-1.2.3"></script>

As Thomas would say: OMG.

A call to one of my senior programmers let me know they had spent the
afternoon Monday and all day Tuesday re-doing my Intranet so that it
would be "Unobtrusive Javascript to get the scripts out of the HTML
file" and the only way to do that was to "use jQuery and Prototype". No,

LOL. Where did you find this "senior programmer?" A soup kitchen?

it didn't put me in a good frame of mind about unobtrusive javascript.

Certainly unobtrusive JavaScript via Prototype *and* jQuery is
madness. Your "senior programmer" should be demoted to junior
janitor.

The other "defense" of it is to have "clean HTML". And that is also
humorous to me. People doing things that are good but they don't even
have the first clue *why* they are doing it that makes it unobtrusive.

That's the way of the Web currently.

And, no, he doesn't work for me anymore.

I imagine not. Clean HTML indeed. Simply add 200K of incompetent
script and just look at the difference!

One can only wonder where this "senior programmer" got his
information. Clearly he doesn't read this group.

 

[David Mark]

Randy Webb said the following on 2/21/2008 6:14 AM:



With the .js extension of course. It is what happens when I think ahead
of myself. They had installed jQuery and Prototype on the server and had
put it in every single page on my server and "fixing" code so that it
was "unobtrusive". No, I was not happy. They spent Thursday, Friday and
part of this last Monday fixing it.

And Tuesday looking for new jobs?

 

[Gregor Kofler]

David Mark meinte:

Certainly unobtrusive JavaScript via Prototype *and* jQuery is
madness. Your "senior programmer" should be demoted to junior
janitor.

Come off it! Janitors can save the universe.
<http://en.wikipedia.org/wiki/Space_Quest>

Gregor

 

[Thomas 'PointedEars' Lahn]

Agreed.

Once you recognized that there is inherent truth in the statement that your
favorite (collection of) browser(s) is not the standard for every user agent
out there, you will see how mistaken you really are here.

As Thomas would say: OMG.

Don't quote me unless you mean it.


PointedEars

 

[Thomas 'PointedEars' Lahn]

David Mark meinte:

Come off it! Janitors can save the universe.
<http://en.wikipedia.org/wiki/Space_Quest>

YMMD

\\// PointedEars, adding a "find my SQ6 game box" reminder

 

[Peter Michaux]

Once you recognized that there is inherent truth in the statement that your
favorite (collection of) browser(s) is not the standard for every user agent
out there, you will see how mistaken you really are here.

Please explain.

Peter

 

[Thomas 'PointedEars' Lahn]

Please explain.

There really is not much to explain. Assuming a proprietary feature to be
universally available is a jump to conclusions; a common fallacy, though.


PointedEars

 

[David Mark]

There really is not much to explain.  Assuming a proprietary feature to be
universally available is a jump to conclusions; a common fallacy, though.

Oh for the love of God. How many times are you going to dump on
window.onload without naming a single case where it might be
considered harmful? Assuming an agent does not support DOM2 (or
attachEvent), it is perfectly reasonable to use window.onload as a
fallback. As discussed in a recent thread, there is a way to detect
support for it, but most scripted enhancements have no need to do so.

 

[Thomas 'PointedEars' Lahn]

[...] Thomas 'PointedEars' Lahn [...] wrote:
David Mark wrote:
David Mark said the following on 2/21/2008 4:31 AM:
David Mark said the following on 2/21/2008 3:00 AM:
<snip>
will take a bit more research on the best way to do it.
Not really.
window.onload = myfunction;
Don't let Thomas know that
Proprietary and error-prone approach. I know.
Only in Thomas' warped mind is it.
Agreed.
Once you recognized that there is inherent truth in the statement that your
favorite (collection of) browser(s) is not the standard for every user agent
out there, you will see how mistaken you really are here.
Please explain.

There really is not much to explain. Assuming a proprietary feature to be
universally available is a jump to conclusions; a common fallacy, though.

Oh for the love of God. How many times are you going to dump on
window.onload without naming a single case where it might be
considered harmful?

As many times as I want to without running the risk of losing credibility
among those who still can think clearly. You instead, have already/just
become the victim of another logical fallacy known as "shifting the burden
of proof":

It is _not_ up to me to prove that I am correct, because the statement is
true by itself, the very meaning of the word "proprietary" in this context
and the truth of the fact that it applies to this situation (the "inherent
truth" I was talking about earlier). It is instead up to those who have
been jumping to the conclusion to prove that they are not incorrect (i.e.
that "proprietary" does not apply here), by providing proof that it works
for *each and every* user agent out there, present and future. As that is
(currently) impossible, their argument, if there ever was one, is rendered
irrelevant in the end.


HTH

PointedEars

 

[David Mark]

Peter Michaux wrote:
[...] Thomas 'PointedEars' Lahn [...] wrote:
David Mark wrote:
David Mark said the following on 2/21/2008 4:31 AM:
David Mark said the following on 2/21/2008 3:00 AM:
<snip>
will take a bit more research on the best way to do it.
Not really.
window.onload = myfunction;
Don't let Thomas know that
Proprietary and error-prone approach.  I know.
Only in Thomas' warped mind is it.
Agreed.
Once you recognized that there is inherent truth in the statement that your
favorite (collection of) browser(s) is not the standard for every user agent
out there, you will see how mistaken you really are here.
Please explain.
There really is not much to explain.  Assuming a proprietary feature to be
universally available is a jump to conclusions; a common fallacy, though.

Oh for the love of God.  How many times are you going to dump on
window.onload without naming a single case where it might be
considered harmful?

As many times as I want to without running the risk of losing credibility

Too late.

among those who still can think clearly.  You instead, have already/just
become the victim of another logical fallacy known as "shifting the burden
of proof":
Hardly.


It is _not_ up to me to prove that I am correct, because the statement is

I didn't say it was, just that it would be nice if you presented some
tiny shred of evidence to support your oft-repeated position that
window.onload is inherently error-prone. It would be more accurate to
say that assuming the window.onload property is supported is
inherently error-prone (as are all assumptions about host objects.)
You often suggest that an intrinsic body onload handler is a better
approach, yet assuming support for intrinsic handlers is no less error-
prone. In fact, in some browsers, it amounts to the same thing
(that's why assigning to window.onload can wipe out the body's
intrinsic handler.)

true by itself, the very meaning of the word "proprietary" in this context

We all know it is proprietary. The window object is not part of the
DOM. But in reality (as opposed to the specs), the window.onload
property is extremely reliable. I am just curious if you actually
know of a situation where using it (as opposed to relying on it to
make a page usable) could cause a problem that would not have occurred
had an intrinsic handler been used.

[snip]