Archive for the ‘Uncategorized’ Category

where do junior developers come from?

Saturday, November 29th, 2014

There’s a cartoon I read when I was a kid. This guy is in a job interview and the interviewer says it’s too bad he doesn’t have any experience and so they can’t hire him or something. The guy responds, “Yeah, but neither did Neil Armstrong.” Last week Jan Lehnardt tweeted that it would be cool if there was a recruiting agency focused on diversity, which is something I’ve been thinking about since. As part of that, I remembered the cartoon, which I thought about a lot when I was a very new developer.

My first job after getting my computer science degree was selling cell phone accessories at a kiosk in the mall. I want to make sure you understand: not during, as in I was in school and needed a low-demand part-time job to pay for textbooks, but after. I tried for a few months to find a programming job and finally, out of options, had to move back into my dad’s house and get a job in a mall.

There are a lot of holes in the pipeline, but I think this is one of the most crucial. If you have no network to help you, getting your first programming job is very hard.

Eventually I found a programming job working for the Washington State Department of Corrections. There are two reasons this was my first dev position. The first is that they were required to advertise in the newspaper. I knew how to look for ads in the paper (or the online equivalent), but that was all I knew about how people found jobs. I’d been surrounded by people who were going on to be programmers, and professors with professional networks, but I had literally no idea I was supposed to talk to them finding work. That was not how you got shitty retail and cleaning jobs and, therefore, was a completely foreign idea.

The second reason I ended up working for state government is that they had an aptitude test. If you were not already in their tiered system of job titles, you applied to be considered for the bottom tier, which meant taking a test. What that means is that no one had to take a chance on me, or depend on whiteboarding alone to reveal what I could do and what I couldn’t. I was a known quantity, even if all that was known about me was that I was breathing and could type some very basic Java syntax.

It’s possible that if I hadn’t gotten my foot in the door through state government I would have found another way in. But when I read the statistics about CS graduates who make it into tech in this excellent article on blacks and latin@s I couldn’t help but think, “WTF, people are still getting stuck in the fucking cell phone kiosk.” My experience isn’t everyone’s, but my experience provides me two clear hypotheses about how to stop that: find people networks and don’t create Catch-22s where people with no experience can never get it.

So when I saw Jan’s tweet, I thought I would start a recruiting agency and just put those ideas to the test. But I asked around a little bit first, and found something disheartening, which is that most people in my extended network who are hiring are not the Washington State Department of Corrections. They do not want raw graduates for their junior devs. They want people who’ve got some work to show. People who’ve done side projects or open source work. Bootcamps were mentioned repeatedly as the best place to hunt for junior devs. Bootcamps are great and I know a lot of excellent people who are involved with them. However, I believe there is some proportion of people with the skills to be great devs for whom “I should sign up for a bootcamp” is as improbable an idea as “I should create the next great front-end framework” for reasons ranging from lack of resources to bigger problems like not realizing that’s a thing people just go and do.

I no longer feel confident that starting a recruiting agency would solve the problems I want to solve. I still feel like it could be helpful as a stand-in for strong networks for people stalled mid-career (for whom the danger of attrition is high) but catching diverse people already mid-career is harder than catching the people trying to get a foot in the door. Several people told me they don’t like recruiting agencies because of “low-quality candidates”. As a former low-quality candidate myself, that’s frustrating. Especially because of Neil Armstrong.

Continually beating people over the head with junior devs they consider too inexperienced is unlikely to work, so I’m putting this one back on y’all. If you get candidates who seem smart and have a resume that shows a history of working hard in unrelated jobs, why not train them? I’ve been a proponent for a long time of the idea that if you need five great programmers, the most foolproof way to get them is to grow your own. If your tiny startup lacks training resources, avail yourself of those same bootcamps. They don’t cost much more than what you’d pay a recruiter for someone who already had experience.

And where do you get these brand-new developers? This is something I felt a recruiting agency could do, but I don’t think it’s sustainable as a business. Fortunately, I also don’t feel it’s very hard. Stop going to top CS schools and start looking instead at state schools without great CS programs and at community colleges outside of major tech cities. Stop expecting diverse, vetted programmers to drop out of bootcamps like they were slot machines and go find the people who can’t afford a bootcamp on their own and don’t have enough of a network to know there are scholarships. Make a call to the CS teacher at the community college an hour outside of town and ask if you can sit in on a forty minute class.

I took CS courses at a Seven Sisters school, a community college, and a state school that most definitely wasn’t University of Washington in terms of its reputation. They all wrote Hello World the same way. Over four years, I got very little experience writing real software, but I got familiar enough with the idea to know how it was done and that it was something I was interested in continuing. My very strong opinion is that you don’t need any more than that in an applicant.

If someone makes it through to a Bachelor’s degree, or even an AA, they can be a competent coder. These are people you can go and find yourself. They are probably all around you, seeing the interesting work and greater opportunity your company can offer, but with no clear idea of how to reach you. You can reach them, though, right now. By the time they demonstrate their chops on their own it will be much harder. If they never find a way in, that’s a catastrophe not just for you but for the system as a whole.

Another thing I think about a lot is the guy whose car I once helped find in my neighborhood in Austin during SXSW. As we were walking around looking for it, he mentioned he was a chef, and asked what I did. I told him and he said, “Oh, I used to do some coding.” I stopped myself from screaming at this black guy, “COME BACK WE NEED YOU” and instead said something about how there were always lots and lots of jobs dot-dot-dot. He didn’t explain why he’d gone back to cooking and made it clear he didn’t want to talk about it. Since becoming an ex-programmer, I have a lot of guesses about what might have happened. That fucking sucks, tech industry. That is a very poor outcome, both for the guy who’s probably making much less as a chef than he would as a dev, and for the company in Austin that’s tried every recruiter in town looking for another person who can work on their webapp.

While I like the idea of being a recruiter and working on solving just this problem, I’m sad to say I don’t think the demand is there. I’m hoping that if you’re hiring, you’ll read this and use the same strategies I was going to. I’m also hoping you’ll reconsider the value of investing in people, and how little it costs vs. how much you and your industry will gain. If you want the great programmers the tech industry is currently losing, why not go and get them before they give up?

the day the lightrail got a CoC

Saturday, November 15th, 2014

Let’s say there’s a train. It’s a lightrail, or a subway, or some other rapid mass transit line that conveys people around a metropolitan area.

The train line starts out in the suburbs. In the 80s, numerous office parks were built out there, and later that office space emptied out and was filled up again by (let’s say) tech startups. Now your metropolitan area has a growing startup industry, which means that after the train makes its first few stops, it’s beginning to get quite full. Most of the people it picks up are young white men, because this city is in America and those people constitute most of the tech workforce. Because the train is empty when it begins its journey, they are almost always able to find a seat, and they sit.

The train makes a few more suburban stops and a handful of people filter on. By this point, they are generally unable to find seats. It’s ok. At the next stop they’ll hit the areas where people with good jobs in the tech industry can afford to live, and the young men in the seats will begin to slowly filter off.

At the next stop, though, the train also begins to pick up people making the reverse journey: those who work in town and whose commute home begins in the city proper and will end an hour or two hours later in residential suburbs where housing is cheap. Let’s say a disproportionate number of these workers are young women. They are coming home from more traditional offices with strict dress codes, which you can tell because suddenly the train is filling up with people in high heels.

At this point there are almost never any seats on the train during peak commuting times. The seats are filled with the tech works picked up outside of town, who quietly read their kindles, or listen to their music, staring blankly into nothing. They may or may not notice that the aisles in front of them have crowded with young women teetering in high heels as the train turns, brakes suddenly, and jumps forward again.

But the tech workers are slowly reaching their various destinations. The train goes much more slowly now, as the densely packed train lines are shared by multiple routes, and other trains on the same route. The stops through the city where the tech workers get off are the slowest part of the journey.

When the tech workers do stand to leave the train, they leave vacant seats. Usually these are nabbed by someone not wearing high heels who can reach the seat more quickly. Sometimes a tech worker will use the vacant seat to put his laptop bag down so it doesn’t get stepped on by all the people standing.

People on the train are beginning to notice a problem. Women are constantly falling on people sitting in the seats. Sometimes their shoes or their laptop bags do indeed get stepped on. It’s a quandary for the tech workers sitting in the seats because most of the people falling over are women in high heels and most of them are men, and it’s happened more than once that someone has fallen and someone has tried to prop them up and inadvertently grabbed their butt or something.

So the tech workers get together and decide to do something about it. They are good guys and they want women to feel safe riding the train without feeling like their only options are to fall over or to get their asses grabbed. One of the women tech workers points out that maybe the women would feel safer if the tech workers wore catcher’s mitts, so their helping hands were more like a comfortable guard rail than a lecherous threat (though she is speculating because being a tech worker, she doesn’t have to wear high heels to work). The men tech workers figure this is a solid suggestion. They all begin wearing catcher’s mitts.

It works. The women are much safer. They still end up with bruises or even scrapes sometimes during their commutes home, but they can rest assured there are people they can fall into who won’t grab their butts.

Frustratingly, though, the women continue to fall over. Shoes and even laptop bags still get stepped on. It’s hard to read your kindle while wearing catcher’s mitts. The tech workers feel annoyed that they’ve organized to do something as a community to make the train ride better and their good intentions seem wasted.

No one knows how the women in high heels feel. It’s impossible to have a conversation with them while they’re standing way up there.

A woman tech worker points out that if the women in high heels had seats, they wouldn’t fall over or get their asses grabbed. One of her male colleagues helpfully explains that if the men tech workers gave up their seats, there would be no one to catch the women in high heels.

it’s ada lovelace day: get angry

Tuesday, October 14th, 2014

It’s kind of a shitty time to be having Ada Lovelace Day, what with the continuing #gamergate bullshit and Kathy Sierra’s recent departure from twitter. Every time I check for news updates online–which is getting to be less and less often–someone is getting death threats, someone is leaving her career, and the internet is continuing on exactly as it was. So today I think it’s appropriate to celebrate the contribution of women who’ve left online life or the technology field as a whole.

Reading Kathy Sierra’s post about leaving twitter made me intensely angry. That someone like weev is given the power to chase someone like Ms. Sierra away from anything is infuriating. Sierra has been contributing to the betterment of technology and the internet for decades. She’s helped who-knows-how-many people, and in doing so had a hand in giving us better tools, standards, and techniques. Weev has done jack shit, and in addition to being useless, he’s a piece of human garbage. People like Sierra create a platform and people like weev use it to drive them away.

But that’s what the internet is. If you’re not a member of the dominant demographic, you exist here at its pleasure. Knowing you have just as much right to be here–more right, in the cases of Sierra and so many other people in minority groups who were important contributors and have been chased away–doesn’t change shit. This is their internet and it always has been.

When I was a teenager, leading the volunteers for a GeoCities neighborhood, there was a guy in his twenties I’d chat with. He started out as a volunteer in my neighborhood and the chatting was professional, but he started flirting with me and at some point sent me a mixtape in the mail. I was interested in the mixtape and in talking about music, but he wanted things to get sexy and I wasn’t into it. At some point I told him to stop. He responded by moving his site to a different neighborhood (note: I know how silly all this sounds in the context of GeoCities and cybersex, but this was the 90s and the whole internet was pretty cheesy). Eventually he became leader of the volunteer efforts there, and started saying silly things about how his was the cool music neighborhood and the one I worked on/had my site on was lame or something, but mine remained the more desirable music neighborhood because it had originally been the only one.

I didn’t think much of any of this. I’d been online for less than a year at this point, and GeoCities was only my second online community. I expected that the whole internet would be mostly reading weird stuff, sitting in chatrooms with other teenagers, doing HTML, and helping other people do theirs. I’d been leading the volunteer group a few months when this dude, in a meeting of volunteer leaders, told the GeoCities employees who oversaw us that I shouldn’t be in charge because I was just a teenager. He had no seniority over me, no paid role in the company, and no justification for the relevance of my age; they replaced me with him immediately.

Things like that happened a few more times before a clear picture emerged: white men run the internet, white men run technology, and whatever place you imagine your work has earned you in either, white men can snap their fingers and take it away.

The internet is much more diverse than it was in the nineties, of course. But though the original white, male shitbags make up less of it, they retain their supremacy, and the unspoken reality is that it’s still their internet. Why does 4chan still exist? Because it’s theirs. Any challenge to its “right” to exist will be met with cries of censorship. And censorship on the internet is a far worse crime than hate speech, death threats, or nearly anything else, because the latter set rarely targets those same original white, male shitbags.

What troubles me is that it isn’t only white men. It takes an internet of billions to hold us back. There is currently no way to participate online without being complicit. We hate what happened to Ms. Sierra but we don’t want the government spying on us, so we have to back the EFF even though they back weev. We hate rape but we like WikiLeaks, so we have to back Julian Assange. We hate labor abuses but we need our toilet paper delivered next-day without having to leave the house, so we have to back Amazon. We hate institutionalized income inequality but we like Node, so we have to back Walmart. We hate the environmental impact of electronics planned to be obsolete after a year, but we can’t do our work without the latest version of OSX, so we have to back Apple. I could go on for fucking weeks. Even if we directly support none of these things, they can use our open source work. They can learn from our blog posts and conference talks.

I’ve seen direct and implied statements to the tune of “We are all Kathy Sierra,” meaning we all lose when a troll wins. While I agree we all lose, I think we have ourselves to blame. While we support the systems that support him, we are all weev.

But so. It’s Ada Lovelace Day and we’re supposed to talk about the women in technology who’ve inspired us. The women who inspire me are those who’ve taken the frightening step of lessening their culpability by decreasing their participation. While it’s courageous to remain in tech/on the internet and try to make it a better place, you can’t get around the compromise in doing so. By remaining in those systems, we award them importance. The more we say we must stay and fight to exist in these systems, the more we imply that we can’t exist without them, that they are ultimately good and necessary. And they aren’t. What is good and necessary in them exists because the shitbags allow it to, and is a side-effect.

My decades-long, non-scientific survey of the internet says that little of what we’re getting from technology is vital, let alone doing objective good in the world. The internet is mostly entertainment, shopping, and marketing. Most of the shopping isn’t done by people with limited mobility. Most of the entertainment isn’t educational. The trade-off for this wealth of pornography, shoes, gadgets, and cat pictures is ascribing necessity to a system wherein people like weev have inordinate power. That is: giving too much importance to a mostly-useless thing provides a place for mostly-useless people to flourish. Can it also give power to the powerless? Sure. For instance, many of us are better informed about Ferguson than we’d be otherwise. But also look at how the people of Ferguson remain under attack despite twitter’s attention, while on other parts of twitter death threats are driving individual female gamers from their homes. When the real world comes to the internet for help, it doesn’t provide much. On the other hand, for an abstract thing, the internet excels at causing fear, suicide, and violence in the real world. Whatever our good intentions about our technology work, this is what it enables.

To leave these worlds behind is to chip away at the source of their power: our belief in their power. We don’t need the startup industry to create technology. We don’t need to be on twitter to talk to our friends. I hold out hope that we’ll eventually have a second technology industry, maybe even a second internet, one where ethics go beyond babywords like “be nice” and are fully-formed and at the core of our participation. The ones we have now, however, are fucked, dangerous, and a waste of everyone’s time. I think Ada Lovelace would be pissed to see her work lead to a place where shitbags like weev are respected and exalted, and I think it’s time for more of us to be pissed at what our participation is enabling, as well.

a theory on tech community drama

Sunday, December 1st, 2013

I’ve been following and trying not to participate in the recent Node drama, wherein an innocent PR evolved into a battle of egos on GitHub and resulted in a very direct statement from Joyent and a large amount of hand-wringing from people offended by that statement. I’d like to propose a theory on why this kind of thing happens in the first place, and why this is not the last time it will happen to Node. Let’s reverse-engineer this fucker and maybe we can stop having the same conversation about vague inclusivity over and over again and talk instead about how exclusivity becomes the assumption.

This drama starts, at least in my mind, not with the modest and helpful PR, but with the reaction of a maintainer of the project (libuv) declaring it too trivial for him to be interested in. So here is the first problem, and it’s one Joyent mentions in their response: people who have admin rights on projects based on their coding skills, not their ability to lead or deal nicely with other people. I do not maintain any big open source projects, but in talking to people who do it’s become my understanding that the bulk of the work is sifting through issues and pull requests, not actually coding. The former is the thing they consider hardest, the thing that burns them out, their most overwhelming responsibility. So it makes no sense to me that such a role would be given to someone who deals with other people badly. And I want to clarify, that’s all I’m reading into this. I honestly don’t know (or care) if Ben Noordhuis is a sexist. I do know and care that he very blatantly let his ego drive his decision-making here, which makes him not a good leader.

But it sounds completely ridiculous to suggest that people have admin rights on open source projects because of their skill in dealing with people instead of their skill in coding, right? I know it must, because there are basically zero examples of anything to the contrary. It’s an absurd kind of bloody monarchy where the only way to lead an open source project is to be the person who wrote the original code or to defeat the original author in battle, proving your worthiness. Via code, obviously. And so all around us we have a very clear message that code is all that matters, and whoever codes best is automatically right in all things. So we can’t really be surprised when this kind of shit happens.

(I want to take a moment to note that Node does have some very good leaders who are skilled at dealing nicely with people, but that standard is less evident when you consider those beyond the most visible folks.)

Is it possible to change the culture of open source in this way? I really have no idea. Well no, that’s not true. My low participation in open source is due to my sense that it’s most likely not possible. But maybe I’m wrong. I’d like to be. What I suspect, though, is that open source rejects the idea of “management”, and having people making decisions who have not been vetted by the infallible meritocracy of holy code sounds too close to being managed for comfort. Of course, anyone who’s been promoted to or worked under a developer-cum-manager might be able to tell you how they found they actually needed a manager who knew how to take care of humans, but nevermind all that. We don’t need no parents, we’re open source, we came to party.

Of course, if this dustup could have been guaranteed to be avoided, the how is real fucking obvious. The original PR changed male pronouns to neutral ones, so as not to exclude people who don’t identify as men. A non-male maintainer would probably have accepted that immediately (and been a bit embarrassed). That’s a silly hypothetical, though, because under our current system this non-male maintainer would have to be pretty heavily involved to become a maintainer and thus would have gotten to the pronouns at issue before anyone else even saw them. They might even have been the originator of said pronouns, meaning they’d be pretty likely to start off gender-neutral and stay that way. Which is to say: because open source is so non-diverse, and presents itself as hostile and obsessed with meritocracy to the point that it drives people who might add to its diversity away, it will always be cleaning up the artifacts of that imbalance after the fact, once people have noticed and drawn conclusions, and once those privileged enough to succeed under the meritocratic system have gotten all fucking defensive about it.

“Always” might sound like a pretty strong word to use, but it’s what I believe. Well-intentioned (and grammatically correct) though it may be, changing pronouns has very little impact on inclusivity. When you’re starting from a default position of exclusivity, when people automatically associate you with the tone-deaf cringefests that are one of open source’s worst problems, when people see your community and your leadership and find very few diverse participants, when your actions don’t illustrate how people can play a role if they won’t prove themselves better coders than those already involved, hanging up a sign saying “no one is disallowed” is not going to be enough. Saying you want to be inclusive does not create a culture of inclusivity. Those who it might hope to include will be smart enough to know that if they accept that invitation, it will become their burden to deal with those already included who are quite happy to enforce a culture of implicit exclusivity. If you want to be inclusive, find the people you want to include and fucking include them. Don’t wait for them to “man up” and make pull requests or submit to your CfP or whatever; only the most belligerent are going to bother to challenge the mixed message in “we want you here, please fight your way in, and can you pick up some ice on the way”.

So those two things are how I think Node got here – emphasizing code skill above all else in building community, and relying on that broken meritocracy to deliver diversity. I see a lot of hearts in the right places, but I also see a lot of defensive and self-righteous anger. I don’t see anyone addressing those problems I’d consider fundamental, so that’s why I think this will happen again.

Earlier, Bryan Cantrill, author of Joyent’s response, tweeted this about it: “And given the haters I’ve seen today, I shudder to think of the hate that would have been unloaded on me were I female.” I thought that was funny, because in a world where a woman held Mr. Cantrill’s position at Joyent, this probably never would have come up (because see above, not due to any deficiency on his part). We live pretty far away from such a world, though.

we need more minority devs.. in corner offices

Monday, November 4th, 2013

You know what I’m tired of? Hearing this story. Programming used to be done by women. Men pushed them out. This happened last century and the trend has never reversed. I’m tired of it because its cyclical repetition in the news of the internet suggests to me that there are endless new waves of people who learn this for the first time and accept that as a reason: men decided women shouldn’t be computer programmers. I’m tired of it because I don’t see enough people asking how it was ever up to these n00bs to decide who was and was not allowed to program a computer, and why this was allowed to become anything more than a blip in our profession’s history and is now looked at with any more interest than the gambit of a gang of confidence men.

Lately I keep coming back to the same thought. It’s summed up nicely by Grace Hopper: “It’s easier to ask forgiveness than it is to get permission,” and Roseanne Barr: “The thing women have yet to learn is that nobody gives you power. You just take it.”

The question of how the patriarchy came to be in charge of an industry that often seems to think of itself as so anarchic is pretty interesting to me. I mean, the answer is obvious: the patriarchy was paying the bills. It’s nepotism. It was in the patriarchy’s interest to give these good jobs, and the respect that accompanied them, back to the patriarchy. But I wonder why those of us outside the patriarchy just accepted that, and continue to accept that we must plead sweetly to the patriarchy running this shit to be allowed a place in this industry. Especially now, when I can’t see how the patriarchy’d be able to actually stop us.

I used to take a pretty dim view of developers maturing and moving into management. I’ve done a 180 on that recently. I now feel it’s absolutely necessary. I meet fewer developers than outsiders who remain convinced by the stereotype of the “traditional” (*cough*) developer, that the best programmer they can get will be one they will know by his nerdiness, his arrogance, his hostility, his whiteness. I meet almost no minorities in dev communities who buy into that. If we’re going to create workplaces and communities that accept that picture of a developer for the marketing scam it was, we need to create them for ourselves, and that means we can’t be dependent on people who still expect us to fit that stereotype or gtfo for jobs and legitimacy.

We’re real good about pulling together to try and get more diverse people into our field, but we suck at doing the things that keep them here. More and more, I feel like the core of that second part lies in recognition and having somewhere to advance to.

I don’t think it’s a popular idea (and I think about it a lot), but maybe the answer is that if we’re not allowed to advance simply through our work, if the existing institutions don’t want to remove the secret handshakes that keep minorities out (or keep them at code monkey status indefinitely), to create new ones of our own. Of course we wouldn’t have the legitimacy granted by patriarchy-endorsed participants who can expect more money and acclaim from existing institutions, we wouldn’t have the cash granted to mostly-“traditional” organizations that merely permit a small amount of recognition to trickle down to different kinds of developers by sponsors with that same demographic, but we’d sure be better off as actual developers. Someone has very explicitly created a system in which only a certain kind of person can succeed. I wonder why the hell we kill ourselves trying to be part of it instead of just creating a new system modeled on what predated the manufactured one: people doing their work with professionalism and care.

Aside from the whining on the internet such a thing might inspire (see reactions to women-only groups), there’s really nothing stopping us aside from the belief that endorsement by a patriarchal system that doesn’t appear to like us very much is actually a measure of success. We can throw our stuff on Github. We can start small without a lot of capital and build businesses slowly. We can go without free beer and pizza. We can continue to read blog posts and use open source and whatever else we need without having to acknowledge the celebrimeritocracy that decides which are correct. We can start fucking companies. We can experiment with new technologies and patterns. We can hire employees who will be pleasant to work with, not those we’re told we must suffer through working with in order to be The Best. We can say fuck being the best, let’s just make stuff and make it the best we can.

I don’t know what prevents us, aside from the fear that there is no us and everyone else is just going to continue playing by a flawed set of rules because that’s what the rules allow.

what might a ladies.js group look like?

Friday, October 25th, 2013

I’ve wondered off and on why there’s no group similar to PyLadies or RailsBridge for women who work with JavaScript. And I’m curious if such a group is something people identifying as women within this community would be interested in. I tweeted about this, but it’s hard to capture it well with 140 characters, so here are my ideas. If you’re in the target demographic or have experience with similar groups for other languages, I’d really love to hear your thoughts.

main goal: support women in the community

I can only speak for Austin, but we have a shitload of amazing JS meetups, broad and specific, front-end and server-side. These focus on disseminating technical knowledge and are great. At least in my area, another tech talk JS meetup is not needed.

Though I think meeting women in your town working in your language is super fun and valuable, I think any meetup component of this group could be informal, done in a coffeeshop, and secondary to the group’s primary existence which would be online and at conferences and hackathons drawing people from all over the place. I’d like this to layer over existing local meetups and not have to compete with them for content or timeslots, but instead funnel people toward those they might be interested in and provide them with buddies they now already know to meet up with there.

So, then, what would the more formal online component of this include?


Localized lists of JS meetups and events. Connections to similar groups for the polyglots in the audience. Beginner-level training options for those merely curious at this stage. Organizations needing JS teachers or trainers. Translations to other (human) languages.

news items

Shared among all locales. Conference CFPs. Grant or fellowship opportunities. Opportunities for advanced-level training. Open source projects needing help. Truly broad news about JavaScript as a language. Fact-based, engineering-specific articles about furthering one’s career.


A member bio from everyone with their experience, goals, and links to github, talks, writing, and other materials. A “member of the month” or something from each locale introducing someone who’s ready to interact more with the community at large and has valuable expertise to share.


Roster of members attending conferences or other events. Commitment from all members that any other member can come hang out with them at community events so they never have to act like “one of the guys” when they don’t feel like it. Attempt at some sort of high availability distributed mentoring, especially for people in more senior roles cause there isn’t a lot of that.


Mutual cosigning with JavaScript projects and community organizations. They support our goals and approach; we recommend them as welcoming, safe, and good places to get involved. We emphasize that this effort is not meant to be in isolation or an alternative to participation in the wider community.


As women, we have an advantage over most other categories of underrepresented people in that in almost any context we’re the majority of humans (even if not the majority of coders), so when women-type issues come up we can hope there’ll be someone to get our backs. That puts us in a strong position to remind everyone to consider all kinds of diversity. What we achieve, we should pay forward.

This is pulling from a lot of different places and isn’t necessarily modeled on any one group. Not because any other group’s approach is bad, but because I am one person and this is the group I would personally like to see exist. A lot of these things exist already, but aren’t specific to any language or niche, and for me that makes it hard to feel part of a community instead of just a consumer of a news source. However, such a group needs legitimacy, and for it to have that it needs to make sense to other people, also. Therefore, again, please give me all of your thoughts as to where this is on the right track and where it is not, and let me know if you’d be willing to organize participation in your locale.


Sue pointed out that IRC would be awesome for this. Added bonus, it doesn’t require the organization of any of this other stuff and is easy to get off the ground to test out whether this is useful and makes people feel better or worse.

Jordan asked for resources for non-women who want to help, too, which is a good idea. A number of groups, for instance The Ada Initiative and Black Girls Code, accept donations, which is an easy thing to do if you just want to provide support. Actively championing such causes takes a little more effort, but is great when it happens, for example nicely asking conference organizers if they can add more diversity to their lineups and recommending some folks you’d love to see speak. And at a personal level, the Stemming the Tide study suggests that simply remembering to express appreciation for the contributions of your peers and colleagues can be a factor in keeping them from leaving the industry. Again, this is a place where other people should totally weigh in.

how to blog about code and give zero fucks

Wednesday, September 11th, 2013

I’m frustrated right now. I’ve been looking for someone to write about a technology that tons of people have no doubt used and am coming up short. Really, this is my own fault, because I was hoping I’d find someone who wasn’t a white male to address the topic. There’s nothing wrong with a white male addressing the topic, but I’ve been recommending a lot of white males to write about technologies and I was hoping to put my money where my mouth is in terms of my hopes for the diversity of the field in which I work.

I checked a bunch of related repos on GitHub and found that the maintainers were white guys and the committers were white guys and the people filing issues were white guys. So I checked the Following lists of related Twitter accounts and found.. more white guys. The few women I found either didn’t blog or had Tumblrs full of inspirational quotes and cupcake photos and shit. (Which is fine. But not what I happened to be looking for an expert on.)

And so this is how I became frustrated, because I don’t want to hit up people I know over and over again, and I need a way to know people are interested in and knowledgeable about certain topics, and the internet was giving me fuck-all.

Which brings me to the subject of this post, which is that you, developer in an underrepresented group who hopefully received this link somehow through the magical machinations of social media, should be blogging more. I need you to blog more. Little future developers who look or act or dress or think like you need you to blog more. Your slightly confused and defensive developer community needs you to blog more. Please please please please. And if you are like, “I give zero fucks about what those people need, I need to get off work at six and build charming birdhouses or customize my bicycle or something,” the best part is giving zero fucks is totally fine.

See, if you were an ambitious type, you wouldn’t need me to prevail upon you to blog more. You would be doing that and speaking at conferences and merrily on your way to becoming the next Marissa Mayer and that would be just fine for everyone. But there are a lot more not-Marissa-Mayers in the world than there are Marissa Mayers and those people need representation, lest we get it into our obsessive little developer heads that if you are not constantly being the very best at everything you should just go home. We need blog posts that aren’t about big fluffy TED topics like programmer diversity and are instead about that fucking stubborn and reprehensible bug you spent five hours on today because you couldn’t find a goddamned thing on StackOverflow.

So here are some simple guidelines for blogging about code while giving barely any fucks at all from someone who used to do exactly that and still has a job and outside interests too and it’s fine:

no quality control

Fuck quality control. If you wanted a code review, you’d put it on GitHub, amirite? It’s an idea, or a solution, or just a list of links. If you start thinking for even one second that isn’t valuable, try to picture you yourself finding such a thing when you started your day this morning and all the agony and yak-shaving it would have saved you. The internet is full of horrible crap! If your horrible crap is at least well-intentioned, it’s probably a step up from the other horrible crap. You don’t have to be perfect, or convert your glorious tabs to spaces, or even spell-check the damned thing. Just hit Post. The worst that will happen is nothing. Which brings us to..

assume no one will ever see it

People don’t click every link they see in a Twitter bio or a GitHub repo. I don’t even normally do that, which probably half explains why I can’t find you right now when I need you to write about this really important thing. This is great! It means there’s nothing for you to be embarrassed about. It means no haters will leave you nasty comments about how you should indent with spaces. It means your blogging is a nice record for you of all the problems you struggled with and overcame that, believe me, you will completely forget ever happened if you don’t write them down. If you don’t want it to, it never has to be anything more than that.

write like yourself

Writing is not fun if you have to stress over it, but if you can entertain yourself with it, it can be. So, I apologize for the excessive-even-for-me sweariness of this particular blog post, but I will also tell you that it is getting written a shitload faster than things I try to write in a professional and grammatically correct voice. If you want to “write” a whole blog post that is nothing but code examples and reaction gifs, that is valid as heck. Write it without capitalization or apostrophes. Who cares. They say you should write drunk and edit sober, and the thrill of getting something written down really quickly and in a way that amuses you is not unlike drunkenness. But also..


Or if that’s not your vice, eat ice cream. Have America’s Next Top Model playing on the TV in the background. Reflecting on your work shouldn’t have to feel like being at work. Take your pants off. Get comfortable.

actually write about code

I don’t know why, but I think it makes you feel like a better coder. It’s good to be able to explain things, or at least lay them out in snippets so it’s clear how they work together. It’s fun. And if it’s something you already coded, it means that shit is already mostly finished.

moderate comments

If you are currently averaging 0 comments per blog post, it might seem validating to accept each and every potential future comment immediately so at least someone is responding, but don’t. Statistically, the internet is 97% trolls, and you would think that trolls would not bother with a blog where there are normally 0 comments but that would be incorrect. Speaking from experience here, the thrill of seeing a new comment appear only to find out it’s baseless and nasty is far, far less than the thrill of seeing a four-page screed about Bitches Need To Stay In The Kitchen; And Also Impeach Obama in your moderation queue, considering all the time that went into writing it, and hitting Delete. Remember, this is your blog, and no one asked Hacker News for its feedback.

don’t hit post immediately

If you want to not worry about what might happen if other people someday see your blog, do yourself a solid and never post anything in the heat of the moment. Save it as a draft and come back and reread it in the morning. And if you like it in the morning, it’s good! Moreover, if you like it in the morning, you are good at blogging. If you can amuse yourself when you just woke up and you heard all the jokes about the text selection API last night, you have done a good job. And if you can’t, fuck it, leave it in the drafts and don’t worry about rewriting it. Do you want to know how many drafts I have saved on this blog? It is a lot. But not rewriting it is also very important. If you thought it was kind of a piece of shit the first time and you sit down to write it again thinking, “Don’t write a piece of shit. Don’t write a piece of shit,” you will write an even worse piece of shit. Write it later, when a new angle or really clever hack suddenly inspires you. Or not at all. Some blog posts make really good first drafts.

promote it. or don’t.

You might like having a little secret blog where you quietly explain all the things that are wrong with contenteditable that you never ever intend on filing a bug for. Or you might eventually begin to desire some recognition. Both are fine. I mean, please link to the damned thing somewhere, but you are not obligated to tweet once per timezone to alert the internet that You Have Written a Thing. However, if you write a thing and you feel pretty certain it’s brilliant or hilarious or just really elegantly executed clickbait, you don’t have to feel weird about sharing it. The internet is huge. There’s probably at least one other person out there who will feel the same way.

just please please please do it

The same goes for putting your stuff on GitHub, and speaking at your local meetups, and going to your local meetups in the first place, but those can be a lot more intimidating. All joking aside, our communities need to hear from people who aren’t the maintainers and conference speakers and web celebrities. We need to hear from people who give zero fucks, who never worry about their Klout scores or how many people starred their repo. The big names create an echo chamber where ideas are safe and popular and failure and being wrong are covered up so no one else can learn from them. We don’t really badly need any more of that crap. We need you.

we don’t swim in your toilet

Saturday, July 13th, 2013

I think a lot of people read Lea Verou’s recent blog post, “On Women In Tech”. In it, she explains her position that women in tech (WiT) groups do more harm than good. Julie Ann Hovrath, a dev at GitHub who also organizes WiT groups, wrote an excellent response that addresses Ms. Verou’s points on the subject perfectly (at least as far as I’m concerned).

There’s something that’s been bugging me from the original post that I wanted to delve into more deeply, though. Ms. Verou is not the first person I’ve heard mention it, but I’ve yet to hear a good response to it. I’m not sure I even know myself what the correct response is. Feel free to chime in below if you think you’ve got one.

Toward the end of her post, Ms. Verou says:

However, I can’t say that I’ve experienced more sexism in tech than outside the industry. Quite the contrary. Engineers (yes, including male ones) are some of the most open-minded people I’ve met. It’s not our industry that has a sexism problem, our society has a sexism problem.

I’ve heard this said a lot of different ways, but all of them can be generally paraphrased as, “What people call sexism in tech is laughable; every other industry is a zillion times worse.” I want to both concede that, and try to explain how I feel that makes WiT groups and the issue of sexism in our industry even more important.

the internet is different

The internet began as, and a remains, a place where anonymity is a completely valid choice. Those of us who work on the internet have probably moved toward using our real names and photos for professional reasons, but Tumblr is still full of kids hiding happily behind pseudonyms, revealing their ideas and interests but not necessarily their identities. As people who work on the internet, we tend to lump ourselves in with other STEM professions, but in the context of the WiT discussion, I think you have to acknowledge that difference. Those other scientists and engineers still operate mostly in person. Like the rest of the world, they may use the internet as a communication tool, but they have long histories of their identities being tied to their work. Not so with those of us who live and work primarily online.

Existing in a place whose default is anonymity creates an expectation that your work and ideas will be all that matters. I think that is probably very attractive to people who identify as women, particularly right now as societies all over the world wrestle with the idea that women are human beings, and the misogynistic backlash seems to be coming to a head. You don’t have to click many links on twitter to find politicians and pundits vilifying women for rape, taking away their reproductive rights, and attacking them for their successes. Even when it comes to light stuff like TV or pop videos, we’re inundated with depictions of women as objects and the idea that a woman’s worth is a measure of her attractiveness. The flipside is that a woman who is not young, thin, white, beautiful, and submissive is worthless. Does being anonymous sound better than being worthless? Fucking A it does.

Admittedly it’s a big jump. I don’t think it’s an unreasonable one, though. The anonymity of the internet offers a way out of that bullshit. The industry that builds the internet promises a world where your looks and social skills don’t matter as long as you can do your job well. This is different than other industries that call themselves meritocratic; we work in a place where the existing infrastructure actually supports the possibility that no one need ever see your face, hear your voice, or know a goddamned thing about you beyond what your code is like.

I’m not saying women enter this industry thinking, “Thank god, a place where I don’t have to be a sex object and can just do my work and collect a paycheck.” What I’m saying is that, ironically, when women first become interested in the field it might seem more accessible than others. Maybe not consciously, but I can’t help but wonder if it might be a factor in the appeal. Would you expect to have more pull requests accepted after whitening your teeth or losing five pounds? Of course not!

but it doesn’t actually work that way

Turns out that, for no reason anyone can explain, once we get out from behind our computers and go to offices or conferences our industry does work exactly like any other in a comparable income tier. Experts are overwhelmingly white and male. Women get further if they’re thin and attractive. Across all genders, melanin is in short fucking supply.

We are both a very young industry and an industry where no bullshit arguments about biological determinants of physical strength or nurturing ability have even the most specious relevance. We’re also an industry that needs to increase its numbers to meet demand. WiT groups exist not because our industry is so much worse off, but because our industry is the perfect place to do much better. We can be a place where only ideas matter, and where backward notions about whose ideas matter get thrown out the window. The sexism in society used as an argument that we should just accept the sexism in technology is the thing that’s backed women into a corner, and that corner is here, and speaking for myself, fucked if I’m not going to fight to hold onto that tiny piece of property.

The thing in Ms. Hovrath’s post that resonated with me most was this:

Over the years I’ve learned that the best way to make sure your experience doesn’t go to waste is to invest it in the people around you. And for me, this is what I see Women in Tech initiatives doing. I see them building communities and support systems around the collective experience of other women in our industry.

Most women in this industry have had to work damn hard to succeed and be taken seriously. There’s nothing wrong with working hard, but if you stick around long enough, you notice that some people don’t have to. They are generally not women. It might be aggravating to realize more is expected of you, and will continue to be expected of you, but fuck it. What else are you going to do? Give up? Switch to a different job where as early as your thirties you won’t be attractive enough to get in the door (this fucking happens)? Or still in your twenties and too attractive to be taken seriously in a job your experience qualifies you for? Nope and nope. The most reasonable course of action is to stick it out.

The great thing about the internet is that it doesn’t belong to anybody. This implementation can trace its roots back to the Pentagon, yet it’s now used as a vehicle for indictment of the military-industrial complex and Edward Snowden fanfic. More than perhaps any other industry, women don’t have to be given permission to be here. The internet is ours as much as anyone else’s. And I think at some level that’s recognized and so the natural reaction to the intrusion of played-out manifestations of patriarchy into our anonymous marketplace of ideas is to call bullshit. Calling bullshit is most effective when you’re not the only person yelling.

Sexism is not a natural part of this industry. Of some of the people in it? Fine. But not of the way the industry actually functions. It had to be added. Having been added, like a breast implant that’s exploded and made a toxic mess, it can be removed, and should. The sexism of society isn’t an excuse for us to respect ideas less, or to elevate individuals above contributions. Forcing it into a young industry because it’s so frighteningly popular outside of it drags our industry down, distracts us, and yes, excludes bright minds.

Your neighbors may shit in their pool. They may not even be aware that they’re doing it. They might think shit is just a natural consequence of having a pool. They may hop the fence at night and shit in your pool, oblivious as they are to the difference between shit and not-shit. That doesn’t mean you give up and start shitting in your pool, too. You clean it up (even though it’s not your mess) and you go back to enjoying swimming in a nice sanitary place where poops don’t hit you in the face when you come up from underwater. You invite your friends over, because swimming in a nice clean pool is more fun for everyone, and it’s more fun for you if you’re not swimming alone. As a result, if your friends decide to dig pools in their backyards, they know shit and pools are not irrevocably linked and they work to keep theirs clean. Slowly, you all hope, everyone will see how much nicer that makes swimming.

The rest of the world may still be shitting in their pools, but that doesn’t mean we have to.

the step back

Saturday, June 22nd, 2013

I’m building shelves right now. I mean, not at this exact moment, obviously – I’m typing a blog post. But that’s the thing I need to get done this weekend. And you might wonder, if I need to get it done, why am I sitting here typing a blog post?

I finished cutting the vertical pieces of the frame. The long horizontal pieces are already the correct size. A little short, actually, but they’ll be capped on the outside by other 2x4s that will bring the total width of the shelves out to the width of the wall they go on so they can be anchored. Now I need to carefully measure where the horizontal pieces will meet up with the vertical ones so that the shelves are level and stable. The current temperature is 97º, the hottest it’s supposed to get today, and I’ve been out in the backyard with my chop saw. I was bent over the wood I’d laid out on the floor, sweaty and shaking, pencil poised 24″ from the end of a board, when I decided I better take a shower and a step back. So that’s why I’m sitting here writing a blog post.

Last night I met up with a friend who’s also a developer and we talked about work. We disagree strongly about the value of an 80-hour work week. He sees it as a side effect of caring about your work. I see it as detrimental to your work. He said he dislikes being confined to a 9-to-5 because he wants the freedom to stay up until the middle of the night getting something working. I said that staying up until the middle of the night getting something working can lead to spending a lot of time solving the wrong problem.

I like the 9-to-5 because I think it’s crucial to take a step back. To be forced to, even. The space between actually working gives you an opportunity to think before putting fingers to keyboard (or stud to chop saw), but it also recontextualizes everything you’re doing. Our work, which has no direct customers and a thousand different potential solutions for every problem, makes us very susceptible to rabbit holes. We hold a problem in our minds and it frequently exists nowhere else in as descriptive a form. That can be really difficult, because things we hold in our mind and nowhere else have the tendency to change subtly every time we examine them, like reading a book in a dream. Trying to hold a detailed, complex idea in your mind for extended periods of time is basically impossible without progress that allows you to transfer the idea to something concrete and stop remembering it.

The step back is valuable because it forces that progress, and if it can’t force progress, it gives you impetus to make some notes. It gets your idea out of your head and puts it someplace where it can’t shift around on you. It allows you to break very large tasks up into small ones, so that you only need to be aware of the details of one piece at a time. When you come back to your work, everything you’ve done has settled and become concrete. You can loosen your mental grip on all that stuff and focus on the next step without the nagging feeling that builds over time and increases with fatigue that you’re missing something.

That’s why it freaks me out when I see people in our profession working and working with no breaks. Not that it doesn’t sometimes lead to brilliant and unexpected results; it certainly can. But more often than not, my experience has been that people working without a break for long hours have stopped solving the problem they’d meant to solve and are trudging toward a finish line that keeps moving further away from them.

There are studies that show the inverse relationship between productivity and hours worked. I don’t think they’re very surprising. With a frequency only a contrarian could love, the best way to get something done is to take a step back and stop doing it.

using javascript templates

Thursday, December 20th, 2012

You know the feeling when you’re a bit obsessed with a topic and you discover someone else is just learning about it? It would be like if you used Vim and I said I only know like five Vim commands. You’d be like, “TIME TRAVELER! I should have known when you tried to bite through your change at that coffee shop!” It’s not that I recently traveled through centuries, robbed an H&M, and learned to write ‘th’ as two separate letters, though – it’s just that I’ve never really used Vim (and I don’t want to, and I don’t want you to try and talk me into it). So it is with me and JavaScript templates. I was surprised, therefore, to search these internets and not be able to find a comprehensive blog post on how to use them. Due to my perhaps abnormal interest in the topic, I thought I would try to provide one.

To get started with JS templates, there are two things you need to agree to, as a default position (down the road, optimization might take you to a different conclusion). First:

It is bad to write HTML in your JavaScript.

That’s easy. It’s so easy I’m not even going to explain it. To do otherwise is difficult to maintain and fraught with ridiculous problems like extremely long strings and incorrectly escaped apostrophes. Second:

It is bad to send data from your server as HTML instead of JSON.

If you don’t want your pages to be dynamic, that’s perfectly fine. So fine, in fact, that you’re excused from reading the rest of this blog post and can go back to whittling yourself a neckbeard trimmer. If you do, though, sending HTML in response to an XHR is silly. What are you going to do with that? Nothing, Einstein. Nothing is what you’re going to do with it. You can insert it into the page once and after that it’s just more junk. If you’re not going to send data back from the server you might as well have static pages.

Still reading? Ok, great. So we have established that we need templates, because the alternative we’re left with is lots of DOM manipulation and nobody wants that. Let’s talk how these things get used.

replacing sections of a page

This is the most basic component. You get some data. You have a template. You hydrate said template. You attach the result to the DOM. And you need to think no more deeply about it than that.. if all you’re making is a proof of concept. For performance, we should probably add a requirement that these templates be precompiled, and that the resulting functions be cached somewhere. For flexibility, we probably want these templates to be composable, so that we don’t have to re-render more of the page than is affected by whatever data we’ve received. So add an additional requirement for partials. If we want don’t want to present all the data exactly as it’s received, we need to be able to control the scope the template function executes in, so that we have access to utilities that transform raw numbers and strings into things like currency and proper names. How we do that depends on the template engine we choose, but we need to be able to do it somehow.

packaging templates

How templates get loaded is an elephant that reveals itself very quickly in whatever room you happen to be designing your application in. Most template engines will accept any string as input, meaning the templates themselves can exist anywhere. Some people think that means they should be chunks of HTML in your normal, server-rendered page. I think that’s foolhardy and inflexible. Templates should go in their own files. In some engines, partials can be defined inline, and in certain scenarios that makes sense – for example, if you have a module that needs to be re-rendered frequently, and some subsection of it will be re-rendered alone only if some error occurs. This assumes, though, that the error state partial isn’t useful anywhere else in the app. Otherwise it should be its own file.

A lot of us start experimenting with templates naïvely lazy-loading them with XHRs. If you begin to break your templates up intelligently, though, that quickly turns into a lot of HTTP requests. Templates need to be packaged up and delivered the same way any resources do, minimizing requests while maximizing the number of manageable chunks the client has the opportunity to cache. You don’t want to concatenate all your templates into one long JS file as variables, though – then you just have the same old line break and character escaping headaches again. You want to concatenate the compiled functions they produce. Those functions can then end up in the same nice page-specific concatenated JS file you were going to send down to the client anyway.

templatizing CSS

While we’re talking about resource loading, it’s a good time to mention that a lot of template engines are output agnostic and will build any kind of code you want, including CSS. So if you’re making changes that might also require loading a lot of CSS you might not need, or that will break your page under the wrong circumstances, you can put that in a template, too, if you like. This might be nice if you want to A/B test some changes based on a factor you’ll only know in a certain client-side state, for instance. Your CSS can be a template function you feed your parameters into to output the correct version without needing to change classes in the DOM, you can attach the resultant CSS to the DOM, and you’re done.

templates outside of SPAs

Mostly we talk about templates for single-page apps, because a good deal of rendering needs to occur there, but that’s not the only place they’re useful. There are one-off areas on a lot of otherwise static pages that might have cause to re-render outside of any formal concept of an app. And then there are the static pages themselves. As soon as a page needs to be rendered once on the server and then another n times on the client, we have a case for shared templates. Before you say it, no, this doesn’t automatically mean you have to use Node, and it doesn’t mean you automatically have to use Mustache. Use whatever the hell you were going to use anyway. If there’s no parser for that template engine with that server-side language, write a parser. Or, you know, use Node or Mustache. But remember that this is computer programming and there’s always a way to do it, it’s just a matter of writing more code.

Of course, once you start using JavaScript-y templates to render some pages, you have to ask whether you want to use JavaScript-y templates to render all your pages. Maintaining two templating systems server-side might get to be kind of a pain in the ass eventually. You also have to ask how easily the JS-y templates can be used in your other templates as partials, or whether that’s even an option. (I might be completely trolling you here.) The goal of sharing templates is not having to write two templates for the same thing. To that end, it’s probably best, if a page contains a JS-y partial, to just convert the whole page to your JS-y template syntax. If that turns out to be a lot of pages, it may indeed be worthwhile to convert the remaining static pages to the same syntax, just for consistency, and in case you want to someday Ajax-ify your Terms of Service. If it’s just your one or two “fancy” pages, it’s probably fine to just keep them in separate directories and live with the ambivalence.

controlling rendering

If you’re doing this server-side, presumably whatever parser you’re using already hooks into your routing and controllers. So that’s awesome. If you’re doing it client-side and using an application framework, the pattern seems to be that either rendering is completely up to you and it’s a piece of cake, or your framework is so tightly tied to your markup that we’re not even having this conversation. If you’re not using a client-side framework you will probably need to write something. The nice thing is that you concatenated all your templates as compiled functions and passed them all in when the page loaded, or required them for the section of code where they’re needed, so all you have to do is pass them data and put the result in the right place. This is where it becomes handy to have all your templates and partials on the same object. Some engines do this already, some will need to be managed by you. This is so you can write a nice abstraction that accepts the name of the template to render, its data, and its container, and you don’t have to worry about which partials it’ll be using. Some engines also need any helper functions used within them passed in each time they’re rendered, and that’s another thing you probably want to keep separate from your main code.

widgets and plugins

There’s an inherent annoyance in creating utilities for distribution (even if it’s just among various pieces of your own app) that need to manage their own HTML and CSS. You want the person using the widget to be able to implement it with no more than an initialization call and some small set of options. You don’t want them to have to import the JS, HTML, and CSS on every page where it’s used, particularly if those pages might be built up from other server-side templates and the place the widget is used might be a partial within that system. At minimum, it’s an improvement to only have to import the JS, and have it take care of the rest (even better would be to use AMD or something to load the widget).

Putting your HTML and CSS in templates makes distribution easier, cause you have something with (presumably) a different file extension that can live in the same directory as the script that will load it and not look like it’s been misorganized. Better still, the minified version of the widget can contain the compiled templates as functions, so its users only need a single file. If you offer an option to let users supply their own path to a template, you can make your templates overridable defaults, though you probably want to set some ground rules about what template engine is allowed and how templates will be loaded and cached (e.g., are you expecting to use require.js).

mixing template engines

I’m going to be straight with you people: we have too many template engines and that’s a problem because of everything above. Templates themselves help us modularize our HTML and whatever else in the same way we can our JS, but using a bunch of different types of templates makes things messier because we then have modules we can’t share. If we want to combine the modules for use in some implementation, we have to load all the template engines needed. And that’s no big deal, the modules can take care of doing that, provided it’s not via some naïve mechanism that will add a script tag to the page potentially loading the same engine again and again. Except that to make that provision we have to assume they’re using a sophisticated loader, which is also a dependency.

The best solution is simply to not mix template engines. The likelihood that two different parts of your app require templates to be marked-up or parsed in a different way is kind of small. Choosing a template engine is like choosing a library in certain ways (which is why it’s nice when libraries like Underscore or Dojo provide their own): it allows your app to be consistent in how it handles things, and pretty much needs to be decided before you can get any large-scale work done affecting disparate parts of the app. If template strings (or quasi-literals) become available in everyday JavaScript, they won’t address all the things templates do, but they will hopefully create more consistency in how various template engines work, and ideally, narrow the field a little bit. In the short term, however, it’s best to choose a template engine you like and just use that one. If there’s a third party utility you need that uses something different, or none at all, it’s probably trivial to create a version that cooperates with your template engine by changing the delimiters in the template and the functions called to compile and render it. If you really need multiple template engines, you could create a wrapper and call that instead of the template engine directly. That would also make it easier to change your mind in the future.

That’s everything I could think of. If I missed something, let me know!

Traducción español, gracias a