The Best Tech Stack Ever

  • 0

The Best Tech Stack Ever

Category : Meteor , React


Why did I choose Meteor:

Naive Reasons:

  1. Easy to set up, has all the boilerplate for a Full Stack JS Engineer:
    built in task runner, server, compilers and preprocessors
  2. Real-time reactivity is baked in.

Reason #1 is kind of weak, because I’m going to spend time learning how everything works anyways, and I’ve set up other boilerplate projects with Angular and Node, so I have those already. Also, I can tweak a task runner using some old school techniques to make it seem like your hot reload premonishes your CTRL-S.

Reason #2 is not used extensively for a majority of applications, and for the amount that I intend to use, it doesn’t justify the overhead bulk that comes with Meteor’s kitchen sink.

Mature Reasons:

But after fleshing out the rest of the stack, I’ve found other reasons to build with Meteor:

Since Meteor 1.3, it’s had support for npm, and it works with Yarn, if it is set it up right.

Upcoming in version 1.5, is dynamic module loading. Dynamic module loading addresses my biggest concern with using Meteor: load time. I don’t want to load the entire Meteor project before the UI is ready. I want a crisp experience. So dynamic module loading is something I’ve been giving a lot of thought to, and now Meteor is doing the thinking for me… again! Yay Meteor! Projects can have a minimal startup packet, and it will also cache other packets on the client locally, so second and subsequent visits from the same device will be much, much faster. And since the caching is being implemented better than Webpack’s and SystemJS’s version of dynamic module loading [link to blog], Meteor FTW!


On top of that, I’ve been a Blaze user since I started Meteor, and that was my first front end framework. I’ve since learned Angular, some pre-release Angular 2, and now I’m getting into React.

I like React’s simplicity vs. Angular’s everything. I like lightweight vs the kitchen sink, for performance reasons. There’s also lot of support for React when used with Meteor, so that’s the front end UI for this stack.

React v15 (which comes after v0.14, naturally) doesn’t yet have optimization for its functional (dumb/stateless/presentational/view) components, but they’ve promised it in the future, and the cleanness of code it provides now is great.


React is just a presentational layer. So it needs a controller. Redux, along with the React Dev Tools, Time Travel, and Logger middleware, does the job nicely as a simple yet extendable state object. You can learn it in a day.

React’s Higher Order Components (HOC’s), also known as containers, are where you handle state callbacks (component state, not Redux’s “application UI” state object), fetch data, and send declarative data values to the funtional view components. Redux is a great tool to manage the “application UI”, with its simple state object, which includes the data and the last action that was called on the state object.

—Meteor’s Data Store & Redux’s UI Store—

Meteor’s pub/sub model is what drives its real-time database everywhere. A copy of the pertinent data on the front end is kept in a Minimongo instance. Meteor also has traditional async data fetching methods: Meteor.methods are defined on the server, and called by on the front end.

Parts of an app will need real-time, but most data delivery won’t. The notifications, alerts, and a chat feature will take advantage of Meteor’s pub/sub, and the data will be stored in the client side Minimongo instance. Only the simplest of data, like a messageCount integer, or a hasOpenAlerts boolean, will be dispatched from the Minimongo data store to Redux for updating a view widget. Any non-primitive objects in Minimongo will not be duplicated to the Redux UI state, including the content of the notications/alerts, and the entirety of a chat conversation.

User info, item lists, and most other data is relatively static, being updated only on occasion. That data will be retrieved via, and managed by Redux, living in the Redux state object. If some of these data deserve it, a real-time watcher can be subscribed to, which will trigger another to fetch fresh data.

This approach only ties the real-time data to the Mongo database. Other data can be had via any async API. If you want to use a different database for the rest of the data later, you sure can.

-Coming Soon-

List of packages required for this

About Author


I'm a full stack web developer / software engineer. I can code a Raspberry Pi or a Windows .NET app, but I'm truly at home on the web, in the cloud, the modern JavaScript "wild west". I've been making code look good since Firefox was called Netscape.

Leave a Reply