Node has changed the way we write applications at &yet. Not just sort of changed, in fact, if it didn’t sound so cliché I would use “revolutionized” to describe it.
How so? Well, if I were forced to pare it down to a single word it’d be “modularity.”
Annoyingly, the word “modular” doesn't really mean much. Of course every developer strives to write modular code, so let’s disambiguate it a bit.
Modularity across applications
Within an application, splitting things into separate files with singular concerns is a great start. But as a Node consulting company we write lots of different applications many of which share similar functionality. The logical next level of code reuse and modularity is being able to easily reuse code across applications as well.
This isn’t a new idea, of course. In the case of Node, this is where npm comes into play. It does a great job of limiting “dependency hell” that comes from different packages requiring different versions of the same dependencies, as made possible by adhering to semantic versioning. Max Ogden wrote a nice, quick explainer of nested dependencies à la npm.
This means even really simple and small modules can be reused across applications and less unique code has to be generated for a given project.
The net result is faster development cycles, happier developers, and lower total costs for our clients. Modularity lets us put the bulk of our effort into the real problems the software we’re building aims to solve, instead of solving the same problems over and over.
Development becomes more like building with Lego™ where you snap small pieces of functionality together to create something interesting. You’ve got pieces of various shapes, sizes and functionality that, when placed into the hands of talented developers, can be assembled into incredibly diverse and amazing things.
By contrast, larger toolsets feel more like Duplo™ blocks. They might get you there even quicker, but ultimately what’s created tends to feel clunky and less flexible. Great for prototyping, perhaps, but you simply lack the level of resolution required for creating a beautiful finished product that can very simply evolve over time.
Node-flavored frontend systems
So what about browser code?
Too often the wild west that is the frontend makes backend developers squirm. The seemingly infinite options of frameworks, module systems, package managers, and philosophies are often nothing short of discouraging.
Historically, the frontend was fairly simple. You’d drop in <script src="jquery.js"></script>, do a few simple rollover effects, init some jQuery plugins and be happy. These days users expect a lot more. We’re treating the frontend as a runtime and we’re using it to build richly interactive Native Web Apps.
Like it or not, more and more logic of web applications is being moved into the browser’s runtime. People from all manner of backend development perspectives are writing more frontend code. We’re all converging in the land o’ JavaScript, bringing all our various development philosophies and styles with us as we move that direction. This helps explain the plethora of tools, approaches, and styles we see on the frontend.
Painting with broad strokes, we see that folks with a Rails background are drawn to Ember, folks from .NET, PHP, and Flex may feel more at home in Angular, and hardcore FRP-types are drawn to things like Om.
But...
What do Node People™ do on the frontend?
Node devs tend to be minimalists, DIY'ers, Lego™ artists, if you will. We want a nice set of tools and pieces at our disposal that we can compose into whatever creation we imagine.
If you’ve bought into Node’s small module paradigm, stuff like Ember, Angular, and even jQuery can feel a bit like excessively large Duplo™ blocks.
To be clear, this doesn’t make them bad. I’m glad they exist. Clearly, they empower scores of developers to create some great things on the frontend.
Browserify certainly comes to mind. It lets you write code in the same CommonJS module format you’re used to from Node, run them through Browserify and have them mostly Just Work™. Fellow Yeti Philip Roberts wrote a great intro to npm, Browserify, and modules in the Ampersand.js user guides.
If you’ve been around clientside development for a while you’ve certainly heard of Backbone.js. It shares a strong conceptual bond with Node, as seen in the following excerpt from Backbone’s docs:
Philosophically, Backbone is an attempt to discover the minimal set of data-structuring (models and collections) and user interface (views and URLs) primitives that are generally useful when building web applications with JavaScript. In an ecosystem where overarching, decides-everything-for-you frameworks are commonplace, and many libraries require your site to be reorganized to suit their look, feel, and default behavior — Backbone should continue to be a tool that gives you the freedom to design the full experience of your web application.
We see the same themes of freedom, flexibility, and do-it-yourself-ness common in the Node community. The only trouble is, from a structure perspective some of the bundling and coupling of Backbone diverges a bit from a totally npm-ified approach. We built on Backbone for a long time at &yet. Eventually as I’ve previously discussed these differences led us to extract/dissect/improve various components in Backbone and publish them all as individual modules on npm. For the sake of having unified name and documentation we called it Ampersand.js.
We’ve been thrilled to see so many of these modules used on their own and paired with all sort of other things. This is precisely the sort of thing we were hoping for. We don’t want to build and maintain some giant monolithic framework and sell everyone on using it.
Financial Times used ampersand-state and ampersand-view with D3.js to create a cool interactive debt-modeling tool using data from the IMF.
WhatsApp’s new web app only uses a single Ampersand module (amperand-state) and then the whole view layer is built with React components.
For us, as long-term Node developers, seeing people mix and match our modules into their systems is a huge validation of our work of bringing the same modularized approaches we’ve fallen in love with on the backend to the frontend.
So what’s the Node frontend framework of choice? None.
Of course we think Ampersand modules are a great match for building frontends for our Node applications. But for Ampersand we use the term "framework" very loosely. As demonstrated by how people are using it, it's really is just a loosely coupled set of tools.
In the end, the only constant in our field is change. We simply cannot, in good conscience, assert that any single toolset (even our own) is the only valid approach. It’s just not how we think development should work.
For a more detailed breakdown of several popular frameworks, read my Opinionated Rundown of JS Frameworks post.
What else has our attention?
Like you, we’re always intrigued by our ever-evolving craft, but we have a unique burden to carry. As a consulting company, we don’t just ship one product, we’re responsibile for shipping a lot of apps for a lot of different use cases and companies. As a result, we’re forced to keep our feet on the ground. We’re drawn to things that help us ship great stuff faster as a team.
On the short-list of things that have our intense interest is React. While we have a nice Backbone-esque view-layer in ampersand-view there are aspects of React that are extremely appealing in a view-layer and we’re increasingly building things that pair Ampersand with React and like what we see so far.
Another is WebPack. WebPack is an alternative to Browserify that also does a whole lot more. It can do most of what you might do with Browserify while also adding features from tools like moonboots, Grunt, Gulp, etc. Essentially, it’s a very complete frontend build system in a nice, coherent, extensible package. It seems extremely stable and well supported. Of special interest is the WebPack Dev Server and the React Component Hot Loader.
What does the future hold for the frontend?
Who knows?! But that doesn’t leave us powerless. Instead of trying to predict it, we try to build modular systems that are optimized for change.
Also, if you liked this post, check out my book Human JavaScript. If not, you may prefer to tell me I’m wrong on Twitter.
Happy Internetmaking!
Remember the part earlier on about how we’re also a Node consulting company? It’s true &yet has been helping Node developers from smaller teams to enterprise clients find custom solutions for their Node apps for the past five years.
Now, we’re making that a concentrated effort under the banner of Seaworthy, the lastest addition to the &yet and ^lift security family.
Seaworthy puts you right in front of &yet’s veteran team of end-to-end Node experts, offering support through Navigator Office Hours and Lighthouse Architecture Audits.
Get in touch with our Seaworthy team ASAP to avoid sending out an SOS (sorry couldn’t resist the nautical pull) by visiting Seaworthy.io or contacting us via electronic mail.