The Co-opetition of Team Web
Much earlier in my career I created and open sourced a jQuery plugin called BigText. I worked hard on it. I made a cool demo page to show it off (in 3D, even). Then, Dave Rupert made a plugin called FitText. His was simple. It was efficient. It was a thing of beauty. But my first reaction was that FitText was a competitor to my precious 💍 BigText. I’ll be honest, it got my competitive blood going. I sat down to pen a furiously competitive blog post about how BigText was better and through the therapeutic magic of research-writing I learned that these two things were in fact not competitors—they were partners. I like to think that the blog post even came out a bit magnanimous at the end. These two plugins not only performed subtly different tasks, but complemented each other.
Most of this is irrelevant now, except I learned an important lesson that day that continues to serve me well even today. I no longer view alternatives to projects I’ve developed as competition. In fact, quite the opposite. FitText brought more attention to the problem of responsive text. It elevated BigText and hopefully vice versa.
Often when we feel threatened by competition, we are harboring a zero-sum mentality. “If you do well, then it takes from my slice of the pie.” Most situations are not like this, especially not at the scale at which we often operate.
Team Static Web
I develop a static site generator called Eleventy but do not see Gatsby or Hugo or Jekyll (et al) as competition, per say. We’re all part of an ecosystem that is fighting to elevate static sites as a viable architecture pattern. As evidence of this, if an alternative static site generator works better for your use case—please switch! That’s why we link to our “competition” right on the front of our documentation.
Team Web Type
Last week I had the pleasure of giving a talk at the legendary Beyond Tellerrand conference. As preparation for that talk I researched a fair number of web font providers and hosts and highlighted the benefits and drawbacks of a few of them. I recognize that a tension exists between free providers (Google Fonts) that some may see as competition to Paid pricing models. Additional tension is added when services want to encourage use of their hosting CDN.
I see free type services in the same light—they are elevating the use of type on the web. They are often the gateway to paid services, introducing and increasing the overall audience of people interested in using type on the web. All of the hardworking people supporting these services (free or paid) are on Team Web Type.
Team Web Standards
Web browser vendors are at their best when they embrace this world view. Eliminating a Best Viewed In mentality by developing and standardizing behavior together with “competing” browser vendors not only helps increase the quality of experiences on the web but ideally will get more people using the web.
Team Web
I think y’all know where I’m going here. The biggest picture is that we’re all web developers. I have my opinions (some strongly, some weakly held) but independent of your framework choice, where you put your CSS (please not in your runtime JavaScript), or even where your paycheck comes from—we’re on the same team: Team Web.
Give those native app developers hell, y’all 😇 (and don’t use AMP).
5 Comments
@davatron5000
🧡🧡🧡, bb
@autiomaa
Good points about the past, but point about native developers feels a bit odd in context. Especially since a lot of developers use multiple platforms for building, whatever they are building. Large part of how the web as a platform is getting forward comes from other platforms.
@WebReflection
ideally I agree 100%, but the problem sometimes comes with some developer from some big company that is incapable of cooperating as a "team", 'cause their shoulders are covered already so they don't need to even put a tiny effort to collaborate with other devs. Th… Truncated
@zachleat
👍 yeah—it was just a friendly jab 🤗
@ben_seven
Timeless jams m’dude. Keeping that to point people to in future!