expiration notice

There are a lot of people subscribed to this feed in Google Reader.. I hate to be rude, but I’m going to delete it August 1. If you’re not all just bots and would like to continue seeing these posts, please update your subscription to the new feed address from this blog’s new home. The site is totally live and more or less stable, so it won’t be moving again, or if it does I’ll be able to set up a redirect. If, on the other hand, I annoy you and you’ll be glad not to see my posts in your RSS feeds anymore, you don’t have to do anything cause this is it.

For you Google Reader people, here’s a button:

deprecated

So I’ve been stalking the domain name garann.com for years, waiting for its registration to lapse. I could probably trace this back to never being able to find my name on the souvenir mini license plate racks in gift shops as a kid, but I prefer not to examine it too much more deeply than that. I like having shit with my name on it, the same way my cat likes to rub his head on everything (i.e., these are my THINGS!). Today I happened to notice it was up for sale again and went and snapped it up right quick.

This whole blog’s been moved over to the new site, so this will be the last update here.

10 web revolutionaries

This is sort of a reaction to Mashable’s “10 Founding Fathers of the Web”.. Those guys appear to belong in several very different categories, like someone was just randomly throwing out big names. The comments on that post give a much more accurate picture of people you’d be likely to think of as “founding” the web. Everyone listed helped move the web forward, but the mixture of guys who created fundamental parts of the web’s infrastructure with guys who sort of improved on existing concepts is confusing.

Regardless, thanks for founding the web, dudes. It is a very nice web, and much appreciated. However! This is Independence Day and sitting on the lawn drinking Budweiser and pointing bottle rockets at your neighbors isn’t something you do to celebrate quiet perseverance in service to science and progress. You do it to celebrate revolution and fucking shit up. In the spirit of the latter, these folks are ten of my most favorite web revolutionaries:

1. Joe Burns

In terms of revolution, I see Mr. Burns as a kind of Martin Luther, bringing HTML to the people. Specifically, in my case, bringing it to people who were teenagers and without HTML Goodies, wouldn’t have known where to begin researching the fledgling art of web development. It became the primary resource I pointed other beginners to during my time as a community leader at Geocities. Eventually it stopped being relevant to what I was doing, but I continued recommending it to people just starting out for years after I quit actually using it. There were a lot of sketchy resources at that time, a lot of conflicting information, dogma, and superstition – it wasn’t the most technically advanced guide in the world, but it was more reliable than many and accessible to anyone.

2. Jennifer Ringley

I have to admit I never actually saw JenniCam, so I guess this is all kind of hearsay, but I remember plenty of discussions about it. It was strange and crazy for this woman to set up a webcam in her dorm room. It changed the web socially, but I think it’s also fair to say Ringley and subsequent camgirls played a part in changing it technically. If video on the web hadn’t moved beyond pictures of fish and into voyeurism and pornography, I don’t think we’d be talking about video in HTML5 today. Certainly at some point, but not today.

3. Craig Newmark

In contrast to the oversaturation, the technical complexity, and the questionable motives of most of the web, Craigslist is plain, small, and genuine. Not such a big deal when it started out, but I think its refusal to change with the times is what makes it revolutionary. Sometimes changing with the times is bullshit. While the rest of us throw every damned OAuth connection and -moz-cupholders:5000 we can find all over our websites in hopes of generating more interest than the thousand other sites we’re competing with, Craigslist does one thing very well and continues doing just that one thing, without gimmicks. Ignoring the very minor tweaks along the way, there’s something to be said for that kind of stubbornness. I could post this same thing almost anywhere on Craigslist and more people would see it than will ever read it here. As Facebook overtakes MySpace overtakes Friendster, Craigslist remains constant and eternally popular.

4. Nate Oostendorp

At the time I discovered Everything2, I didn’t know of anything else like it. Livejournal may have been around at that point. Wikipedia most certainly was not. Flickr, the site that bears closest relation as far as I’m concerned, was just a twinkle in some young developer’s eye. A decade later it continues to exist and there’s still nothing like it. It’s similar to Craigslist but also completely opposite. The nature and purpose of E2 changes with each successive wave of moderators, features come and go in slow reaction to technological fashion, and it remains completely fucking obscure and yet a huge part of the lives of a relatively small group of people. Given that what makes it revolutionary is its unceasing anarchy, it seems a little weird to hang it all on one person. On the other hand, I think I’m probably correct in believing E2 was the first site to ever be so fully handed over to its users, and for that he’s a pioneer.

5. Zeldman

Seriously you should probably just take your can of Budweiser and go re-read “To Hell With Bad Browsers”. It’s way more inspiring than this drivel.

6. Dave Shea

I remember using CSS Zen Garden and the ALA article mentioned above as a two-pronged attack against my boss’ policy that we were going to keep marking up our website in tables until armed terrorists broke in and made us stop it. CSS Zen Garden was sort of like Stalin to ALA’s Marx. It’s also one of the most elegant proofs of concept that I’ve ever seen. Not only could this professional design guy style carefully structured markup to look more or less like what a client wanted, tons of other web guys and girls could style exactly the same bare-bones markup to look like any goddamned thing they could imagine. I still think it was a huge fucking deal.

7. Holly Bergevin

I’m resisting the urge to extend the Marxism analogy all the way to its breaking point here. Instead I’ll just ask where we’d be without the Holly Hack? I fear it’s always going to be the case that the dominant web browser is a decade-old version of IE. Without IE hacks, the web would be nowhere.

and 8. John Gallant

And the problem is never just IE. I’ve torn my hair out over all the others, too. PIE made it possible not to give up. Idealism is awesome, but we’re always going to need someone documenting the realities and, in doing so, keeping the pressure on.

9. Crockford

Last week at work I was in an argument about whether we were going to offer a version of a product that didn’t require Javascript. Imagine that five years ago. Imagine even considering not having a noscript alternative then. A hell of a lot of people contributed to this massive shift – some of them mentioned in the Mashable thing – but Crockford stands out to me because he’s promoting all the “good parts”, not just one specific technique or library. I’m not going to go on about it. You know why Crockford’s awesome.

10. Nicole Sullivan

I don’t see anyone better poised to do for CSS what Crockford et al have done for Javascript. And god knows CSS needs the help. Even as the web collectively freaks out over the potential of CSS3, people are coming up with all kinds of crazy ways to avoid actually writing CSS and I’m getting in fights on Facebook about how CSS is fundamentally broken. I’m hopeful that Ms. Sullivan’s work is going to help CSS evolve to suit those of us who already love it (instead of to pacify the h4terz) and to get the respect it deserves.

All pretty subjective, but hey..

Happy Fourth. 🙂

defending terrible things

I’m sure all this has been said before, but it’s a minor obsession of mine. Ignore HTML5 for a second, and all the interesting things happening with Javascript and CSS. I’d like to discuss the kids in leather jackets smoking cigarettes behind the gymnasium of web development: <b> and <i>.

And WordPress is going to make my first point for me. I’m typing this in their WYSIWYG and the buttons for bold and italic are a little b and a little i. When I toggle one on, it becomes /b or /i. And yet the HTML that gets inserted is <strong> or <em>. Why?

Point 1: The bold and italic tags do exactly what the fuck it says on the tin.

If you want something in a division on a page, there’s a tag for that. If you want something to be a heading, there’s a tag for that, too. These tags, like all others, accomplish what they do only through conventions of browser manufacturers, but can nonetheless be relied upon to get you some semblance of what you want even if your CSS should be mysteriously and tragically abducted in the middle of the night. Like the bold and italic tags, they tell you very little about text they contain. But nothing in HTML tells you about the text it contains. It does, however, sort of tell you what it’s going to look like in a webpage and describe the role it will play in the page’s structure.

Point 2: If you want semantic markup, use XML.

XML is a very handy little language that will let you describe your precious digitized text as precisely as you want. You can style it and present it on the web and get exactly the same thing you would from a document full of non-semantic <div>s and <span>s. Or, hey, put even more <span>s in and give them all seventeen class names and call it a microformat. I hope you have a really, really fun time doing that. If, on the other hand, you’re willing to consider that your consumable data and your pretty website need not be the same beast, you could just keep the XML somewhere else and if anyone ever actually wants to scrape all the air dates and titles of the Buffy the Vampire Slayer episodes you recorded on VHS, let ’em just grab that.

Point 3: Why this webpage is shouting at me!!

You know what strong and emphasis refer to? They refer to verbal inflections. You know what most peoples’ web browsers don’t do? Talk to them. You know what would annoy the shit out of me if I were using a screen reader to read a bibliography on the internet? Listening to a goofy-sounding computer voice try to emphasize every single word of Journal of the Study of Obscure and Mostly-in-Latin Canine Diseases Affecting Generally the Respiratory System but Also Sometimes the Lymph Nodes or something. I don’t know that this is still a problem, but the idea is ridiculous in and of itself. Italic does not always mean emphasis, nor does bold always mean MAKE THIS LOUD. Certain conventions of formatting require the use of bold or italics, but actual writing rarely does. If you need to place emphasis on something, you can do that with word choice. (Or anyway I hear it’s possible..)

Point 4: Character count

When I first started doing professional web development, lots of things weren’t digitized. Therefore I spent a lot of time marking things up, enough that I began to have those horrible almost-nightmares where you’re doing the same task over and over and you can’t stop doing it or thinking about it. If semantic markup had been a buzzword back then and every <b> had to be a <span style="font-weight:bold;">, I probably would have gone back to working at Chevron. The bold and italic tags are short. The emphasis tag isn’t bad, but the strong tag is way too long to be a good value per keystroke. This is to say nothing of what you should actually be doing if you want to keep your presentation and your tags altogether separate, using a span with a CSS class describing the content and not merely the fact that you want it extra heavy. I mean, sure, I will always use CSS to bold or italicize something if there’s already a tag around it. Nine times out of ten a bold or italic tag would be inappropriate there anyway as the font weight or style is purely decorative. On the other hand, if something needs to be weighted or styled differently and has no containing HTML element, fuck it, I’m using <b> and <i>. They’re shorter.

Point 5: Dirty tricks

I add <b> and <i> to things I don’t necessarily want bolded or italicized. I do it because they’re some of the shortest elements available and they provide a hook to style child elements in larger repeated widgets with very precise, complex layouts. If I have to wrap every word of text in a tag just to accomplish some goofy layout, I’m using the smallest thing available. Especially if the widget in question is something I’m inserting dynamically and I want to keep it in a string without spaces and still be able to sort of recognize what’s in it without needing four monitors just to view the whole thing at once. Again, if Something Better exists, I always do that first. But there are times when nothing you can do is going to be semantic, screen-reader friendly, or anything you’d want your mother finding out you’d done.

One of the most beautiful things about the web is its imperfections. We don’t write firmware for missile guidance systems, we write applications that let you pretend to steal your friends’ cartoon cows. There are places for flawlessness and obsessive semantic control, but this isn’t one. When you can write elegant code, it’s awesome, and I think most of the time everyone tries to. But it’s important to realize that at the end of the day, this is all kind a series of epic hacks, and sometimes the most sane thing to do is just embrace it.

CSS, live(), and application state

An idea I ended up thinking a lot about as a result of the application rewrite I just did was managing client-based application state with CSS classes. I’ve been making mental lists, trying to figure out how far you could take it and whether it would be useful. I was thinking there was probably some performance caveat or something, but then I read this post on the relative speed of live() and now I’m thinking maybe it’s something worth exploring more.

Using (what used to be) my application as an example, I can see a few possible states..

• Edit mode for the object’s owner
• Display mode for the object’s owner (so, surfacing links to access the edit mode)
• Display mode for non-owners (no edit links)
• Live mode (same as above, but possibly with more data about what the object is doing in whatever context it’s been published or released to)
• Error mode (tracking needed corrections)
• …?

You couldn’t use switching classes alone to manage those if there were roles certain information had to be hidden from – you’d have to take care of that on the server, obviously. And you’d have to check permissions on any type of update, but presumably you’d be doing that anyway.. For my application it would work fine, though. For certain pieces of the application, I implemented a pared-down version and it’s pretty successful.

What I actually tried was really simple. I just applied a CSS class to a container, causing pieces of the interface to be shown and hidden. Event handlers for those elements were attached with jQuery live(), so that as stuff gets added and removed, its event handlers are already (usually) set up and switching states merely reveals or hides the elements that trigger them.

Examples of WTF changing the “state”/container class actually does..

• Show/hide edit buttons
• Change an element’s event handler
• Enable form elements
• Change layout to reveal spaces where new elements can be added
• Hide error messages
• Disable iframes (I need them – don’t judge)
• Determine whether areas that contain actions that aren’t automatically surfaced react to hovers
• Reveal state-specific information

Especially with regard to changing event handlers, I’m assuming jQuery live() was designed with this use case in mind? What I mean is like:


$("div.editable a.editItem").live("click",function() {
showSomeEditor();
});
$("div.error a.editItem").live("click",function() {
alert("Nice try. Fix whatever you screwed up, then we'll talk.");
});


I think this is just handy as hell, but every time I try to google information about how other people might be doing the same thing, I come up with nothing. So in the absence of any best practices or warnings, I’m still playing around with it on my own. I think it’s cool.

bra of uncertainty

Seems I may never know how the jTemplates experiment would have turned out. Same with the WYMeditor experiment, which I haven’t mentioned here, but trust me, has been lengthy. I’ve got an amount of time somewhere between zero days and two months to get my ducks in a row and make whatever further enhancements I want to make before moving on to something different. The team I’m currently on will continue with the same product for a while, but without a UI person. Considering that a large portion of our product is the client-based application I just rewrote, that means that in a substantial way, the product is entering maintenance mode.

The new project is cool, though. Last week I got handed a list of things to prototype, and I love prototyping. Imagining the best way you can think of to have a user accomplish something and then architecting the solution around writing the sexiest possible code is the best part of development – frontend or otherwise. Once you add the business’ opinions and the edge cases it can get to be a slog, but that comes later. I’m looking forward to making perfect little creations that don’t have to know a damned thing about SEC regulations.

But, there’s uncertainty.. My team is the only team with a UI Engineer that won’t be working on this new initiative. My other peers are staying with the projects they (or their positions) have worked on for over a year. They know their roles within their teams and how to work with their backend and QA people. I’m a little adrift, pulled into this as an extra body. I’ve been on the same team for over a year as well, and though I think they’re a little dismissive of the frontend, I’m comfortable with them.

They say you dress for the job you want, and they say clothes make the man or woman. It’s not bullshit, even in an industry where our fashion sense is just about the last thing we’re known for. Dressing well makes you feel more confident. If you’re a woman, you can’t overstate the role a decent bra plays in dressing well (or the role a shitty bra plays in making you look and feel like a broke-ass college student again). I’m told it’s the same for dudes and their shorts. So I feel excited but also freaked out about my job right now, I need the confidence to try and make a place for myself on the new project, and guess who’s going to Nordstrom this weekend?

I started buying good bras – big girl bras, the kind that don’t come off the clearance rack at Target – shortly after getting this job. Over the past ~2 years, I think I’ve become a much better developer. As good foundations go, buying decent underwear ranks right up there with learning C.

the jTemplates experiment

So it took a heck of a long time between the first proofs of concept and actually going live, but I rewrote a pretty complex client-based web application to use jTemplates. It started out with 12k+ lines of code (the numbers in that previous post don’t reflect various utility files, just the two main ones) and when I totaled it up on Monday, the new count is 3834. I’d been estimating it at about 5k. Less than 4k is better than I’d hoped. Even more impressive is that the previous figure did not include all the HTML templates that provided the pages their basic structure – the 3834 includes the jTemplates (since they’re all Javascript), meaning that’s it.

Summary: I am now a fanatical jTemplates convert.

However, I had a conversation over the weekend that’s got me questioning whether I’m sacrificing too much performance for maintainability. I won’t pretend the new application runs a lot faster than the old one. Its issues are different – this takes a long time to load, whereas the old one leaked memory over time – but it’s not blazing fast by any means. Part of the problem is the immense data object that the jTemplates process. All the information about a specific object is passed down at once when the page first loads, and then has to be pulled down again whenever the user switches between the four tabs in the application because of some irritating issues with the web services (the only thing they return is error messages, so if a new element is added, for example, it takes an additional XHR to find its ID) and data getting stale. I’m wondering, if I’m pulling down all this data anyway, if there’s an argument for putting jTemplates on the server and just getting the markup pre-loaded with the data points.

Of course, this is a .NET environment where I have pretty much no control over the backend, so it’s not likely I’ll get to try jTemplates on the server. I can’t find evidence that anyone’s ever tried that, so who knows, maybe it’s impossible.. Instead I’m going through all my notes from txjs and applying every performance enhancement I can find to any code I’ve touched over the past couple days. It’s not giving me an improvement so far, and I’m beginning to feel this is a design problem. If there were a way to split up the data being pulled down and lazy load interface elements, I think things would speed up a lot. Sadly, there’s (currently) not.

I’m left with 4k lines of Javascript I’m very pleased with having shrunk and no clear path forward, which fucking sucks. But the application is clearer and more well organized. I guess the experiment continues..

txjs

I’ve already helloed into the box about this, but I am still sort of having some issues getting over it. Hlysht, Texas Javascript was amazing. Pretty much everything I saw was just crazy awesome. I learned things, which was a problem I had with most of the technical talks I went to at SXSWi (note that sx didn’t inspire me to come back and drool about it on my stupid never-updated blog). There was exactly one talk that didn’t teach me something new or make an argument I hadn’t heard before, and even that would have been mind-blowing if I hadn’t been working on the specific project I’ve been working on for the past year. I wish I could do this shit every weekend.

My favorite talks were Crockford’s, John Resig’s, Nicole Sullivan’s, and Paul Irish’s. I’d link to them, but as far as I know they’re not online yet.. I plan to link to them, though, because I want to revisit every single one of them (and most of the others, honestly).

It really never occurred to me until yesterday how jaded I am about what I do. It’s like I left my brain back in the 90s, when front end development was something dirty and every other kind of developer thought you were a moron if you messed around with webpages (something I still contend is bullshit, because it’s a lot easier just getting something to compile and run on a server that’s completely under your control than to build applications that have to work in places you’ve never even imagined out of what in the past amounted to packing peanuts and duct tape). While I’ve been walking around with a giant chip on my shoulder after having been talked down to one too many times, Javascript has been transforming into something thoroughly badass. I’ve been aware of this, but never actually noticed, if that makes any sense. Even if the frontend still doesn’t get the respect it deserves in certain circles, um, we have geniuses.

The one thing I regret about yesterday was not trying to talk to more of those geniuses. For reasons I can’t really explain, I was completely terrified of them, even though the ones I did manage to speak to were totally nice and awesome. Ok, that’s not 100% true, as I was rude (stupidity, not malice) to one of the speakers and pissed him off. So two regrets, the other being that I didn’t go to any of the server side Javascript talks. I got my ass schooled at the Driskell and am now finally convinced that this is something I should find a way to implement as soon as possible.

A final to-do item is to try and contribute some of the plugins and fixes I’ve made for my own use to the open source projects they correspond to. I feel like there’s another world where the Javascript is more exciting by orders of magnitude, and it’s kind of chickenshit to hang out around the perimeter implementing things other people have written instead of trying to actually participate. On the whole, I feel genuinely inspired in a way I haven’t since I started doing layouts with CSS instead of tables. There’s some really cool shit going on and I can’t believe I’m just now realizing it.

jTemplates: easy answers to dumb questions

I’ve been trying to use jTemplates for a fairly complex interface that displays quite a bit of data. The documentation on their site is pretty minimal, so I’ve come up with a lot of what may be very dumb questions that I’ve been forced to answer myself, by trial and error (how tacky).

I figured I would post these in hopes of saving someone else some wondering:

1. Can you treat an array like an array once it’s part of your template data?

Yep. In my data, Columns is an array, and this code works great:

<table class="{#if $T.Columns.length == 1}onecolumn{#/if}">
{#if $T.Columns[0].Label != null}
<thead>
...


2. Does whitespace matter?

Apparently not – see above.

3. How do you refer to a property of a parent object from a child template?

I couldn’t figure this out, so I worked around it by adding the property I needed to the root object I was passing into the child. I ended up doing this in a function because neither of the two delimiters jTemplates uses – {} and {#} – can be used for straight assignment as far as I could tell.

{#foreach $T.Columns as c_f}
{#include COLUMN_CELL root=addFieldType($T.c_f,$T.FieldType)}
{#/for}
...
function addFieldType(obj, ft) {
obj.FieldType = ft;
return obj;
}


4. Can I put a property of the current object into my call to a child template?

Seems like no. What I really wanted to do instead of the code above was this, which does not work:

{#foreach $T.Columns as c_f}
{#include COLUMN_CELL[$T.FieldType] root=$T.c_f}
{#/for}
...
{#template COLUMN_CELL[0]}
<td><input type="radio" disabled="disabled"/></td>
{#/template COLUMN_CELL[0]}
{#template COLUMN_CELL[1]}
<td><input type="checkbox" disabled="disabled"/></td>
{#/template COLUMN_CELL[1]}


For now, all I have is those four items.. I’m sure I’ll come up with more as I get into the hard parts.

MVC in Javascript

Nothing against Ajaxian, but I don’t usually look to them for pithy wisdom – mostly I look to them for clever jQuery plugins and stuff. However, the paragraph at the end of this post on MVC for Javascript sums up my feelings pretty well:

If you think that view source / semantic markup is a great feature of the Web platform, then this kind of world is a touch worrying, but major apps have been doing this for years.

Once I worked on this project with a lot of contractors from IBM, and they were the ones defining the architecture. They had a very literal approach to MVC. As in, every single link went through a controller. Home link? Ask the controller. About Us link? Ask the controller. I’ve implemented MVC in C# (back before they had the framework for it, which from what I gather is pretty cool) and had it be useful, don’t get me wrong.

MVC to me is one of those FUD problems, though. Even the experts can’t quite agree on how it should be implemented. Reminds me of the not-Agile-enough or not-semantic-enough debates that seem to eat up a lot of valuable time that would be better spent coding. This is why I want MVC to keep its white-gloved, mechanically precise fingers off my Javascript.

As far as I’m concerned, there is no good pattern except the one that is obvious. The one that makes you smack your head, exclaiming, “Of course!” because it is perfectly suited to your problem and its application is absolutely clear. I think of the Factory pattern as a good example. What it does and why you need it aren’t up for debate. MVC, on the other hand, is subject to interpretation once you try to apply it to environments it didn’t grow up in. Javascript is a language for manipulating CSS and HTML. Manipulating the View. There is no single, clear answer to the question of how to apply MVC to Javascript because MVC in Javascript doesn’t answer a need. Forgive me because – again – MVC has been very useful to me in the past (on the backend), but in this context MVC is nothing more than a buzzword.