Introduction

Anyone remember the golden days of Ruby on Rails? The days when you could be a "rails developer", and work on any project across any company, knowing that the framework and structure would be the same? Not having to re-learn a new stack and set of technologies every month, or for each project you work on?

Well, Rails didn't work out when it comes to adapting to the modern web. But one thing that we all learned from it was the power of convention. At the same time, too much convention can be a hindrance. There must always be customizability, and this is demonstrated clearly by the way that the development community has moved away from monolithic solutions like rails and django, and towards smaller and more modular tools like express, react, and postcss.

Spike is built entirely on top of modular, plugin-based systems. A spike project is just a normal html, css, and javascript project with a little dev server and live reload without any plugins. As such, developers are afforded an extraordinary level of flexibility when it comes to deciding how their toolset will look. You can choose between multiple hundreds of different ways of transforming your html, css, and javascript. The flexibility you have here is nothing less than incredible. But at what point does it become overwhelming?

We moved away from monolithic solutions because of the lack of flexibility, but now the lack of convention is coming back to bite us. If every developers builds their own stack based on their own personal plugin preferences, how is any other developer supposed to work with it? What will happen if they change companies, and they have a different stack? Ultimate customizability is incredible, but also comes with an ultimate lack of stability.

Spike Standards is an attempt to change this by bringing back a little bit of convention. To be clear, you do not need to use our standards in order to use spike, nor do you need to be using spike in order to use our standards (although the two work together very well). Spike standards is simply a set of guidelines for what tooling you should use, and our justifications for why we chose in the way we did. Accept our standards, and it comes with a set of clear documentation on which features we require from our tools, and how to use them. The more people that accept these standards across your company, and across multiple companies, the easier it becomes to onboard new developers to projects, the less time we burn learning boatloads of different ways to accomplish the same thing, and the more time we spend shipping great products.

Let's Get To It!