Excuse me, your code is bleeding.

Our competitors use cutting edge technology. We use bleeding edge technology. Our technology is so bleeding edge, it hasn’t even started to bleed yet. We use code that hasn’t even been written yet. We’re leveraging ideas that haven’t even been reinvented yet. We haven’t even incorporated yet. We’re so start-up we haven’t even started yet.

This is San Francisco.

Every morning, while walking the 5 blocks from BART to the office, I pass maybe 500 people. 490 of them are in technology — proudly sporting their Adverbly and Verbify shirts and stickers — while the remaining 10 folks are asking for spare change or screaming at fire hydrants. In this city, we have a ton of influence on the world when it comes to defining what makes tech companies great, and what “best practices” really mean to the world. Contrary to what a Millennial might tell you, the NPM library that’s coming out next week that’s a fork of another one nobody’s heard of isn’t what makes our companies great. Security, dependability, scalability, security (yes it’s that important), and the ability to assess and analyze new tech as it becomes available is what makes our companies great.

Slow and Stable

I believe that one of the main challenges with the scalability and security of start-ups might actually derive from all the new devs not having experienced Internet tech before the dotcom boom. Look at any of the top 20 most profitable E-Commerce companies and you’ll notice something in common: a lack of trust in new platform technology. New technology means new risk, and if I was a new developer, screaming all I want through my flower beard wouldn’t convince their security teams to let me use that open source fork I just stumbled upon that seemingly fixed that one bug I didn’t really understand in the first place.

I spent the first decade or so of my career on Linux building websites with MySQL and PHP. Ya I know, “PHP Sucks lolz”… bear with me here. This was before websites were called “web apps”, when JavaScript was used to wire up buttons and make AJAX calls and didn’t account for 99% of the codebase; when devs knew what JScript was and why Internet Explorer was such a pain. Those websites didn’t break often, were fast, simple to comprehend in the source code, and made money. As a career developer, I was content and my clients were happy.

PHP has accumulated a pretty bad reputation throughout its life, for several reasons; the biggest in my opinion is that it allows people who don’t know what they’re doing to make websites that appear to work as expected but are terribly insecure behind the curtain. The language is extremely forgiving and doesn’t enforce any best practices unless you explicitly tell it to, which leads to novices suppressing errors and writing plugins for Wordpress, Joomla and Drupal that would reference globals and break other plugins, writing SQL-injection-prone queries and using them as blog tutorials, and storing passwords as plain text, because, if I don’t know I’m being hacked then no harm done, right? Impossibly frustrating stuff.

Fast and Risky

In 2012 I switched over to NodeJS as my primary go-to server-side development language because I enjoyed the modularity and the community which seemed to really aspire to best practice adherence. I was already very comfortable with vanilla JS and was also fed up with CodeIgniter being the new hotness for everybody and their brother who wanted a PHP website. Have you ever tried running PHPUnit on a CI Controller? Of course you have; who hasn’t? It sucks, right? *High five.

For all the great things that the Node and JavaScript communities bring to the table, I think that the notion of “we have to use the latest thing” needs to chill. I think the real power of open source is to expose the masses to our software intentions so that crowd intuition can be applied, therein securing and optimizing said intentions. I don’t think the benefit of open source is so that we can choose from 70 libraries that only uppercase the first letter of a word and haven’t been updated in a year.

Newer !== Better

On the client-side, when Single-page apps first came to light, we had Backbone, then Spine, then Ember, then Angular, then Durandal, and so on. Can you still build a solid SPA in Backbone in 2016? Yep. So why do I sense judgement when I tell people I haven’t upgraded to Angular 2 yet and still use 1.5? Do you know how many times Angular 2 has changed since its inception? If I had built a site in Angular 2, it would be the buggiest, most-refactored-to-keep-up-with-changes app in my career. For what benefit? Where is the gain? Bragging rights? How does that help a client? In 6 months to a year from now, it’ll certainly look very different, be a little more baked and patched, and a little more ready for consideration — but until then I would be doing a disservice to my clients by even suggesting it as an option. It’s in the list with about 5,000 other open source projects I’ve never heard of that came out yesterday that I won’t be suggesting. Don’t get me wrong — I’m 1000% in favor of open source code diversity. It prevents another Microsoft. I just think we need to stop treating all the new scripts like black belts and let them earn their ranks. Blindly trusting scripts is how exploits like Heartbleed sneak up on us.

Libraries !== Frameworks

When ReactJS came out, Facebook very clearly stated that it was only the view layer. As in, you can actually quite successfully replace your AngularJS directives with React components and your Ng app will work just fine…and ironically not any faster. When I saw the presentation by the FB devs on why they created React (to solve the unread message icon bug) I was legitimately surprised. “One-way data flow” they said. Solved “two-way binding chaos” they said. A fundamental misunderstanding of MVC by novice developers led to the creation of an entirely new library which was adopted by the entire fucking community as a solution to a problem nobody else had, because “Facebook”. Ok, so all the PHP, Perl, JSP, ASP and ColdFusion sites that had been around for over a decade prior which used that exact data persistence flow didn’t count?

But… but Facebook! Ok. Then why do companies keep comparing AngularJS to React as if they’re one in the same? Without Flux or Redux helping React, you can’t begin to compare the two — so for companies to consider React over Angular just because it’s the new hotness shows a clear lack of understanding of the driving technology behind the name, which is really frustrating in this industry where “buzzwords” sell products. Angular now has a one-way data binding option. Your move, Facebook.

No, Really. Libraries !== Frameworks

A few years ago, Knockout.js was introduced. I worked on a project for a client who’s internal dev team required that we use it because a quick Google search by one of their developers turned up KO as the new hotness. Well for one, KO is just a binding library. There’s no routing, no http service API layer, no modularity with native dependency injection; so those features had to be cherry-picked from other libraries and stitched together to form our stack — that’s not always bad, but for this project it was pretty chaotic. The one thing that KnockoutJS does do is binding, and it’s awful. Any variable you want to be observable becomes a function, so foo(“bar”) acts as a setter so that foo() would then return “bar”. Ok, ugly but fine, until you want to send that data in an API call — have you ever tried to JSON.stringify() an object containing functions? Of course you have and you know it doesn’t work! *High five! So KO offers ko.toJS() and ko.fromJS() functions to convert values to and from observables, which need to be called before sending data to an API. Yes, keeping track of all that was a nightmare. Why did it gain any traction at all? Because it was new. And Millennials love new shit.

MongoDB Is Not For Data You Care About

I had a former CTO tell me once when I suggested that we had a graph model and should be using Neo4j: “Investors love MongoDB — they’ve heard the name now, and it’s hot and sexy.” I replied, “Why would we use a document-driven db for a graph model just because investors think Mongo is sexy?” I lost that argument thanks to some buzzword-drunk investors, and unfortunately my concerns came to fruition 8 or 9 months later when the queries became impossibly complicated and underperforming in Mongo and the entire project was dropped, which accounted for several people losing their jobs.

Lamborghini’s are sexy too, but they would not do well in the Baja 500. We need to pick the right tool for the job — one that makes sense, is supported and to which is actively contributed, and that has been proven to work. I don’t think we — as companies — should be part of the demographic who experiences release-candidate pain. I assert that there are plenty of devs in the community (including myself) who tinker with new releases on our own R&D time and offer feedback and pull requests to help stabilize libraries so that we can eventually use them at work.

Exceptions?

I’d be remiss if I was implying that “all new libraries are bad”. New libraries that compete with other libraries for brand traction are one thing. New libraries that solve legitimate problems are another. Take RamdaJS for example. Unlike the Underscore->Lodash utility library transition everybody lost their shit over because we all gained 0.5ms of processing power, Ramda solves real problems in JavaScript: mainly that of mutation and scope control. Ramda never mutates objects, and always returns altered copies of whatever you give it. All functions in the library are curried which means arity actually matters. Ramda takes the functional programming concepts from Scheme and Haskell and makes them available in JavaScript, which solves SO MANY PROBLEMS! So, that said, currently at 0.21.0 at the time of this writing, I consider it a must-have for my applications. Unfortunately, frameworks like Angular and Express which depend on mutation don’t appreciate the reference loss so use it with some planning in those scenarios. If you don’t want to take my word for it, or if you just really like Lodash, look into the “fp” branch which offers currying and composition.

TL;DR

The takeaway here is that not all third party code will jive with your app’s intentions. Not all developers take security precautions. Not all libraries on NPM are worthy of being a part of your application. The moment your own code becomes the minority shareholder in the repo and you’re depending more other developers around the world to keep your company afloat than you are yourself, you better make sure you have vetted the code upon which you’re depending. If the head of dev-ops tells you you can’t use a library, trust her judgement before resorting to Millennial cynicism.

On our own projects and experimental R&D efforts, let’s have at it and make bleeding edge code that changes every day. In a professional environment on code that will be used in production in E-Commerce scenarios, though, for the sake of all that is sane in the world, let it bake. Let the community vet it for us! We need to build sites on stacks that don’t implement breaking-changes every week simply because the primary contributor had a stylistic change of heart. We need to use libraries and frameworks that recognize exploits and take extra security measures. Customers trust us with their personal information, credit card numbers, photos and media. We owe it to them to give a shit.