Yahoo Developer Blog

"... I don't think web developers have to think about disk I/O unless they're Google or Yahoo. ..."

I'm not sure about this.

For "any" interactive Webapp, speed is important. If you have repeated queries to/from, DB I/O does come into the picture when peak loads occur. So right when you get lots of users, the site will be hit. I've seen this with e-commerce (where user speed == $$$) where sure enough every peak time the server(s) would begin to grind. Remember your max speed will be determined by bandwidth. DB I/O will have some effect to slow response times. Maybe not as much as bandwidth but it is still something you must consider. Not every site is as extreme as e-commerce but the idea is still valid.

"... Every Web usability study I have conducted since 1994 has shown the same thing: users beg us to speed up page downloads ..." ~ http://www.useit.com/alertbox/9703a.html

Why is it important? Well user perception is one.

user: "Gee your application is slow compared to google, a bit slower than amazon"

developer: "But google invests squillions in hardware, network connections . Their applications run in memory. My apps run on fast hardware, I optomise for small pages ...."

user: "... So, it still appears slow"

If a user thinks your site is slow (and if you subscribe to the idea that you are creating web applications as apposed to documents) you need to keep your response times as close as possible to applications that people use every day.

It doesn't help that…

I think you raise a very good question.

I hadn't explicitly considered it before, as I was writing from my feelings on what a Web developer should know. Let me try to define my cut off.

It's not where the abstraction stops, because TCP/IP/SSL aren't part of the average Web framework (maybe some provide their own server, but I'm not aware of any), but it definitely includes everything the abstraction for framework does.

Is it abstraction + 1 level? Maybe.

I have a feeling different languages and areas have different cut-off points -- Web dev differs from Erlang dev.

For the Web, I think the cut-off point is TCP/IP because it is so central to the way the whole thing works, but is not too technical to be hard for the average developer to understand. As far as SSL/TLS is concerned, I provide a specific example of when an understanding of SSL is needed.

There are reasons go deeper (http://developer.yahoo.net/blog/archives/2009/10/a_engineers_gui.html talks about Ethernet frames and payload sizes), but I think an understanding of TCP/IP and the encapsulation they implement will allow a knowledgeable Web developer to understand the technical details.

I don't think there's any place to stop, necessarily, and I think these discussions are useful because they help to shape what we define as important knowledge. So, while I may not have a concrete answer to your question, I think we have a good starting point at which to draw the line.

Even Googlers agree with Eran, xauth is just a temporary solution, the real solution should go into the browser, maybe with a API that is xauth compatible. Mozilla is already working on those ideas.

edit, from another googler: http://www.google.com/buzz/dclinton/RcW6X3EjKj1/John-Panzers-take-on-the-XAuth-project-is-pretty

> John Panzer's take on the XAuth project is pretty much spot-on. It's not that XAuth is what anyone wants for the ultimate answer in this space. > Rather, XAuth is a short-term way of pushing for any momentum in this direction.

> There are a number of companies leading it, btw:

> MySpace: http://xauthdemo.myspace.com/

> Microsoft: http://xauthdemo.mslivelabs.com/

> Yahoo: http://developer.yahoo.net/blog/archives/2010/04/xauth_oauth_and_yahoo_openid.html

> Etc., etc. (Eran suggested this was Google-led, which didn't quite strike me as accurate, given that Yahoo, Microsoft, MySpace, etc., were all as involved as Google was.)

> For more background on XAuth, I did a round-up of the various announcements and responses during the XAuth launch:: http://www.google.com/buzz/dclinton/CYgLcs24yqP/

As I talked about in the post, I have some pages that are popular with search engine visitors. They generally come to the page, read, and then leave. I serve CSS and Javascript in <style> and <script> tags on those pages so it's fewer HTTP requests, and loads faster.

Unless someone has a reason I should do otherwise?

UPDATE: From Yahoo: http://developer.yahoo.net/blog/archives/2007/07/rule_8_make_jav.html

"The key factor, then, is the frequency with which external JavaScript and CSS components are cached relative to the number of HTML documents requested. This factor, although difficult to quantify, can be gauged using various metrics. If users on your site have multiple page views per session and many of your pages re-use the same scripts and stylesheets, there is a greater potential benefit from cached external files."

"now why are we building "jails" within the compelling interactivity of the "web 2.0"?"

Usability. Take a look at the Yahoo research on OpenID for an example of just one standard:

http://developer.yahoo.net/blog/archives/2008/10/open_id_research.html

Asking why people are flooding Facebook is a great question, one that often doesn't get asked by geeks, probably because we assume the problem is simple human flocking behavior and people herding towards where the rest of their friends hang out. Nope, that's a necessary but insufficient condition - why did that crowd form in the first place? Just try using myspace for a day and it's painfully obvious.

Add to the failure list:

* Terrible performance - practically first rule for optimizing page rendering is "don't use CSS expressions"

http://code.google.com/speed/page-speed/docs/rendering.html
http://developer.yahoo.net/blog/archives/2007/07/high_performanc_6.html

* Only work on IE natch.

So, you have Javascript which was better performance and worked everywhere.

I think it's a little misleading to say it's the best feature no one ever used. CSS expressions were re-born as hardware-accelerated CSS3 transitions - with a much better, more focused implementation, and are pretty popular these days - especially for mobile.