All the members of the exceptional performance team at Yahoo! and Google are designers, thus not knowing technology? Yes, sounds very likely…

Interesting to hear that you believe you are in the position to completely discard the results of some of the best performance specialists in the world, working for Google, yahoo! etc.

Lack of caching
LOL – there`s nothing more to say
Poor accessibility
“This means that it won’t work when JavaScript, for one reason or the other, isn’t available.” – Javascript does not work when javascript is not available , good one, good and bright …. FAIL

Difficult code maintenance
“When it comes to making changes to the code, I’m sure every web developer would agree “… That you search for the element in the page. Who uses 800 html pages anymore ? Seriously if you have 10 pages that display a menu and you do not include that menu as a template you`re just plain stupid. You don`t have to change 50 pages, you only have to change the page in which your element is located. And again … FAIL.

FYI ooCSS is the way to go – all margins widths heights sizes should be inline (why ? because your size if often based on some calculations and differs from browser to browser – hacks are stupid)

I’m happy for your sake that you have fallen in love with XSLT – most of the world have moved on to other approaches; nothing wrong with it, but I can’t really see why it would be the ultimate solution to any factor in good web development.

Have you actually studied this or is this just a feeling you have?

Since you mentioned YSlow, are you familiar with the performance work Yahoo have been doing? Have you read their recommendation Make JavaScript and CSS External (where anything inline really only could possibly apply to start pages of companies like Google, but given the reoccurring searches people do, not even there). What I write about in this blog post is common knowledge amongst web professionals all over the world.

Have you ever read about Unobtrusive Javascript? That web site and material about that is by Christian Heilmann, one of the world’s leading authorities on web development, and high up within Yahoo.

About YSlow grade on this web site: if you had actually taken the time to look what HTTP requests, CSS and scripts that are affected, none of it stems from this web site – it’s about code served from, amongst others, Google and Flickr, who have decided not to offer expire headers and minifying. And CDNs aren’t even applicable unless for very very high traffic web sites.

According to Alexa, 99% of the world’s web sites are slower than robertnyman.com, which I would say is a pretty good indication of the performance of this web site.

Overall, I like discussing these things, they’re far from black and white, but I feel that your tone and approach has been disrespectful from the get-go. Therefore, I agree that we end this now, it will definitely not make anyone of us happier.

Overall, I agree that user performance is important.

However, the argument that HTML is the heavy part of downloading bandwidth with inline scripts is a tempest in a teapot. Have you actually studied this or is this just a feeling you have? Most of the bandwidth these days is in downloading script and css files, not in html content, even with inline scripts.

I also just tested this page with YSlow. It got a “Grade B” including: Grade B Make fewer HTTP requests, Grade F on Use a Content Delivery Network. Grade C on Minify JavaScript and CSS. Seems like a lot of wasted bandwidth. How ironic.

Your argument is also not even germane about caches. You can turn off caching in a browser. I have mine to clear the cache on shutdown. So cache reliance is not guaranteed. And I have to reload your scripts again anyway tomorrow. Thus, you have saved me little unless I browse your site extensively today. Maybe I am not “a normal user”, but that is just the point, you can never encompass all user behaviors.

I also find it a performance hit using the very scripts on this page showing me my “comments” as I type. As I type more and more there starts to be a lag between what I type (I am a very fast typist) on my keyboard and when it appears on the screen. I suppose you think it is smart to limit my bandwidth and not show me a “preview” page, but I find the developing lag very annoying. So I turned of scripts just to type here. Even more annoying there is not a “page preview” option for when I turn off scripts.

And you missed my point about separation of content from context. It was about maintaining a single piece of code, one that does each task, in only one place, not two, as just good design. And no, mixing them the way you did is not needed. And exposed hooks should be generic in scripts, should be based on the type of element making the call, and else should not know or care any more about the context of that element. Hence one should never ever hard code an “id” value as a constant in a script. You only do so because of your desire to “save bandwidth” which really is a straw man leading you down a road of overall bad design.

Anyway, I will leave this as we just disagree.

Browser-side XSLT? Seriously? It’s not a nice thing, performance-wise, and especially not when it comes to inconsistencies between web browsers and their parsers/implementations.

Hence why JSON has become so popular, for instance.

And of course it’s a performance hit if you need to re-download inline styles and scripts for every page you visit in a web site, as opposed to having it stored in the user’s web browser cache. If you transform it into the desired HTML via XLST on the server doesn’t really have anything to do with it.

Then we have accessibility and SEO: you can’t just depend on JavaScript and serving small portions (i.e. not complete pages) of code to everyone. For anyone with the capabilities, sure, that’s called progressive enhancement, but you need to offer a version that works without that as well.

Not sure if I misunderstand about events, but if that’s the case, why attach hundreds of events to each cell? I guess/hope you only have five actual event handlers, and that you let the events bubble up to them.

About a central location being “defeated”: as with all code when it comes to CSS and JavaScript, naturally you have hooks for you or anyone else to interact with it; things that might also be exposed via an API, for Firefox extensions etc.

I also think you misunderstand the central location idea: it’s that ALL presentation code is in one single place and that ALL interaction code is in one single place.

Conclusively: if you love XSLT and your spreadsheet application, great. But for building public web sites, there are a lot more factors to consider.

Second, you can also process the exact same XSL file on the server and send only formated HTML, so there need be no browser rendering and thus no performance hit on the client. My code is reuseable with two different methods of delivery.

Third, hundreds of dom attached events, not “script events”, because it is a spreadsheet program, with events per cell, and they are all delegated to about 5 main controlling functions.

Finally, in your example you have the “id” value “get-news” hard coded twice, in two different files (html and script files). Using XSL I can reference this value once in a database and build my XML content on the fly. My context (what the user sees) XSL file does not even know or care about “id” attributes. Thus one of your arguments to keep changes to a central location is defeated: you have it in two places. I have it in one.

How the content is generated – be it XSLT or any other technology – is irrelevant. What matters is what times time for the web browser to render, how content is cached locally between pages in a web site etc. That is how your end users will perceive the content and that is what really makes a difference.

And if you have hundred of events, something isn’t coded properly. Look into event delegation instead, which is really the only correct way of handling events.

<?xml version=”1.0″ encoding=”UTF-8″?>
<xsl:stylesheet version=”1.0″ xmlns:xsl=”http://www.w3.org/1999/XSL/Transform” >

<xsl:template match=”/root”>
<html>
<head></head>
<body bgcolor=”#FFFFFF”>
<div id=”container”>
<div id=”navigation”>
<xsl:apply-templates select=”links” />
</div>
</div>
</body>
</html>
</xsl:template>

<xsl:template match=”links”>
<xsl:for-each select=”link”>
<a>
<xsl:for-each select=”@*”>
<xsl:attribute name=”{name()}”>
<xsl:value-of select=”.” />
</xsl:attribute>
</xsl:for-each>
<xsl:value-of select=”caption” />
</a>
</xsl:for-each>
</xsl:template>

</xsl:stylesheet>

<?xml version=”1.0″ encoding=”UTF-8″?>
<?xml-stylesheet type=”text/xsl” href=”test_news.xsl”?>
<root>
<links>
<link id=”get-news” href=”news-proper-url” onclick=”clickme”><caption>See</caption></link>
</links>
</root>

<?xml version=”1.0″ encoding=”UTF-8″?>
<?xml-stylesheet type=”text/xsl” href=”test_news.xsl”?>
<root>
<links>
<link id=”get-news” href=”another-url”><caption>Vu</caption></link>
</links>
</root>

<?xml version=”1.0″ encoding=”UTF-8″?>
<?xml-stylesheet type=”text/xsl” href=”test_news.xsl”?>
<root>
<links>
<link id=”get-news” href=”another-href” onclick=”another-clicker”><caption>Sehen</caption></link>
</links>
</root>

First of all, worrying about time to load is pointless if you neglect issues like time to register “onclick” events. We have hundreds of events per page and that does indeed slow things down a bit as well. Also, you should not use “onclick=function” you should use addEventListener or equivalent for what is understood by each browser.

Also, you complain about in-line scripts, and yet you inline and hardwired the language to English.

Your mistake is you are looking at this completely from the wrong site, the side you “see” in the browser. But a lot more should be done before anything even reaches the browser in a visible form. That is, you should use what you do not see: a template system. I am sure this is what Google does. Then most issues you note as being a “problem” regarding in-line script go away and in fact are part of the solution. For example, try XSLT and XML to split content and context. You can use XSLT on the server or in the browser.

Something like:

&lt?xml version=”1.0″ encoding=”UTF-8″?&gt
&ltxsl:stylesheet version=”1.0″ xmlns:xsl=”http://www.w3.org/1999/XSL/Transform” &gt

&ltxsl:template match=”/root”&gt
&lthtml&gt
&lthead&gt&lt/head&gt
&ltbody bgcolor=”#FFFFFF”&gt
&ltdiv id=”container”&gt
&ltdiv id=”navigation”&gt
&ltxsl:apply-templates select=”links” /&gt
&lt/div&gt
&lt/div&gt
&lt/body&gt
&lt/html&gt
&lt/xsl:template&gt

&ltxsl:template match=”links”&gt
&ltxsl:for-each select=”link”&gt
&lta&gt
&ltxsl:for-each select=”@*”&gt
&ltxsl:attribute name=”{name()}”&gt
&ltxsl:value-of select=”.” /&gt
&lt/xsl:attribute&gt
&lt/xsl:for-each&gt
&ltxsl:value-of select=”caption” /&gt
&lt/a&gt
&lt/xsl:for-each&gt
&lt/xsl:template&gt

&lt/xsl:stylesheet&gt

Then any of these XML will always work (be sure to send proper xml headers from your server), for three different languages with and without scripting included. And you never have to touch the display context XSL file above. This is much easier to maintain than your “solution” since your XML content, the only thing that should change, can be built on the fly:

&lt?xml version=”1.0″ encoding=”UTF-8″?&gt
&lt?xml-stylesheet type=”text/xsl” href=”test_news.xsl”?&gt
&ltroot&gt
&ltlinks&gt
&ltlink id=”get-news” href=”news-proper-url” onclick=”clickme”&gt&ltcaption&gtSee&lt/caption&gt&lt/link&gt
&lt/links&gt
&lt/root&gt

&lt?xml version=”1.0″ encoding=”UTF-8″?&gt
&lt?xml-stylesheet type=”text/xsl” href=”test_news.xsl”?&gt
&ltroot&gt
&ltlinks&gt
&ltlink id=”get-news” href=”another-url”&gt&ltcaption&gtVu&lt/caption&gt&lt/link&gt
&lt/links&gt
&lt/root&gt

&lt?xml version=”1.0″ encoding=”UTF-8″?&gt
&lt?xml-stylesheet type=”text/xsl” href=”test_news.xsl”?&gt
&ltroot&gt
&ltlinks&gt
&ltlink id=”get-news” href=”another-href” onclick=”another-clicker”&gt&ltcaption&gtSehen&lt/caption&gt&lt/link&gt
&lt/links&gt
&lt/root&gt

It’s not just about personal preference, it’s about respecting your end users and stop wasting their time as well – why use unnecessary bandwidth?

When it comes to code being readable, most code in the world is handled by several developers, or handled over to other people – it’s a developer’s obligation to write good code.

Yeah, it may take a fraction of a second more to load a page, but are we really all that impatient? Another thing, does code need to be pretty?

My code is ALWAYS rittled with secret numbers, words, etc inline. In fact, if anyone ever read my code they’d have no idea what is going on. I do though, and that’s all that matters.

One thing that pisses me off about programmers is that they all seem to have a ‘better’ way of doing things. This is where the mind seperates between ego and intelligence and ego is all that’s left.

Back to the code. My css is inline so I don’t have to specify over a thousand unique classes for what is sometimes only one word.

About caching. You can easily have your site load from the server every time rather than lapping up the cache. IE is one of the whores that usually always does this.

File size. Each html file is over a thousand lines of code and is no more than 50kb.

I will admit however that I have a simple site for people who use IE and get viruses every time they go to ANY site, and a version for firefox which is high resolution and heavy on bandwidth.

The heavy version is total 1.7mb. Yes, that’s alot for people who live in GA and still have to dial up but not for people like me who see no difference in google response and my response. And the heavy site is 1280 * 1024.

The simple site isn’t done so can’t accurately be measured however it can accept any resolution and works in any browser mode. This one will no doubt be indexed by google but the other one is not so likely, which is fine. The heavy site is only for people that adore visual appearance and artistic effects.

In other words, a site for people who are boring, and a site for people that are not. msnbc.com = boring, ninjai.com = not. That kinda thing.

I guess my last words are this. Everyone has there own style of programming just like everyone has their own style of drawing. It’s because of development teams of 100+ people that we all have to think alike. This is why I’m glad I don’t work for anyone and make more money than if I did.

In the article, I have explained just a few of the common scenarios where JavaScript isn’t available for end users, and it is beyond their own control.

If you’re not interested in about being serious with your web development and cater to everyone, too bad.

What I meant was that the event in the example code was used on a span element, i.e. an element that doesn’t even have a native click handling functionality (like links and their href attribute).

If it had been a link element instead, your suggestion would work just fine (although you would still like the code separation for overview, caching etc).

Poor accessibility
When it comes to inline JavaScript code, such as in the above example, it’s applied to an element which doesn’t have any built-in fallback interaction handler (i.e., like a link takes you to the URL specified in its href attribute etc). This means that it won’t work when JavaScript, for one reason or the other, isn’t available.

Why can you not define an href for non JS users and make callSomeFunction() return false for the JS users? Returning false will ensure the href link isn’t followed through on.

Cheers

MarkB