While Twitter, for many individuals, has taken the place of blogging — instead, for me, it’s the place where ideas are fostered and allowed to grow before expanding into fully formed pieces of prose.
This post is a study of that pattern. A few days ago, I tweeted the following statement:
Act One: We Love Where We Come From
<script> tag and your environment is primed — but this initial simplicity can also become problematic.
ESLint, the closest thing we have to a universally accepted standard of best practices, is customizable. We use this ability for both good and evil: if you look at other tools (like
gofmt, the de-facto style enforcer for Go programs), you’ll realize how dangerous this can be.
Here’s the thing. I love a strict style guide. Turn the linter to eleven and cut me loose. If the feedback loop is tight enough, I don’t care. Not one iota.
Gulp, Grunt, Broccoli. Rollup, Browserify, Webpack. Each time a new tool surfaces, sometimes more than once per day, we look around and sigh. My startup’s code base, even though it’s written in React, has fell out of vogue. Surely we could remain hip for at least a week; guess again.
If you’re coming over from Go, Java, C, C++, C#/.NET, or any other programming community, I’m sure you wonder how we get anything done. Most of us don’t. We either make a conscious choice to live on the edge, consistently dissatisfied and unhappy, always looking for the next fix, or we intentionally lag behind. If you value safety and seek to spend your technical finances wisely, stay back by at least two years.
But if you love the community, and the action within it. You’re happy. The rest of us, especially with small teams, are doomed to forever play catch-up.
Like almost everything in life, this dilemma has a handful of positive attributes too. No tool will ever stagnate. If an ecosystem can survive the meteoric rise required to stick, the odds of it staying strong over years are solid. I’d bet on them any day.
Act II: Where Do We Stop?
Let’s first go over what we know to be true:
I admit, it sucks as a newcomer to learn that thirty modules are required before you can serve up a basic site. Okay, I know, thirty is an exaggeration. All you really need is Express — but what if you choose Koa, or Hapi? Prepare to load up the plugins.
This is good, yes, because CommonJS and the incoming ES2015 Modules spec make it easy to develop small, reusable building blocks. (Who doesn’t like writing an authentication system once and using it everywhere?) Especially when coupled with Rollup’s “tree shaking” feature, which only includes active code, this technique is ready for prime time.
If you’re going to render code generated by React (and other frameworks like it) on the server side, it’s always easy to fire up a new web server and get it done.
I find it exceptionally hard to argue with the flexibility that React and JSX bring to the UI debate. It’s so smashingly good.
When you’re brand new, and presented with a grab-bag of 25 dependencies, you rarely choose the correct subset. No, you choose them all!
We’ve gotta stop focusing on build tools.
I shouldn’t have to write this. We have enough. Focus on improving the ones we already have. Done.
Don’t treat newcomers like sh*t.
+"44" means. (That’s a coercion technique, FYI.) It shouldn’t be that way. 20 years of language development, almost always by the crowd or committee has it’s price.
How About the Good Stuff?
It isn’t all bad, I promise. I’m proud to call the people below my friends. They’re amazing humans who do the hard work, despite the lack of immediate, quantitative value. Here are a few charges led by people who deserve our praise.
The learning curve is being shaved off.
My pal Jed Watson and his team are kicking ass with tools like Keystone, which dramatically short-circuits the huge learning curve. Did you mention building a site in Node? Are you cool with MongoDB? (Hint: you should be, for most cases.) Use Keystone. Boom. Done.
The boilerplates you encounter everyday really do have a place.
Sure, we need to figure out how to best scaffold applications, and make the process easier for everyone (especially newcomers). But that may happen by distilling a handful of boilerplate configurations into a couple of specs that are boilerplate projects themselves.
Standards will be our friend forever.
Node.js’ initial release dropped in May, 2009. As of this writing, the runtime — which arguably predates the “platform” that would be built on top of it — is just over 5 years old. The Node.js Foundation, a nonprofit organization formed as a joint project with The Linux Foundation, was introduced by Joyent in February 2015 by the occasionally embattled CEO, Scott Hammond.
Consider this. The project is less than a decade old. The Foundation, which is possibly Node’s most important initiative, since it launched the formal Technical Steering Community and many other helpful working groups, is almost one, per the Joyent blog post above.
Any way you slice it, as a community, foundation, or runtime; Node.js is young. This may be controversial to mention, but Node.js has magic. It hasn’t yet matured to a point where everything is standardized. I’ve been working with Node.js almost since the very beginning, 0.2.0 to be exact. Firsthand, we’ve reinvented the world several times, and while the next releases are moving along at a steady clip, the ecosystem isn’t finished evolving. We still need time to establish bulletproof standards. I can only imagine that build processes, based around tools like onChange will eventually be the norm, not the exception.
The Community, not so much at large, but on the fringes, tends to fall prey to hyperbole and fad-chasing. Folks are now ditching Gulp and Grunt without considering why they choose a given build system in the first place.
But first, all of us must place a flag firmly in the ground and decide where we want to be. Build systems are fine, but everyone will need to understand why they use a certain tool. (“Because my friends use it,” or “my team thought it was a good idea,” are unacceptable answers… unless it was your superior, who knows how Node.js rolls. Then follow their lead.)
The Node.js Foundation Board of Directors: It’s Real
Did you know that The Node.js Foundation elects board members? That’s right, and my fellow Nodevember attendee, Ashly Williams is a candidate. Vote.
Why does this matter? For a very long time, Node.js was controlled by corporate powers at Joyent. We were grateful, but ultimately, a Foundation was required. This tiny project grew up and quickly strained at the bit of it’s corporate sponsor. This is not new.
This power struggle has been fixed, forever, by the Foundation. Live it, breathe it, pay into it, and support it’s efforts.