%HTMLlat1; %HTMLsymbol; %HTMLspecial; ]> Roland van Ipenburg's logging attempt
Roland van Ipen­burg
To be stolen or blogged

/// Raise the lame (Un­der con­struc­tion), Come and catch a fire baby, don't let me fade away, don't let me fade away

Tow­el-snap­ping op­ti­mi­sa­tion

Mon­day 13 Fe­bru­ary 2012 22:44

When your au­di­ence is most­ly n00b front-end strug­glers, as a medi­um ex­ist­ing be­cause of pub­li­ca­tions and not so­lu­tions it's per­fect­ly rea­son­able to waste every­one's time adding an­oth­er chap­ter to the cir­cle jerk that do­ing some Bos­ton Globe web­site ap­par­ent­ly was. Other­wise it makes no sense, for the fol­low­ing rea­sons:

There is no re­li­able way to de­ter­mine the amount of band­width a user is will­ing to spend on a sin­gle re­source. Be­cause screen size is all we've got to query in some mo­bile cu­ri­ous way that doesn't mean it's us­able or ef­fi­cient to do so. So it's some Spiel­erei to pre­pare for the mag­ic event when there is an API that we can use to de­ter­mine the band­width on a de­vice? No, be­cause mo­bile means there isn't a sin­gle band­width on a de­vice. Even an API can't pre­dict when con­di­tions sud­den­ly get worse be­cause a de­vice moves from Wifi to Edge. In such a volatile en­vi­ron­ment it's back­ward to keep think­ing in mono­lith­ic bitmapped re­sources ar­riv­ing af­ter craft­ing a sin­gle re­quest for it. There's wavelets, pro­gres­sive schemes and vec­tor based im­ages that are much bet­ter at us­ing band­width flex­i­ble and ef­fi­cient­ly be­cause they can stream un­til some­thing de­ter­mines there is enough res­o­lu­tion, and re­sume when more is need­ed. But if you're look­ing for a markup so­lu­tion - be­cause that is what your au­di­ence is crav­ing for - it's just mov­ing the same old pro­to­col into an­oth­er lay­er, ef­fec­tive­ly of­fer­ing the user no ad­van­tage. Just wast­ing time wait­ing to get some­thing into a stan­dard it shouldn't be in in the first place, but ap­par­ent­ly it's to hard to get de­sign­er-slash-de­vel­op­ers to ask serv­er spe­cial­ists to solve their prob­lems prop­er­ly. That's why hey are called HTML mon­keys.

And even if you've gone through such great lengths to pre­vent suck­ing re­dun­dant data over some­one's pre­cious con­nec­tion, only one click seper­ates that user from go­ing to an­oth­er web­site that didn't and makes the ef­fect of your op­ti­mi­sa­tions seem pret­ty use­less. It's like risk­ing your life to re­move a sin­gle mine from a mine­field and then claim you've made an im­prove­ment in safe­ty for the user. But that user isn't go­ing near your sin­gle safe spot as long as all the oth­er mines are still there. Nice tech demo, but in the real world the whole ecosys­tem the user op­er­ates in has to have some min­i­mal lev­el to make it us­able in he first place. And the core of that ecosys­tem is still the brows­er.

Browsers should do a lot more than just im­ple­ment web stan­dards flaw­less­ly. Ini­tia­tives like Opera Mini show users can be giv­en good tools with­out some stan­dards body first have to make a stan­dard for it, or every web­mas­ter come up with his own rein­ven­tion of what should be brows­er fun­cional­i­ty. But if all HTML mon­keys can do is markup and think in markup they will nev­er un­der­stand how to build a brows­er and solve the real prob­lems. They seem to have enough is­sues grasp­ing why browsers don't func­tion as they would ex­pect them to work from their markup view­point any­way.

Dustin Cur­tis is an ass­hole.

Sun­day 12 Fe­bru­ary 2012 16:04

For the ben­e­fit of the weak of mind it would have been so much eas­i­er to let Mi­crosoft win the brows­er wars ten years ago. That would have giv­en us for ex­am­ple a nice vec­tor based graph­ics im­ple­men­ta­tion, hard­ware ac­cel­er­at­ed graph­ics ef­fects and web ty­pog­ra­phy. At this point when We­bKit seems to have the same ad­van­tages as In­ter­net Ex­plor­er had ten years ago mon­ger­ing the killing of W3C is like sup­port­ing democ­ra­cy only to get into pow­er and then start sup­port­ing dic­ta­tor­ship. There is of course noth­ing wrong with dic­ta­tor­ship when you're the dic­ta­tor or part of it's clan. So buy some shares of $AAPL or $GOOG and start build­ing We­bKit only sites: there is noth­ing wrong with ven­dor lock-in if you're the ven­dor.

Stan­dards aren't de­signed for the cur­rent MVP de­vel­op­ment men­tal­i­ty of the min­i­mum vi­able de­vel­op­ers that most web de­vel­op­ers seem to be these days. If your only main­te­nance is­sue with web stan­dards would be giv­ing an in­tern the lo­gin to your WordPress site, you shouldn't care about web stan­dards and ven­dor pre­fix­es. And only the de­vel­op­er with a min­i­mal vi­able mind­set would in­ter­pret ven­dor pre­fix­es as be­ing "ex­per­i­men­tal", and pro­pose to pro­mot­ing them to have only -al­pha- or -beta- mean­ing. They are just a mech­a­nism for al­low­ing a name­space with­in the syn­tax of valid CSS so you don't have to split it at the MIME type. Which is nice in case you're work­ing on a closed sys­tem in which you have con­trol over both the ren­der­ing en­gine and the code it's ren­der­ing. And of course Ap­ple and Google con­sid­er the whole in­ter­net their closed sys­tem in which they soon have con­trol, with or with­out W3C. Com­bine that with a myr­i­ad of n00b web de­vel­op­ers who bet on hav­ing moved on to some­thing else when their stan­dards-ig­no­rant code hits the fan in a cou­ple of years, and Flash seems like a good idea.

The real is­sue is that with the pro­pa­gan­da of HTML5 as the set of new HTML and CSS com­bined with JavaScript APIs in a mod­ern brows­er it hard­ly makes sense to de­fine fu­ture HTML and CSS stan­dards from the per­spec­tive of a plat­form that lacks JavaScript. If oth­er brows­er ven­dors don't start sup­port­ing -we­bkit pre­fix­es any JavaScript li­brary provider could do the same thing by au­to­mat­i­cal­ly pro­vid­ing a poly­fill for it. If a site doesn't work with­out JavaScript any­way, the prob­lem that it only uses the -we­bkit ven­dor pre­fix­es is aca­d­e­m­ic.

Are we back?

Satur­day 12 Novem­ber 2011 14:38

Looks like my Bri­co­lage in­stall is still run­ning. Bet­ter get some rants up here then ;-)


Wed­nes­day 15 De­cem­ber 2010 00:06

Spent the week in a snowy Achter­hoek.


Satur­day 11 De­cem­ber 2010 17:57

Mo­tion is a piece of soft­ware that does some­thing with a we­b­cam, like when you point a we­b­cam - or sev­er­al we­b­cams - at some place it can be con­fig­ured to de­tect a cer­tain amount of mo­tion in a par­tic­u­lar area of the im­age and then cre­ate a movie or send the im­age some­where. All very com­pli­cat­ed so I just in­stalled it and plugged my we­b­cam in and for­got about it. And when I re­turned from a week's hol­i­day some­where in some di­rec­to­ry it had stored a bunch of im­ages like this:


application browser cool data days different flash game gta html ibook internet linux movie open play playstation run screen server side single site stuff system train user web windows work wrong

Blog Posts (421)

Image Gal­leries

ipen­bug Last.fm pro­file

ipen­bug last.fm pro­file

Fol­low me on Twit­ter

Roland van Ipen­burg on face­book
Lin­ux Regis­tered User #488795
rolipe BOINC com­bined stats


Add to Google

Valid XHTML + RFDa Valid CSS! Hy­phen­at­ed XSL Pow­ered Valid RSS This site was cre­at­ed with Vim Pow­ered by Bri­co­lage! Pow­ered by Post­greSQL! Pow­ered by Apache! Pow­ered by mod­_perl! Pow­ered by Ma­son! Pow­ered by Perl Made on a Mac Pow­ered By Mac OS X XS4ALL This site has been proofed for ac­cu­ra­cy on the VISTAWEB-3000 Creative Com­mons Li­cense
This work by Roland van Ipen­burg is li­censed un­der a Creative Com­mons At­tri­bu­tion-Non­com­mer­cial-Share Alike 3.0 Un­port­ed Li­cense.
Per­mis­sions be­yond the scope of this li­cense may be avail­able at mail­to:ipen­burg@xs4all.nl.