A few months back I had the opportunity to speak at the Tridion Developer Summit. You can go through my slides, or watch my presentation first, if you’d like. What I want to do is expand on many of the different points that I made during my presentation. It’s hard to cover all of my thoughts in an hour (or in my case, about 40 minutes). So I’d like to finish out December with a full series on Tridion, Node.js, and JavaScript, and hopefully provide some ideas and insights for what architects need to know about Node.
Node.js is kind of a Big Deal™
Despite the fact that Node.js isn’t even ten years old, adoption has been quick. Netflix, PayPal, Uber, eBay, and even Walmart are using Node. You could argue that Netflix and Uber are newer companies, and it makes sense that they’d use newer tech. But Walmart? eBay? PayPal? Those are companies that made a conscious decision to adopt Node over other technologies. They didn’t just drink the Kool-Aid, join the cargo-cult, and hop on a bandwagon.
Node was created to solve concurrency problems
Even though Node itself is single threaded, it’s a super powerful thread. Node’s power is in its Event loop. Everything that happens in node ultimately ends up being a “reaction” to an event that’s managed inside of that loop. So it’s that event loop that gives Node the ability to handle I/O on a single thread. 10,000 concurrent requests ends up not being a big deal because they’re all being handled asynchronously.
Node became a big deal because it was a solution to a concurrency problem.
JavaScript has improved, in part, for the sake of Node
JavaScript (or ECMAScript, if you want to be pedantic), got a much needed update in 2015 and it introduced a whole slew of things that made it look, act, and smell a bit more like a big-kid language. It got variables that are actually block-scoped ( let and const ). It got a little more obviously object oriented ( class and super ). And it got easier to manage dependencies (import and export ). This all adds up to JavaScript at least on the surface, looking like the kind of language that a C# developer or a Java developer might want to use.
Node.js helped make the case that JavaScript is more than just a “designer’s programming language”. It got the attention of engineers and software developers, and as a result, the language now looks more like a software engineer’s kind of language.
NPM is freakin’ huge
As of today, NPM has over 865,000 packages. Nuget has over 137,000. The Python Package Index has 162,000.
Why is NPM so much bigger?
It’s because of the browser.
While NPM was never intended to be the package manager for front-end developers, it became the package management tool for front-end because it’s all JavaScript. NPM gave front-end developers an easy way to maintain their libraries, frameworks and snippets across projects and the planet.
So Why does Node Matter to Tridion?
There’s little argument that Node is a big deal. But the better question is, “what does it have to do with Tridion?”
Node is an application solution
Back to the bit about I/O, Node is useful for applications that need to handle lots of I/O. That makes it useful for dynamic websites and Rest APIs.
Considering that DXA can publish JSON (JavaScript Object Notation), that makes it friendly by nature. Node can be useful as a Rest API in this case if you need to deliver content to some other consumption layer that doesn’t necessarily want to be a DXA application.
Node wouldn’t necessarily make sense as the web application — unless the web application itself is really an application more than a bunch of static pages. But Node makes a lot of sense for creating simple, lightweight APIs for other applications.
NPM is the Nuget of front-end development
NPM has become the de-facto package manager for front-end developers everywhere. NPM provides their CSS pre-processors and post processors. It provides their libraries like jQuery and jQuery UI. It has Babel, which makes it easier to use new JavaScript features. It gives them their frameworks like React and Vue. It also gives them the task managers like Grunt, Gulp, and Webpack which put it all together. NPM provides their local development environments, too.
Front-end developers are using NPM to produce the HTML, CSS, and JavaScript for the site that Tridion will manage. Since NPM can provide everything from the world’s worst HTML preprocessor through a full React+Graphql bootstrap, it’s important to set parameters for how that site gets built.
You don’t want front-end developers building out a static site in some God-awful templating language if it’s going to end up being a DXA web application. You also don’t want them using React for the same reason.
Front-end developers are like fish; they’re constantly getting hooked on the new and shiny stuff without ever understanding why.
NPM enables poor choices to be made more easily, with more serious effects. So architects need to know that this is a problem.
Talk with front-end developers about how they’re using NPM to generate their code and make sure that it aligns with how it needs to be delivered.
tl;dr
Node is a big deal, regardless of whether you like JavaScript. It has potential to help Tridion as being an easy-to-implement platform for APIs.
It also has potential to hurt, as NPM enables front-end developers to make more stupid browser-centric, instead of CMS-centric, decisions.