Our Production Front-End Stack

Matt Hubert| February 2nd
twitterfacebooklinkedin

If you’re like us, you’ve tried dozens of different front-end technologies, only to learn that many are half-baked, unsupported, and not prepared for a proper production deployment. We’ve spent years trying, testing, and getting burned on those aforementioned Github projects, to finally arrive at a stack that works great in the real world, and is extremely friendly to our engineers along the way.

If you’ve been following our previous posts about components of modern web apps, you've learned the many pieces of the decision making process that go into building a new product. But we hadn't yet talked about the decisions we ourselves have made.

We’d like to present that now and hopefully save you the expensive learning experience!

That said, because JavaScript frameworks are about as divisive as sports teams, I’d like to spell out our goals in developing software applications to preempt angry Twitter posts about why we didn’t include the latest version of COBOL on Cogs in our list.

Bitmatica is an app development firm. We design and build products for clients as a service, and thus our code gets touched by hundreds of different engineers every year. Therefore, as interested as we are to try Haskell and Clojure in our own environments, they are a hard sell for our clients, who expect us to deliver something simple and maintainable.

We look for software that is

  • Production-ready
  • Mature and predictable — won’t cause time delays or budget increases as we try to patch upstream bugs and hack around missing features
  • Supported by large ecosystems
  • Compatible — we use dozens of tools, and we need them all to work together like clockwork
  • Simple for junior engineers to learn quickly — often our clients hire engineers who are expected to inherit our codebases, and it’s important that they understand what we build
  • Recognizable — as much as we don’t want to fuel the hype machine, our clients expect software that’s modern, and if only on paper, it gives them a competitive advantage to include cutting-edge tools in their stack
  • Widely applicable  — we build dozens of different products a year, and though not we try to not be a hammer in search of nails, the more reusable technology we have, the quicker we ship products

With that in mind, here is what we use every chance we get

  • Views and Controller: React.js. As the front-end framework war wages on, we have used React now in a large amount of large, production-ready front-ends, and we have been nothing but happy. React is simple, does one (OK, a small handful) of things well, and gets out of your way. Components are the future, and they allow engineers of all skill levels to manage complexity.
  • Model: Ampersand. It’s extremely well-documented, simple, modular, and works great for all different types of data with an extensible collection libraries and community. Up next: Redux. We’ve used it before, and as we become more confident in its stability and ability to solve a large class of problems, it could replace Ampersand.
  • Server communication: Ampersand. Already baked in, works implicitly, good support for pre- and post-fetch hooks.
  • Routing: Ampersand. Also part of the package.
  • Error Reporting: Bugsnag. A great, simple error reporting service. Works will all different types of languages.
  • Build Tool: Gulp. A big improvement over Grunt, with a simpler configuration and far less copy-and-paste.
  • Style Preprocessor: Sass with libsass written in C. No contest.
  • Module Bundler: Browserify. This is a tough one, but Browserify made the cut for us with its large amount of documentation, plugins, and userbase. Webpack is still a good option as well however. Good news is once ES6 becomes more standardized, this won’t matter.  Speaking of which...
  • JavaScript Flavor: ECMAScript 6 (ES6). Works excellent with Babel, most modern libraries support it, and soon it will be directly in the browser. There’s no excuse to wait — make your engineers happy and make the switch.
  • Dependency Management: npm only. Almost all client-downloaded front-end libraries have an npm version, making Bower unnecessary.
  • Type Checker: None yet. We are waiting for Flow, but it still has some work ahead of it, and with minimal library support, it’s still mostly unusable for large applications. eslint is still a welcome addition to any of our software.
  • Utility Libraries:

  • We have almost rid our codebase of jQuery! It still slips in from time-to-time, mostly due to other third-party libraries (dropdowns, notifications, et cetera) that rely on it, but we hope to be in a jQuery-free world soon enough. Until then, be sure to look for React-made components instead of those reliant on jQuery for your next project.

Hopefully with those tools, you can avoid many of the pitfalls that come with choosing the right software for your next product.

Coming soon, we hope to release a Yeoman generator that builds all of these lovely tools into a brand-new web app starter kit for you — stay tuned!

And as always, if you have any questions about building modern web applications, we'd love to hear from you!

Matt Hubert
Co-founder of Bitmatica. Super powers include catching falling objects and occasionally having perfect pitch.
Share
twitterfacebooklinkedin