Skip to content

Instantly share code, notes, and snippets.

@kadamwhite
Last active August 29, 2015 14:13
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save kadamwhite/6bbed66aacdefca762fc to your computer and use it in GitHub Desktop.
Save kadamwhite/6bbed66aacdefca762fc to your computer and use it in GitHub Desktop.
architecture-of-the-community.md

original outline

  • We architect applications for transparency and intercommunication, but our community is silo'd
  • Grunt vs Gulp, etc are false dichotomies
  • Many/most of us are in this business because we found a welcoming community: key component of the open part of open source
  • Current landscape appears sectarian, polarizing
  • We are not in opposing castles, we are living in cities inextricably linked by trade routes
  • We should take a step back and re-architect our community, with the same mindfulness we take in our applications
  • But in the community, two modules (groups) that do similar things are a strength: competition used to be considered a good thing! We wouldn't have Ember, Angular, etc or any of the others if it existed in isolation. Backbone is still relevant, and still inspiring new ideas (look at ampersand, new developments in marionette)
  • Relevancy and utility are not correlated to novelty

Proposal

Everybody who does Web Development followed a path to get there. Some of us have computer science degrees; others are self-taught. Some of our peers learned our trade at a start-up, and some of us rose through the ranks in the IT group of a large company. Many of us work on the cutting edge: we move beyond our history, and have the opportunity to play with the latest and greatest in technology. We can write a full-stack application in JavaScript, front-end frameworks are proliferating, and we even have a choice of unit test runners for our projects. Where we are now and where we were are different worlds: it's critical for us to remember where we came from.

I want to give a presentation to highlight some of the communities that JavaScript programmers -- and JSConf attendees -- come from, including the WordPress developer community and the enterprise, Microsoft-stack software world. (These are the specific communities where I learned to do my job, hence the focus: I'll be corroborating with the experiences of coworkers.) These communities continue to move towards modern front-end development best practices, but they don't have enough support from this group: they don't have the support of the alums of that system.

I want to simultaneously demonstrate how far these otherwise "un-cool," somewhat-ostracised development environments (PHP, .NET, etc) have come in terms of front-end practices, and to show how much more we could be doing to support them in their evolution. A lot of us know both sides of this world: we should be using that knowledge to train the next generation of our peers. The most exciting work in the world of web development is the work that is going to bring the majority -- and no, JSConf attendees are not the majority -- up to par with our methodologies, tools, and habits. We know the people who are going to do this work. Why aren't we dropping ladders down into those communities whence we climbed? (This feels hyperbolic. I've considered taking it out, and decided not to.)

As JS developers we draw arbitrary distinctions between ourselves and other communities or platforms. Gulp vs Grunt, Angular vs Ember, or even JS vs .NET are all false dichotomies: they miss the point of being a community, and that's an important thing to remember at a community event like JSConf.

other comments

I believe I could give a good technical talk at JSConf, but for me JSConf has always been an aspirational goal for myself primarily in terms of the community. Some of the best developers I know, and all of my mentors (pre-Bocoup), are from "un-cool" development backgrounds, and I get frustrated seeing people waxing philosophical about the minutiae of our tools when we have so much to give back to those communities. Better resources make us all better. I'm intimidated by submitting a talk to JSConf, but I think it's an important thing to remember.

prior drafts/notes

It would be amazing to see this speaker present on the topic of: Can be general or specific, this will only be shared with the curation committee.

Everybody who does Web Development followed a path to get there. Some of us are self-taught; others have a computer science degree. Some of our peers learned our trade at a start-up, and some of us rose through the ranks in the IT group of a large company. Many of us work on the cutting edge: we move beyond our history, and have the opportunity to play with the latest and greatest in technology. We can write a full-stack application in JavaScript, front-end frameworks are proliferating, and we even have a choice of unit test runners for our projects. Where we are now and where we were are different worlds: it's critical for us to remember where we came from.

I want to give a presentation to highlight some of the communities that JavaScript programmers -- and JSConf attendees -- come from, including the WordPress developer community and the enterprise, Microsoft-stack software world. (These are the specific communities where I learned to do my job, hence the focus: I'll be corroborating with the experiences of coworkers.) These communities continue to move towards modern front-end development best practices, but they don't have enough support from this group: they don't have the support of the alums of that system.

I want to simultaneously demonstrate how far these otherwise "un-cool," somewhat-ostracised development environments (PHP, .NET, etc) have come in terms of front-end practices, and to show how much more we could be doing to support them in their evolution. A lot of us know both sides of this world: we should be using that knowledge to train the next generation of our peers.

As JS developers we draw arbitrary distinctions between ourselves and other communities or platforms. Gulp vs Grunt, Angular vs Ember, or even JS vs .NET are all false dichotomies: they miss the point of being a community, and that's an important thing to remember at a community event like JSConf.

Many of us learned to program because we found the web to be an open, welcoming environment. The chief problem I see with modern frameworks and tooling is that we've lost some of that sense of welcome. We need to stay aware of where we came from, and where our future peers may be now: that a library like Backbone is older and stable does not make it irrelevant, and that a tool like Browserify is powerful and conceptually engaging does not make it easy to pick up.

As open-source developers, we do not live in walled cities. Free trade keeps this ecosystem going, and open doors welcome new contributors, colleagues, and friends. It's important to have multiple solutions to a problem, because competition is good and d sf 'afdshil

The JavaScript community is siloed. Externally, JS developers separate themselves from other programming clans,

JavaScript developers tend to be open source. Even if we don't release all our code under a permissive license, we all got to where we are by reading code, borrowing, breaking, and learning. This makes it frustrating to see

Anything else you might want us to know?

@ashleygwilliams
Copy link

this looks great so far!

i think ending the talk with ideas about how we can use current platforms (github) to share ideas across these siloes, and/or if those tools are deficient(they kinda are..) how we could update those tools or repurpose other tools to accomplish that task (can one reference issues from another repo easily, etc).

i think also maybe talking about creating a shared vocabulary across these different frameworks/tools etc could help, and how one could go about creating that vocabulary.

anyways! keep it up. looks good!

@kadamwhite
Copy link
Author

Additional thought, after watching Justin Searls' Rubyconf keynote: Libraries are "optimized for adoption," which is critical for gaining traction in the current, visibility/marketability-driven FOSS community, but naturally prejudices libraries towards making themselves out to be the only true solution to problem X.

@kadamwhite
Copy link
Author

Another paraphrase from Searls' keynote: "adopting a [software] dependency [into our library] outsources our understanding of how to do something." We pay down that "understanding debt" by utilizing those dependencies over time. If you're not going to iterate on your releases (which allows you to incorporate learning about those outsourced areas as you gain it), you shouldn't let yourself outsource your understanding of those dependencies. Low-level systems are less iteratively deployed or altered than high-level systems, so low-level engineers have no choice but to thoroughly understand their domain (and all of their dependencies) up-front.

Tangential to his point, but: is there any corollary that within our high-level world, we have "understanding debt" towards our colleagues, our competitors, and people within other silos of our world?

Bit stretched, leaving the comment for now but that may not be a productive line of thought.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment