It is a new year and I can exploit that to write a post proclaiming how
something ought to be done in 2015. We can use the new year to discard last year’s practices and mistakes as “the old way” and start fresh from lessons that we’ve learned.

The interesting (and also most frustrating) part about building frontend apps is
how fast the landscape changes. The tools, libraries, and frameworks that you
use today might not be the same as what you’d end up using on a new project only
a month from now. While we’ve ended up with this culture of adopting something
new as soon as someone posts that the “old” way is “dead”, I’ve found a few
pieces of the frontend stack that I do not plan on switching out anytime soon.

I would also like to preface this with stating that this post is highly
opinionated. The opinions expressed here are mine and formed through my own
experiences. These opinions may not reflect what I end up doing in practice, nor
does it reflect on what others at Grio may choose or use.

Tooling

My frontend development stack is primarily javascript: both the application code
and the tooling. Using javascript tooling keeps the project consistent and
makes switching between developing the app itself and the build scripting a
smoother experience.

Build Tasks: Gulp

Gulp has become my go-to javascript task runner. Before that grunt had been
the crowd favorite. I enjoy working with gulp a lot more than grunt.

Gulp uses streams for its tasks and those tasks are defined programmatically. Gulp
embraces to the idea that your build tasks are code, not just configuration.
I have found that this philosophy makes doing custom things that diverge from
the “common default behaviors” much less painful. My gulpfile is shorter than
my typical Gruntfile used to be too.

Browserify

Browserify is probably the single best thing I adopted on the frontend during
2014. What does browserify do? It lets you use Common JS modules in the
browser. This means that you can leverage many of the existing modules in npm
for your frontend app’s code too! It also means that you can organize your
source tree into a sane structure that gets bundled into a single javascript
output file which you include from your main html document.

Another benefit of using Common JS modules for your app is that you will avoid
polluting the global state (browser’s window object) with all of your JS. Components can be strictly isolated from one another, and you can unit test each module on its own.

I can go on and on about how great Browserify is. I can see it remaining useful
for quite some time. Even once ES6 (ECMAScript 6, the next version of Javascript) becomes widely adopted it will be helpful for using npm modules within the browser.

Bower

I wanted to say something radical like “bower is dead!” in light of Browserify’s
making frontend javascript easily managed via npm. The problem is that bower is
still the best option for CSS management.

Wiredep

Wiredep is a node module that will insert your bower dependencies right into the
html document for you. It uses placeholder comments to know where to insert
them.

For newer apps I find myself either skipping wiredep completely, or only using
it to insert the css dependencies, leaving javascript to browserify.

Angular.js

This part of the post has the potential to cause a holy war. Fortunately I have
already mentioned that this is an opinionated post. Late-2014 was full of
back-and-forth about Angular vs. all kinds of frameworks. There was also a
significant amount of FUD about Angular 2.0 (that is a big enough discussion for
its own post). Even after all of the discussion, all of the FUD about Angular
2.0, trying various frameworks… Angular still wins for me.

What makes Angular continue to win? I say it boils down to a few of Angular’s
design decisions: Dependency Injection, organization, and support. Notice that
I did not mention things like “data binding” here – all of the
frameworks/libraries have a solution to that!

Dependency Injection

I love dependency injection as a pattern. It allows for writing very loosely
coupled modules that are all well tested. Angular has embraced Dependency Injection and done it “right” as far as javascript goes. I agree that it has its flaws (too many
provider recipes, for example) but when you work within the boundaries of the
framework it really all comes together nicely.

Organization

I feel that Angular lets me think about my frontend webapps as if they were any
other type of mobile application. There is a strict separation between the
controller layer and the DOM which makes dealing with complex applications much
easier. This decoupling of logic from the DOM makes testing and code-reuse a lot
more common within angular applications as compared to other frameworks that
I’ve used.

Why not react?

I felt the need to include this brief section because of the growing community and fanbase surrounding react. I’m not sure that 2015 won’t be the year of react! We may see an even bigger shift to react than has already happened. Only time will tell!

Conclusion

This is how I want frontend webapps to be built in 2015. Nothing is really groundbreaking and I think a huge part of my opinion comes from the excessively rapid pace of javascript tooling and framework churn (see Breck McKye’s post on the state of Javascript in 2015.  I have an toolchain and stack of frontend technologies that work very well and I think will continue to be strong and solid through the new year.  I am planning on building a scaffold generator around these tools to generate and maintain frontend javascript projects (keep your eyes open).