New Dojo Site--Most incompetent ever?
in [JavaScript]
|
Prev: Javascript Toolbox - Table Sort utility - Column Width cannot be set.
Next: FireFoc support forums (Re: FF3.6 Stack output from Too MuchRecursion)
From: S.T. on 10 Mar 2010 16:20 On 3/9/2010 7:10 PM, Andrew Poulos wrote: > On 10/03/2010 11:43 AM, S.T. wrote: >> Validating is a debugging tool - that's it. It's not important if a page >> "passes" or not. > > For me, not caring about validation is the equivalent of incompetence. Fascinating tidbit Andrew. I'm guessing validating is important to programmer types because many have personalities that gravitate toward 0/1 - true/false structure. Unfortunately the web offers no such measure. Validating against W3C gives the illusion of such measure, but the scale is irrelevant.
From: David Mark on 10 Mar 2010 16:16 S.T. wrote: > On 3/9/2010 7:10 PM, Andrew Poulos wrote: >> On 10/03/2010 11:43 AM, S.T. wrote: >>> Validating is a debugging tool - that's it. It's not important if a page >>> "passes" or not. >> >> For me, not caring about validation is the equivalent of incompetence. > > Fascinating tidbit Andrew. > > I'm guessing validating is important to programmer types If you have been reading the replies, you should have realized by now that it is important to competent and trustworthy types. > because many > have personalities that gravitate toward 0/1 - true/false structure. That makes no sense at all. Like I said, you should take the five minutes to install a smoke detector. Yes (obviously), your house may still burn down. > Unfortunately the web offers no such measure. You take measures. The Web just so happens to offer tools to help. > Validating against W3C > gives the illusion of such measure, but the scale is irrelevant. So I say take five minutes and validate and at least skim the results. You say "the scale is irrelevant?" What does that even mean?
From: S.T. on 10 Mar 2010 16:51 On 3/10/2010 11:54 AM, David Mark wrote: > But you can't judge your work by empirical evidence as you can't see > every browser/mode/configuration, past, present and future. To ensure > that your sites work (and continue to work) in the maximum number of > environments, validating your markup is an essential first step. After > that you need to consider what scripts you will allow between your > markup and your users. Just because you can't see something fail > doesn't mean it isn't failing (or will fail) for somebody somewhere. > You start out with no scripts, which means there is nothing to foul up > your documents. With each script that you add, particularly if you do > not know _exactly_ what they are doing, you increase the likelihood of > pissed off users. You have a tendency to speak of web pages as static entities that need to survive the test of time. That's rarely the case. Only the content need "survive". More often than not, and nearly always on any large-scale site, content is safely tucked away in a database, or stored as a number of files in a directory (i.e. images) or other self-contained manner. Often content has a long life cycle. The markup to render this content, the server-side scripting to manipulate and present the content and the client-side scripting to interact with this content is ever-evolving. It's easily fixed. It's frequently changed/updated/redone from scratch. It has a shorter life cycle than the browser market, and infinitely shorter than the W3C. I can see the points you're making about the dangers of invalid markup and popular js library's to a current page's future. However there is (virtually) no need to protect my site's markup and interactive functionality from the future. It's not intended to make it there. Perfect the content for use in the future. Work in the 'now' for the presentation. Short on time.
From: David Mark on 10 Mar 2010 16:57 S.T. wrote: > On 3/10/2010 11:54 AM, David Mark wrote: >> But you can't judge your work by empirical evidence as you can't see >> every browser/mode/configuration, past, present and future. To ensure >> that your sites work (and continue to work) in the maximum number of >> environments, validating your markup is an essential first step. After >> that you need to consider what scripts you will allow between your >> markup and your users. Just because you can't see something fail >> doesn't mean it isn't failing (or will fail) for somebody somewhere. >> You start out with no scripts, which means there is nothing to foul up >> your documents. With each script that you add, particularly if you do >> not know _exactly_ what they are doing, you increase the likelihood of >> pissed off users. > > You have a tendency to speak of web pages as static entities that need > to survive the test of time. That's rarely the case. No, you have misconstrued my message somehow. Static or not, the same rules apply. > > Only the content need "survive". More often than not, and nearly always > on any large-scale site, content is safely tucked away in a database, or > stored as a number of files in a directory (i.e. images) or other > self-contained manner. Stored as a number of files in a directory? That pretty much describes anything and everything. And yes, some of those files may be databases. > Often content has a long life cycle. Some content does, some content doesn't. Irrelevant regardless. > > The markup to render this content, the server-side scripting to > manipulate and present the content and the client-side scripting to > interact with this content is ever-evolving. You aren't really saying much of substance. It sounds as if you are building towards an excuse to just do anything and never mind what happens as a consequence. > It's easily fixed. You don't have to fix what is not broken. > It's > frequently changed/updated/redone from scratch. What is? You've pretty much said everything is redone from scratch often. > It has a shorter life > cycle than the browser market, and infinitely shorter than the W3C. You are focusing on the future, but I take it you haven't mastered the past or present yet. > > I can see the points you're making about the dangers of invalid markup > and popular js library's to a current page's future. And its present (which is influenced by the past). > However there is > (virtually) no need to protect my site's markup and interactive > functionality from the future. Ah, so you are talking about _your_ sites. Again, concentrate on the present for now. > It's not intended to make it there. And it surely won't if it is already broken in the present. > > Perfect the content for use in the future. "Perfecting" content is beyond the scope of this discussion. I'm not even sure what that means in most contexts. > Work in the 'now' for the > presentation. The CSS? Yes, it should work today (and hopefully tomorrow as well or your future visitors will be upset). And no, it doesn't make the slightest bit of sense to perpetually rewrite style sheets (or markup for that matter). It's a good thing that the W3C is so slow. It makes it easy to reuse the same templates for years on end. And now that the browsers (at least the majors) have converged somewhat, it is even less likely that you would need to jump through hoops for them either. I have the sneaking suspicion that you are trying to justify doing things in some extremely hard way that is completely alien to me (and no, it isn't because I think of all Web pages as static). > > Short on time. > If you knew Time as well as I do... :)
From: Garrett Smith on 10 Mar 2010 18:22
David Mark wrote: > Garrett Smith wrote: >> David Mark wrote: >>> SteveYoungGoogle wrote: >>>> On Mar 10, 12:11 pm, David Mark <dmark.cins...(a)gmail.com> wrote: >>>>> David Mark wrote: >>>>>> SteveYoungGoogle wrote: >>>>>>> On Mar 10, 5:42 am, David Mark <dmark.cins...(a)gmail.com> wrote: >>>>>>>> S.T. wrote: >>>>>>>>> On 3/8/2010 1:04 AM, David Mark wrote: [...] >> The problem is the code itself. The code is large. There is disturbingly >> faulty logic in the core of dojo itself (some of it discussed in this NG >> archives). > > It's the tip of the iceberg. Wait until you see my review of Dojo 1.4 > (coming soon to cinsoft.net). Of course, it looks very much like Dojo > 1.3 as nobody over there touches the core, which is understandable once > you grasp the depth of their misunderstandings (who wants to fiddle with > a foundation that they can't even explain). > The core has many dependencies and so trying to adjust that, with so many things that require it, is a risk. OTOH, the problems won't go away by ignoring them. Fixing the problems sounds like a good idea, but then there would have to be somebody capable of doing that, and if it is going to be done by the original authors, then much learning should take place prior to doing that (or different mistakes will be made). Regaring your review, I would like to suggest the following document: http://www.jibbering.com/faq/notes/review/ I'd also like comments on how it can be improved. >> Projects that have used Dojo FWIS, tended to have performance issues and >> take too much effort to maintain. > > Yes. > >> Significantly larger projects (72+ man months) having a poor outcome or >> total failure is a more significant failure than a smallish website that >> throws a few errors and hangs for two seconds. The dojofoundation isn't >> much worse than any other pop website nowadays. >> > > Er, size your browser window down a few notches... :) The Dojo site is a fine incompetence exemplar, but so are others. A bad corporate website is not nearly as bad as a large corporate software project failing. Half a million dollars is not something that should be thrown in the trash. -- Garrett comp.lang.javascript FAQ: http://jibbering.com/faq/ |