Archive for the ‘development’ Category

Mobile Web App 2: Picking a UI Framework… or Not

Tuesday, September 14th, 2010

Now that I know roughly what I want to build in my app, it’s time to pick a UI framework.

Evaluating the libraries

I looked at 3 javascript frameworks that are geared toward mobile/touch development: YUI 3.2, Sencha Touch, and jQuery Mobile.

YUI 3.2

Pros: I use YUI 3 a lot at my day job, and in general I like it a lot. It’s a mature, capable library with some very smart folks working on it. They haven’t historically focused on mobile/touch, but in this recent release they added touch event support, gesture support, and support for css3 transitions. Also, the library is very modular, so it would be easy to keep the filesize small.

Cons: Has only one mobile UI widget – the ScrollView. And when I loaded up the ScrollView on my Droid Incredible (running Froyo), it didn’t work. I found this very disappointing, since Android would be a major target for my app.

They have no publicly available browser support policy for mobile devices, although I’ve been told they’re working on one.

Conclusion: It’s not ready yet, but has the potential to become a really good mobile library.

Sencha Touch

Pros: They’ve taken all of the visual elements of an iPhone app, and recreated them in javascript.

Cons: They’ve taken all of the visual elements of an iPhone app, and recreated them in javascript.

Ok, but seriously – Sencha is a very slick-looking framework. They have a full complement of UI widgets, and they look great, if a bit iPhone-specific for my tastes. All of the demos worked beautifully on my iPod Touch running iOS4.

But their stated browser support is pretty narrow: just iOS and Android, and some of their demos were buggy to non-functional on my Droid. Furthermore, there’s no possibility of progressive enhancement – the page is assembled completely from javascript, so it’s all or nothing. Either the user is on a device that Sencha supports, or they’re out of luck.

Conclusion: It’s not ready yet. Furthermore, it doesn’t really provide the breadth of support that I’m looking for. But iPhone developers will love it because it provides a familiar model, and it doubles the number of platforms they can target.

jQuery Mobile

Pros: Because it’s jQuery, there’s a huge developer community built in. Claims to support a huge variety of different browsers and devices. Full set of proposed UI widgets that look great.

Cons: Not actually released yet, so who knows if it will live up to the claims. Plus, jQuery is less modular than YUI, so I’m concerned about the size.

Conclusion: It’s not ready yet, but has the potential to become a really good mobile library.

After looking at these three, I’ve come to the conclusion that there’s no javascript library in existence right now that does exactly what I want. A lot of smart people are working on a lot of great stuff, and it’s all really early in development, and it’s just not ready.

Having come to this conclusion, I started to ask myself whether I really need a javascript library at all. On a desktop app it doesn’t matter as much – a few wasted kilobytes are no big deal over a high-speed connection, especially when the most popular libraries are likely to be cached. And the niceties that they provide make development a lot more fun.

But I think when you get to mobile the equation changes, for two reasons: browsers are more similar, and waste is much less tolerable.

A big part of the value that javascript libraries provide is normalizing between IE and everyone else. But there’s no IE in the mobile realm. (Well, there is, but it’s small enough that I can happily ignore its existence, and plan to continue doing so.) So it becomes a lot less annoying to work in plain javascript. There are still a lot of browser differences, but at least you don’t have to write everything twice.

But even more importantly: when you’re on a slow, spotty connection and every download drains your battery, any amount of waste becomes intolerable. And there’s waste when you use any javascript library – even with a modular one like YUI3, you’re never using every single line of code that you pull down.

If you want people to keep using your app, speed is the second most important thing you must have. (The most important thing, of course, is that it does something useful or entertaining.)

So, my conclusion is: none of the above. I’m going to develop BrewTracker (our working name) without relying on any javascript library or UI framework. (If I really get annoyed by this I might turn to a very bare-bones library like XUI, but I’m hoping I won’t need to at all.)

I’m going to attempt to be minimal and efficient in my javascript, and truly follow a strategy of progressive enhancement. I’m going to avoid making heroic efforts – like recreating momentum scrolling in javascript – for small design wins, like the ability to have a fixed-position bottom nav. And I’m prioritizing broad accessibility and usability over flash and flair. After all, everyone likes beer – even people who dare to use a Palm or a Blackberry!

Coming up next: I try to persuade Andrew and Dom to guest-blog about BrewTracker’s design.

Mobile Web App 1: Wireframing

Sunday, August 22nd, 2010

In my last post, I introduced the mobile app project that I’m going to undertake. Today I took the first step and sketched out the UI of my app. From this, I can get an idea of the number of different screens (don’t call them pages!) and how they connect, as well as the different UI elements that I will need to either get from a library or create on my own.

The home screen

This is what you will see when you open the app or visit the site, and are already logged in. (The whole login/account system is something that I haven’t looked at yet. I just know that I want it to be super-simple.)

It presents the four main things that you can do: browse your beer notes, add a new note, search for a beer, or look at a random beer from the database.

(Note that the title is wrong in these sketches. I was going to call the app Beer.Me until I realized that’s already taken.)

home screen

Adding a new beer

This needs to be super-simple, because when you’re hanging out with people or conversing, you don’t want to spend a ton of time typing into your phone. Key design principle: Don’t make your user look lame!

Because of that, the ability to grab a snapshot of the label using your camera phone is key. I could envision myself doing that to remember a beer that I liked, and then filling in the rest of the details later. (This implies that we need a way to remind the user of incomplete notes, and prompt her to complete them. This may or may not be another screen.)

I avoided the typical 5-point star rating scale, because I think it’s often overkill. I’m not sure that my opinions on beer are fine-grained enough to support five separate divisions of feeling; I tend to think of things as liked or disliked, with a few standouts that I particularly love. I threw in a “hate” button too, mainly for symmetry’s sake, or to remind yourself of something terrible that you never want to try again.

add a new note

Browsing your notes

Just as important as adding a new note, is the ability to go back and easily look over the notes that you’ve created.

The browse screen is fairly simple: it offers a segmented control with 4 different ways of organizing your notes, and below that a simple list. Touching a beer on the list will slide over to that beer’s note, in the standard iPhone-ish way.

Here’s a sketch of the screen organized by name:
browse by name

And here’s an example organized by the name of the brewery:
browse by brewery name

The two other views would look similar to this one, with subheadings on the list for category or for the date the note was entered, and entries alphabetically within that.

Viewing your own notes

From the browse list or from search, you would have the ability to view a note that you had previously made. This would include your information, of course, and also some global stats about that beer, if anyone else had noted it as well.

The global stats bar would double as a filter of the other people’s notes below it. You could tap on any particular rating and the section would filter to only show notes by people who had assigned that rating.

one of your notes

Viewing other beers

Of course, you might want to get information about a beer that you yourself haven’t tried yet. This part would only work if lots of people were actually using the app, which is why I see it as secondary. Nonetheless, by searching for a particular beer or by hitting the “Random Beer” button, you should be able to review the notes for any beer in the database.

This is what that screen would look like: it’s basically the same as the previous one, without the whole “your notes” section and with the addition of an info thingy telling who first noted this beer. (The hope is that including this would motivate people to note more beers, in the hope of being the first person to do so.)

not one of your notes

And there you have it. As noted, there are a few things missing, like a search results screen and any kind of account/profile management stuff. But I think that these are the core items that give me enough information to start planning out the app.

Coming up next: Picking a UI framework, or not.

Building a mobile web app, start to finish

Sunday, August 22nd, 2010

Given the way I keep falling into mobile work, I’m apparently destined to be a mobile web developer. (If you know me, you know why this is funny — I hate talking on the phone, and avoid it at every opportunity.)

Because of this, I’ve decided that I need more practice at creating cross-platform, web-based apps. I have some experience with the iPhone SDK from a project earlier this year, but I’ve come to believe that web-based and cross-platform is the ideal way to go.

I’ve decided to start a project to create a mobile web app from start to finish, and I’m going to blog about it each step of the way. I’ll talk about the various decisions that I face, like choosing (or not choosing) a javascript framework, and the challenges that I will no doubt run into.

The app that I’m going to make is based on something that I actually want for myself, which makes it easy to design. It’ll be an app basically geared toward beer snobs (or connoisseurs, if you’re being polite), that lets you keep track of beers that you’ve tried, take notes on them, rate them, and see notes and ratings from other people. There may be apps around like this already; I don’t really care. I’m not in it to make money, just to gain experience with mobile app development and create something that I personally like.

I’m tentatively calling the app BeerNotes. Over the next week or two, I’ll be working on the design of the app and making the various technical choices required to get started. After that, I’ll move into talking about implementation. So, come back to see how it goes!

YUI3 Hiddenhancements: Y.cached

Wednesday, August 18th, 2010

Ok, first things first. I totally stole the word “hiddenhancements” from the yayquery guys. If you’re not familiar with them, go and watch a show and then get back to me.

Back? Okay. (Enjoy having their theme song stuck in your head, btw.)

So lately I’ve been doing a LOT of work with YUI 3, which is totally rockin’, and I’m starting to realize that there’s all of this Really Cool Stuff hidden away in YUI Core and other parts of their API that isn’t really mentioned, well, hardly anywhere. So I’m going to be writing some of this stuff up.

(Of course, everything IS documented in the API docs, or at least mentioned. is your friend.)

Cache me if you can

So, Y.cached. What does it do? According to the API docs, it “Returns a wrapper for a function which caches the return value of that function, keyed off of the combined argument values.”

In other words, think of it as a filing system attached to your function.

If you pass in some arguments to a function wrapped in Y.cached, YUI will go off and check whether there’s a mailbox labeled with that set of arguments. If there is, it’ll pull out the stuff that’s already stored there and return it, without ever going into your function itself. If the value isn’t stored, YUI will pass your args through to the function, intercept the result when it returns, and store it away in a neatly labeled mailbox, so the NEXT time you call the function it can retrieve it.

So you can see how this potentially could help you skip a lot of duplicate work, if you’re calling the same function with the same values over and over again.

Of course, this doesn’t help you much if your function has side effects, or in other words, does anything other than process some args and return a value. (It also can’t help if you need randomness in your results.) But there’s a whole set of operations that do exactly that: process some args and return a value in a predictable way. For those operations, Y.cached can really speed up your code.

(You can pass in a third argument that will cause Y.cached to blow away the cache and call the function again, but if you’re using that a lot then you’re defeating the purpose.)

If you want to impress your tech lead or something, you can throw around the term memoization when referring to this technique. Then they’ll be all like, whoa this person knows his/her bizness! And they’ll think you’re smart, and then you’ll get a raise.*

*Not guaranteed to actually occur.

An example from YUI

Here’s an example from YUI’s event-target code.

//In this line, they're caching a function that does some string replacement with a regular expression
//With this caching, if you pass in the same string again, the regex won't have to be evaluated twice.
_wildType = Y.cached(function(type) {
        return type.replace(/(.*)(:)(.*)/, "*$2$3");

// .... bunch of other stuff......
// ..... and then later on they call the function just like a normal function.
if (type.indexOf(PREFIX_DELIMITER) > -1) {
            type = _wildType(type);

And that’s basically all there is to it!

My current use case

Right now I am working on a widget that does client-side filtering of tables. This widget needs to be fairly generic, so one of the things I do is let people pass in a function that specifies how to filter for a particular command. This function takes a value and returns a boolean, in a way that should always be predictable. As soon as I saw this, I thought to myself, “Boom! Let’s use some totally sweet memoization to speed up this code!”*

Embarassingly, I don’t have actual numbers to show its effect. I might try to gather some tomorrow. But it made a notable difference in the filters’ responsiveness, especially in mega-slow IE7.

And it’s so easy to use, it’s like why not? Go forth and memoize!

* What? I get excited about things like this.

Fireflies – My #js1k Contest Entry

Sunday, August 15th, 2010

Most javascript developers have probably heard of the js1k demo contest by now. (You can check out all of the entries here.)

Here’s my entry, just under the wire at 1022 bytes. (The right edge is a bit cut off, because of my blog’s layout – sorry.) It was only possible with the help of the Closure Compiler from Google, which totally rocks my world.

I’ve decided it looks a bit like two swarms of fireflies chasing each other around. It’s adapted from the “Boids” flocking algorithm, which is applied to both the individual bugs and also to the swarms themselves to make them chase each other. (I found this explanation particularly helpful.)

Anyways, I doubt I’ll place because there are a lot of really amazing entries, but I had a lot of fun building this. It was a bit of a flashback to my old computer graphics days, in college.

My Biggest Fear as a Developer…

Sunday, August 1st, 2010

…is that 5 years from now, some other developer will be cursing my name for something that I did. (They may not actually know my name, but they’ll be cursing what they imagine it is.)

That something I built, or some decision that I made, went on to become set in stone and now is making their life more difficult. That something wrongly optimized, or just poorly done, is now actively hindering future progress.

Of course, none of us can predict the future, so this is basically unavoidable. Conditions always change, so what I’m optimizing for now is almost guaranteed to become the wrong thing at some point down the road.

So developers are always going to be cursing my name, at least a little bit. But how can we try to reduce this?

1. Seek out as many perspectives as possible.

When you’re doing something that could have big implications down the road, make an effort to get lots of feedback from people from different backgrounds and perspectives. (And then listen to their criticism and be willing to change your ideas – which can be difficult, I know.) Every person brings their own angle to a problem, and each angle can see different holes and cracks.

You need a panel of trusted experts who you can call on regularly, to vet ideas and tell you when you’re being dumb.

It helps to find people who will:
a) not play politics with your ideas, but evaluate them strictly on merit,
b) keep it constructive, and
c) give you honest criticism without holding back.

Chances are if you can get a whole group of designers and developers to agree that something is okay, it’ll stand the test of time a whole lot better.

2. Don’t overdesign.

There’s this great William Gibson quote that I absolutely love:

“That which is overdesigned, too highly specific, anticipates outcome; the anticipation of outcome guarantees, if not failure, the absence of grace.”

Design for grace. Make the bare minimum number of decisions required to meet the current need, and make those decisions easy to change. Leave daylight between every part of your system and every other.

There are a million different patterns around to help you do that. Use them, but don’t overuse them, and remember also that a lot of design patterns introduce complexity.

In the tradeoff between simplicity and flexibility, lean toward simplicity, so that other people can understand your system. Don’t try to anticipate future needs – you’ll get it wrong. Instead, create a simple and solid foundation so that future needs can be met by future developers.

Another quote that I love, from Antoine de Saint-Exupéry:

“Perfection is achieved, not when there is nothing left to add, but when there is nothing left to take away.”

3. Draw on principles from information architecture and usability to make your system sensible.

As developers, we’re lucky because we design for other developers. In a very real sense we are our users. But we’re still never exactly our users, and the view of a project when you’re eyeballs-deep in code is different from that of someone faced with learning to use a system from scratch.

Consider the basic principles of usability as they apply to code design. Develop sensible hierarchies. Use agreed-upon domain terminology when naming methods and variables. Design your API, don’t just let it evolve blindly. And yes, this is where the dreaded task of writing documentation comes in as well.

(I may be the only developer in the world who actually enjoys creating documentation. But I like writing and teaching and psychology, and creating good documentation draws on all of these. I find it an interesting challenge.)

I think that learning a few basics of IA, design, and usability will make anyone a better software architect, because it trains you to effectively consider another person’s point of view.

In the spirit of #1, what am I wrong about? What other things can we do to help our code adapt to future change?

Programming While Female: 13 Thoughts

Tuesday, July 27th, 2010

This topic seems to get into the air about once a year, and I normally avoid it like the plague. Most of the time it seems to result in pointless hand-wringing and, if anything, harms us tech women by calling us out. But stubornella’s excellent blog post stirred up my thoughts, and the relative civility of her commenters gave me hope. Also this latest brouhaha started around jsconf, which I attended myself, and which helped shape my own thoughts on the topic.

So these are a bunch of scattered thoughts, that together are my attempt to honestly describe my own experience.

1. A little story

I didn’t start programming until I was in high school. I was never even aware of programming until I took my first class, I think it was my sophomore year. (We wrote Hangman in Pascal.) Honestly, it just never crossed my mind.

At that point, I was already behind. Because real programmers start when they’re 8, don’t they? Real programmers get started seemingly at birth, and know what they’re meant to do right away – there aren’t really other options. (I’m speaking in stereotypes, of course, but they are stereotypes that the field itself promotes.)

When I started college I realized how far behind I was. I did well in my first couple of classes, but I wasn’t the best. And other things seemed so much easier – writing was easier, and art was, and all of these other things. So I didn’t stop programming, but I switched out of CS into InfoScience, and made up a Digital Art major, and did all of this other stuff. (Not sticking with CS is my biggest college regret.)

When I graduated I decided to become a designer. After all I wanted to work in the tech field, but I “wasn’t smart enough to be a programmer”, and with my love of art, design seemed like a good compromise. Besides, that’s what nerdy chicks do – they become designers. Right?

I was fortunate enough to explore the design and UX field at a company where I could easily switch back to programming. And I did, once I realized that design wasn’t for me.

I learned some valuable things from this experience. But how much better would I be at programming now if I hadn’t taken that 2-year detour? How much further ahead would I be if I had had the self-confidence to stick with CS, and the understanding that I could actually catch up, if I just worked really hard?

This has to do with gender because it has to do with stereotypes, and with how I measured myself against those stereotypes and found myself lacking. And you’d think I would have learned from it, but I still do the exact same thing.

2. Ambient sexism

I have never had anyone personally treat me rudely because of my gender. I’ve never been the target of serious disrespect, or been denied an opportunity as far as I know. (I’ve had dudes be really awkward or try to hit on me, but whatever. I can deal with that.)

This is a totally awesome thing! It’s a big change from when my mother was an engineer in the 70s. (She has some stories that you might not believe, about behavior that was just accepted back then.) Progress has happened, and we nerdy chicks owe that generation a lot.

It also makes this kind of difficult or confusing to talk about. Most of the programmer guys that I know are totally awesome people, and would never think of themselves as sexist. And yet there’s all of this general objectification and disrespect that floats around in programming culture and makes it really hard to be female in certain venues. Call it ambient sexism if you will.

A lot of that stuff comes from people who would probably be perfectly nice to me as an individual. How do these two things reconcile?

3. Yes, you are.

“Oh, we’re not talking about you” is never a valid excuse.

4. Get to know me, I dare you.

I find that as soon as I get the chance to actually work with someone, gender instantly becomes not an issue. As soon as I get the chance to show what I can do, to get into technical topics, to talk geek with someone, then all of the awkwardness and misbelonging disappears. They stop seeing me as a woman and start seeing me as a programmer, and then things are fine.

(The tricky thing is that I’m actually both.)

5. female X awkward = even more awkward!

I’m a great big introvert, as many programmers tend to be. I’m also shy – not cripplingly so, but it still takes a lot of energy and mental preparation to face a big group of people that I don’t know.

Gender is not the root of this problem, but it serves as a magnifying factor. When I’m the only woman in the room it makes it even harder to connect, harder to overcome my natural shyness, harder to find a point of entry to the conversation. It serves as an isolating factor, and makes the barriers that already exist that much higher.

6. I <3 nerds

Talking to smart programmers is one of my favorite things in the world. Talking to smart female programmers is even better, because they tend to be “my type of folks”. But I’ll geek out with anyone – as long as I don’t feel too intimidated by them.

7. Learning French

You learn how to get by, in this man’s world. You learn to make yourself bigger, to consciously take up more space, to pitch your voice lower and louder to be heard. You learn how to dress to minimize staring, and when to choose a t-shirt over a blouse. You learn what topics to steer away from in conversation, and which threads on websites to never ever click. You learn to fit in, to minimize the differences that would keep you separate, to adapt to the common culture. It’s like learning to speak French. You learn, or you leave.

People learn and live in other languages every day; but native speakers will always have the advantage.

(Sometimes two cultures collide and create a new language, a creole, that contains concepts from both of its parents. I want to know, how do we go there?)

8. Community

There aren’t too many place where I really fit in, so when I find one I tend to become attached. Because of this, I’m completely sympathetic to guys who have found a community and a home within programming culture, and who want to preserve and defend that culture.

I can understand how it might seem unfair and threatening when people talk about wanting to change that culture, like in that famous study about geeky environments and tech appeal. Because they value that culture the way it is right now; it’s brought good things to their lives and they don’t want that to be lost. That makes perfect sense to me.

But dammit, I’m here too, and I also want community!

There has to be a way to do both – to extend the culture, without replacing core functionality.

9. It’s not about the dick jokes.

I actually have a pretty coarse sense of humor. So I’m fine with the dick jokes, seriously. I’ll #twss with the best of them – just check my Twitter feed. I think my sense of humor is pretty standard for the field.

Except. Except it all changes when I’m already feeling unsafe and isolated. When I’m feeling in a hostile environment where I have to be on my guard. Then the joke that I might find hilarious under better circumstances suddenly starts to feel like a threat – just another reminder of how much I don’t fit in.

It’s not about the dick jokes, it’s about the overall atmosphere.

10. The relevant parameters

I love programming. It’s not just what I do, it’s What I Do. Nothing else gets me into a state of flow so easily and so quickly. I love it for itself: for the joy of unraveling a complex system and seeing it all take shape in your head; for the love of creating something that’s minimal and effective and Right, with nothing extra added and nothing left to take away; for the satisfaction of making something with my own hands that other people will use, that improve their lives in some minor little way. (The fact that it makes me money is a nice side effect.)

None of this has anything to do with gender. What does have to do with gender is all of the auxiliary stuff, all of those human and social things that turn out to be so important in careers.

So far the first thing has outweighed the second, and so I stay. But I can see how that calculation might be different for someone else.

I can see how easy it might seem to go and find someplace friendlier, where it’s less of a struggle just to be.

11. Hills

There are two runners. One is running on perfectly level ground, and the other is struggling up a big hill. They both might get to the same place eventually, but which one is going to have the easier and more pleasant time?

Being female in the tech industry is that hill.

(And yet. Runners run hills to get faster, don’t they?)

12. Hard words for a hard problem

So maybe you have to work twice as hard to be accepted. Guess what? Go out and work three times as hard.

Do you have to be twice as good to be heard? Be four times as good, and be impossible to ignore.

Feel like you have to know twice as much? Learn five times as much, and then teach others.

Be constantly learning. Work your ass off. Put in your 10000 hours, and then put in some more. Make your skin thicker, and just go on.

Yeah, it can seem unfair. Guess what? Life’s unfair. The only way forward is to suck it up and go make some awesome stuff.

You can let this make you miserable, or you can let it make you better.

(I’m talking to myself here.)

13. That’s what she said.

Yes. Yes, it is.

The Boundaries of Accessibility

Monday, May 10th, 2010

Sites and apps

During discussions about accessibility, I always wonder whether accessibility goals should be different for different types of web projects. Are there cases where accessibility is less important? And if so, what are the relevant differences that make it that way?

“The web should be accessible” is an easy blanket statement, but the web is very diverse. Many sites and applications exist that aren’t accessible in various ways, but are still useful and popular. Are we to say that these sites should not exist at all, and everyone else misses out? On the other hand, people have a right to get the information they need and perform the tasks they need to perform. How do you balance these two things?

For websites, whose primary purpose is conveying information, it’s no question to me that the site should be accessible. First off, most sites that exist to convey information want it to be widely seen; accessibility is in their own best interest. These also tend to be the sites where accessibility is easiest and can be achieved by following simple best practices. There may be some flashy ajax stuff going on, but it tends to be window dressing. At the worst case you might have to provide textual alternatives to rich media like videos or Flash.

But there’s another category that I think is much more of a grey area, which I’ll call web apps. It’s tough to categorize web apps, so I’m going to take the lazy way out and say that they are the complement set of the above category, containing any site whose primary purpose is not to convey information. So if the app exists to let people create something, or to play a game, or to do something complicated with data, it may be reasonable for the app’s creators to set the bar higher in terms of what is required to use that app. This may mean requiring javascript or the use of a mouse, or the ability to view visual images, or even specific browser features. (You won’t be using Bespin in IE, for example.)

Another way to look at it: Importance and relevance

Anything that’s both important and relevant to a large number of people — such as job applications, reference information, and government agencies’ sites — should always be widely accessible in as many ways possible.

If it’s important but not widely relevant, consider your target population and gear support towards their specific needs.

If it’s widely relevant but not important to people’s lives, like for example many browser-based games, prioritize accessibility based on a cost-benefit analysis of how many people you’d like to reach.

If it’s neither important nor widely relevant, go nuts; knock yourself out with crazy features.

I feel like this could be somewhat controversial; what do you think? Should there be a difference in how accessibility is prioritized for different types of projects on the web?

The Browser Breakdown

Wednesday, April 28th, 2010

The growth of the mobile web and touch screens has created more browser diversity than ever before. I think it’s useful to categorize browsers into four major categories, along the axes of screen size and input type.

chart of browsers by screen size and mouse vs touch

Probably the most growth is going to come in the large-screen touch category (mainly because it’s starting from the lowest place overall). If anything, I would expect the small-screen mouse input category (i.e. Blackberries) to decrease — but not to disappear entirely, because businessmen sure do love their physical keyboards.

Making web apps that work with minimal adaptation across all four quadrants is the challenge. (And you thought dealing with different screen resolutions was hard?)

3 Reasons to Care About Server-Side Javascript

Wednesday, April 21st, 2010


Server-side javascript has been a hot topic for awhile now, especially since node.js was announced. But after reading about it here and there, a big part that I felt I was missing was the “why”.

I mean, for those of us who really enjoy javascript (which I do), enough said. Javascript on the server? Hell yes!

I realize, though, that most of the world doesn’t share my love of this particular programming language. :) So, while at jsconf this past weekend, I tried to collect some reasons why everyone should consider javascript on the server.

1. It lets you write things once instead of twice.

The more logic that you’re running on the client-side, the more code you have to write twice: once in your server-side language of choice, and once again in javascript. The classic example here is validation code. You want to validate on the client-side for a good user experience, but you have to validate on the server for security reasons. As a result, you have two whole different sets of validation rules to be written, updated, and maintained over time.

Now wouldn’t it be great if that could be just one piece of code? You’d cut your codebase in half, and make maintenance a lot easier.

2. It could make progressive enhancement easier.

Server-side javascript has the potential to make progressive enhancement a lot easier, by requiring you to do less special planning for it. With a hijax-type approach, which seems to be the current best practice for supporting non-scriptie users, you have to create your site first without javascript, and only then add all of the dynamic stuff in.

In a world of limited budgets and tight deadlines, this may seem like a lot of extra work to support a very small number of users. But with server-side javascript, there’s the potential that for those users, you could just run the javascript on the server-side instead and return the page in its new state.

I’ll be honest, this would probably be a pretty slow experience with a lot of extra page reloads, but it may still be better than the unusable state of many current sites with javascript turned off. (There was a fab talk at jsconf by Philly’s own Jenn Lukas on the sad state of no-script support on major sites.) At least this way people could get what they to wanted, even if the experience was slow.

This isn’t a topic I’ve heard discussed very much yet, but if there was a way to make progressive enhancement basically automatic, that could turn out to be a big win.

3. It lets you stay in one headspace.

Ok, this could be considered a weaker reason, which is why I put it third. But it’s well-known that switching between tasks harms productivity, and it’s much better to focus on just one thing at once. Now consider that many developers are generalists who do some server-side and some client-side code, and as a result have to hold (at least) two different languages in their heads, with two different sets of APIs and quirks and syntaxes and styles, switching between them all of the time.

I know that I personally try to use console.log in Objective-C, trace in a javascript file, or echo in a Flex app at least once a week. And that doesn’t even get to the subtler traps of forcing one language into another’s paradigm.

Now imagine that you could take a large portion of that brainspace and devote it to just one thing. One language, one syntax, one set of patterns, one set of common bugs. Wouldn’t it make you more efficient? Wouldn’t you get so awesome and productive and ninja-esque at that language?


I’m sure using js on the server has its downsides as well, but I don’t really know enough yet to speak to what they are. But I’m convinced now that it’s more than just a toy, and is worth at least a look from people who care about the good things above.