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: Scott Sauyet on 8 Mar 2010 15:54 Andrew Poulos wrote: > Scott Sauyet wrote: >> David Mark wrote: >>> Have you seen the shiny new Dojo Toolkit site? [ ... ] >> >> Umm... David, you do realize c.l.j.s. is about Javascript, right? > > I can see why he posted it to this group. Dojo considers itself a > leading javascript library and it would be reasonable to consider their > web site an example of how the library should/could be used. Instead it > appears to be a counter example. This was of course partially tongue-in-cheek. I know that David knows the purpose of this group. But he couldn't have really been criticizing the use of the Dojo Toolkit on the home page of the Dojo Toolkit, because as far as I can tell, it's not used at all -- really! But a 1700+-word post that contained maybe 100 words on Javascript, discussing instead such things as the location of the shortcut icon, the use of section comments in the markup, and the number of characters in their URLs, seems out of place here. The only substantive comments on the JS were that it was odd to need to explicitly specify that debugging is off and that synchronous AJAX requests are a bad idea. -- Scott
From: David Mark on 8 Mar 2010 23:48 Scott Sauyet wrote: > David Mark wrote: >> Have you seen the shiny new Dojo Toolkit site? [ ... ] > > Umm... David, you do realize c.l.j.s. is about Javascript, right? > It's c.l.j. and that site is all wild claims about JS. Get it? A review of the "toolkit" itself will follow.
From: David Mark on 9 Mar 2010 00:22 Scott Sauyet wrote: > Andrew Poulos wrote: >> Scott Sauyet wrote: >>> David Mark wrote: >>>> Have you seen the shiny new Dojo Toolkit site? [ ... ] >>> Umm... David, you do realize c.l.j.s. is about Javascript, right? >> I can see why he posted it to this group. Dojo considers itself a >> leading javascript library and it would be reasonable to consider their >> web site an example of how the library should/could be used. Instead it >> appears to be a counter example. > > This was of course partially tongue-in-cheek. I know that David knows > the purpose of this group. But he couldn't have really been > criticizing the use of the Dojo Toolkit on the home page of the Dojo > Toolkit, because as far as I can tell, it's not used at all -- really! Couldn't I have? Didn't you see it in there? That's exactly the mentality I am criticizing. They just dump that mess into every page, regardless of how much it is (or isn't) used. As for the rest of the pages on the site, most used jQuery. So this should give you pause when considering if you really want to buy into the BS on the front page. > > But a 1700+-word post that contained maybe 100 words on Javascript, You counted the words?! > discussing instead such things as the location of the shortcut icon, > the use of section comments in the markup, and the number of > characters in their URLs, seems out of place here. I'll decide what's in place here. :) And it all goes to prove that the developers are less than proficient at Web development. I mean. this is the best that the Dojo developers could do? There was quite the build-up for this long-overdue site. Does that make you want to believe their pitch? It demonstrates incompetence on so many levels. > The only > substantive comments on the JS were that it was odd to need to > explicitly specify that debugging is off and that synchronous AJAX > requests are a bad idea. > Yes, the synchronous Ajax requests have been integral to their BS from the start. It took me months to convince them that they were wrong to use those. Still, they remain as nobody wanted to bother merging in the changes required to put those out of the picture (too much like work with no "wowie" effect I guess).
From: S.T. on 9 Mar 2010 13:33 On 3/8/2010 1:04 AM, David Mark wrote: > What experienced developers? What Web? Where? And scales?! I've yet > to see a site out of this bunch (even a basic page) that doesn't > download ten times what it should. A quick glance shows that the front > (well only) page of the aforementioned Foundation site weighs in at:- > > Total HTTP Requests: 45 > Total Size: 454259 bytes On dojotoolkit.com? I show two-thirds less size and a third-less requests than you're showing. The YSlow firebug add-on quite likes what they've done, in fact. > ... like Cappuccino (another massive folly that > has no shot of ever gaining acceptance on the Web). Out of curiosity if Cappuccino has no shot at gaining acceptance, do you believe "My Library" does? > <div id="page" class="homePage"> > > The camel-case class name must have seemed like a cool idea (of course, > it isn't). And what sort of ID is "page?" What's possibly wrong with camel-case in CSS? I frequently use it - increases readability dramatically when quickly scanning, especially if you prefer single-line rules like I do, i.e. #leftLink {font-size: 1.1em; color: blue} ..rightLinks {padding-left: 5px; text-decoration: none;} #leftColumn a {color: red} > > <img > src="/dojango/dojo-media/release/1.4.0-20100212/dtk/images/logo.png" > alt="Dojo Toolkit" /></a></span> > > The outrageously long paths for every asset are ridiculous. Why would a long path possibly matter? Safe bet these links these aren't being hand-coded. > <form method="GET" action="http://www.google.com/search" id="search"> > <span> > <input type="text" name="q" id="query" value="Search" /> > > Ugh. Name/ID mismatch. What's wrong with different name/ID? Nothing. Google want's the GET variable to post as 'q'. 'q' isn't very descriptive in a style sheet. ID's need to be unique on a page, names do not. Plenty of instances where form element's id/names should be different. If I'm unsure of the finished design or the form will be re-used and am using a common name (i.e. "email") I'll always use differing ids/names. > <div class="innerBox"> > > Another interesting class name. How so? > <span class="version"><h1>1.4</h1> <span>Instantly Better Web > Apps</span></span> > > Am I seeing things? An H1 inside of a SPAN? span.version is position:absolute. It's no longer inline. H1 is fine inside it. That was a largely ridiculous, ticky-tack critique of underlying HTML that makes it pretty clear you don't design anything more complicated than what's on cinsoft.net. If you did you'd realize how ridiculous it is to expect the designer(s) to go back and waste time changing single-used classes to ids, swap spans that already compute to block-level to divs to make the code 'pretty', parse code to strip an unused span that has zero impact in any event, and so on. I'll grant you a library that supports Opera probably shouldn't use a non-Opera supporting jQuery-based forum. Maybe you have a legitimate beef with how they instituted 'your' aural/handheld styles - don't know, don't care. If you spent half as much time documenting "My Library" as you do criticizing everything else -- perhaps someone would actually use it. Of course actual usage was never the motive of "My Library", was it? On the plus side, I've never really looked at Dojo Toolkit before. I quite like their widgets in contrast to the (IMHO) still too rough-around-the-edges jQueryUI. Might give it a shot in an upcoming project.
From: S.T. on 9 Mar 2010 16:14
On 3/9/2010 12:33 PM, Gregor Kofler wrote: > It is. span is and will always be an inline element. > >> http://webkit.org/blog/117/webcore-rendering-iv-absolutefixed-and-relative-positioning/ > > >> "When an object is absolute/fixed positioned, it becomes block-level. >> Even if the CSS display type is set to inline (or inline-block/table), >> the effective display type becomes block-level once an object is >> positioned. " > > So? This doesn't state that by setting some CSS properties and invalid > markup will become valid. > >> Check computed display styles of absolute positioned spans in various >> browsers. They aren't inline. > > I never said that. The markup is invalid. That's all. > Alright, I see where you're coming from here. Yes, I'll concede if validating HTML to its DTD it'll come out invalid. |