In the previous post, we reorganized our code into components. This allows us to reuse code only pieces of our code. However, our index.html and app.js files had a bunch of extra code in them that would require us to sort through the next time we wanted to use the code in another project. There has to be a better way to organize this code, right? Well of course there is, or this would be the lamest blog post ever.

The solution is to move our code into subdirectories, each containing a component. Then we can use Browserify to bring it all together. My preferred method is to use Gulp with Browserify. So I will show you how to set it up.

If you don’t know what Vue.js is by now, then you have to check it out! In case you haven’t heard of it, here is how Vue.js describes itself on its website:

That isn’t very specific. Vue.js is a view library that updates the physical DOM based on state managed in JavaScript. You manipulate the state and the webpage will update to reflect the changes. Pretty cool, huh? It’s similar to React and can be thought of as a stripped down version of AngularJS.

• Vue is maintained by a core meteor developer.
  Evan You created and maintains vue.js, and is a core meteor developer. This gives him insight into what meteor needs, as well as having an independent, agnostic UI layer (which I believe is what meteor needs)
• Similarity to Blaze
  The syntax for vue.js is extremely similar to blaze. In fact, it seems like a perfect three-way marriage between angular, react and blaze. However, the focus of vue.js is strictly to be a front-end UI built for quick starts and short learning curves. This fits into meteor's wheelhouse perfectly.
• Maintaining meteor patterns
  One of my biggest issues in using react is that it does a terrible job of maintaining separations of concerns (in a front-end developer experience). While react tries to manage your entire application state through flux/redux, vue.js doesn't care.
• Speed/Small learning curve
  What many of us may not realize is that one of the main stengths of meteor is that it allows developers with little to no experience learn how to make rich applications through it's speed of getting set up and running. It's why I learned meteor, and why I'm a developer to this day. The front-end UI layer of meteor should be the same and should not require a complete rethink of your application.
• It provides possible stability
  React is the hotness right now, we can all agree to that. But last year at this time it was angular. Many years ago it was Ember. Essentially, every so many years we see a change it what people prefer. Being that React is going to have to compete with angular 2.0 soon combined with the fickleness of front-end techs, why not just choose a quickly up and coming framework now and make it our own? If not, what happens if the tides turn and angular 2.0 usurps react as the front-end framework du jour?