Web Dev and VueJS are so Damn Fun

What I’m about to tell you is my story on starting my enjoyment of VueJS and front-end development. It should not be construed as an article on why VueJS may be better than React, Angular, or whatever framework you are considering. VueJS is awesome, but we are living in an awesome time for front-end developers.

If you talked to me a few years ago, I would have sold myself as a back-end developer with a good grasp of server and database administration. OOP languages, Java and C#, were the only languages I wanted to find myself being paid to program in, and I progressively learned more and more about the .NET/SQL Server stack. I had this notion that front-end development was primarily for artsy right-brained folks and wasn’t “real” programming.

Well, during my last job search, pickings were slim. I epically failed an interview that was for a job that was consistent with how I saw myself. That failure was very frustrating, but I took a lot from it. I landed at a position that took advantage of my experience with SharePoint. My experience with SharePoint was nothing special: designing pages with the GUI, workflows, etc. Not my ideal job description, but it put food on the table.

When I first started, I approached any project like I had done in the past. I relied on the GUI to design user interfaces. Fortunately, experience with databases allowed me to design lists in a normalized manner, but the user interface seemed lacking. Certain effects are difficult to implement within SharePoint designer, even when modified the underlying ASP.

I had a discussion with an awesome developer that really triggered my journey into front-end frameworks. She said, “You know… SharePoint has a REST service.” Ah, yes! I can use AJAX on SharePoint and build out my HTML based upon the response. This is going to be super fun!

Our first iteration of a particular utilized XMLHttpRequests and building HTML via JavaScript functions. There was so much concatenation with this approach that our functions and strings became increasingly difficult to maintain. So, I wanted to find out if there was a common solution to this problem.

Of course there was! Welcome to the chaos of “Why you should use framework X” videos and blogs. After doing tutorials, and watching debates on the topic, I resisted going with a framework. After all, working with a framework means that everybody has to get smart on it. However, during the course of researching frameworks, I came across Handlebars, the templating engine used by Ember.

So, we did what any sensible team would do. We rewrote our project using this template engine. Aside from having to explicitly call the compile function, it was a decent experience. The initial rendering was no problem at all. However, we needed to add the ability to collapse/expand some items in a list of items. My first approach with this problem was to assign a “visible” property to my objects and recompile the template whenever the property was changed. This means that potentially hundreds of elements had to be re-rendered based upon a change. We landed on using jQuery to apply handlers that showed/hid elements based on certain selectors.

This felt messy to me. The end product was functional, but would I be able to come back to the code in one month and maintain it? Probably. One year? Not without a lot of effort. Allow me to take the opportunity to say that lots of maintainable code has been written using jQuery and Handlebars. At that point, I wasn’t able to get it there.

So, I went back and started to look at the frameworks available. There are so many good ones, but we have a unique environment. We cannot use Node. No NPM, no tooling that is heavily used in every framework. We came to the conclusion that running Babel in the browser would degrade performance too much as well. With these conditions in mind, React, Ember, and Angular 2+ were not viable options.

We did seriously consider AngularJS (1). I had even implemented it in another project, but it was already on the chopping block for support, and Vue.js had just released V2 and had a clear path for in-browser use. It was continuing to gain popularity and there was tooling available. So, if we ever gained the opportunity to include a toolchain, we would have support for that as well.

Why is Vue.js Fun?

Many of the reasons I’m about to give can be ascribed to Vue’s alternatives.

Templating

The initial thing that turned me on to Vue.js was its templating. With some curly braces, I can insert values into the presentation based on variables that I had accessible via JavaScript. Although template literals provide a path for templating, Vue.js DOM and component templates are even easier to use. Also, there is no concern about using Vue.js in IE9+, whereas IE does not support template literals.

Reactivity

The fact that I can make a change to our model and it is automatically updated on the page is what made me initially fawn over Angular.js. Similar to the old “ng-model”, Vue.js provides a “v-model” directive that makes it easy to tie an input to what’s being displayed. Using watchers, this reactivity expands to performing operations that aren’t necessarily tied to what’s happening on the page.

Components

Although you can leverage Vue’s reactivity and templating without the use of components, implementing a component-based architecture is really fun. Learning how to encapsulate behavior into a component is fun and it gives me the ability to split out code efficiently. Similar to life in the C# world where it’s not good to have a class doing too much, I can get a sense of when a component might be doing too much. There’s something intellectually stimulating about this practice that dwarfs the the stimulation when programming in an imperative manner.

Why is Front-End so Fun?

As a kid, I dreamed of programming. Programming what, exactly? Desktop applications and games. As I started getting into real programming, I really desired to get into the kind of work that benefits the folks that I work with. I don’t know about you, but until recently, I had a preconceived notion of “real programmer” hierarchy which looked something like this.

Real Programmer
OS/Kernal Programmer
Desktop Application Programmer
Game Programmer
Back-End Web Programmer
Front-End Web Programmer
SharePoint/Sales Force/Other Platform Programmer
Microsoft Office (Access/Excel) Programmer
Not-Real Programmer

This notion really made me self-conscience about being back-end guy, much less the front-end. For the longest time, and even still in many places, these two were one in the same. This resulted in less attention being paid attention to the front end, result in low quality sites. Subsequently, organizations started hiring front-end folks for pennies on the dollar and got what they paid for. The job has had a bad reputation, and I didn’t want to be associated with that reputation.

However, as mentioned earlier, I found myself in a position where I needed to lean on the front-end to meet requirements. To my surprise programming for the browser was not only fun, but functional as well.

Power to the Browser

I am constantly amazed with what the browser can handle. Even poor old Internet Explorer can handle reading, parsing, and creating Excel files without a single call to the server. The canvas and SVGs give us two super useful ways to create beautiful and dynamic images/animations. Using AJAX, we can create dynamic content that updates periodically and seamlessly to the user.

Sharing is Caring

There is no hiding of your source when it comes to client-side development. It’s there for the world to see. So, it comes as no shock that JavaScript projects are heavily represented on GitHub. Furthermore, many of these projects are MIT, Apache, or otherwise licensed very friendly. Score! Contributions from awesome people have helped me contribute to my organization in a quicker and more meaningful way.

Instant Gratification

Similar to desktop application development, we often get to see the impact in a visual manner. We can a little flair with CSS and visually attractive sites can improve the impression we, as developers, make on our bosses and users. Coupled with a visual framework like Twitter’s Bootstrap or Bulma, we can really cut down the time to add the flair.

Write Once Run Everywhere

The old Java saying runs truer for web development than Java itself. There are challenges for making code compatible with multiple browsers and layouts for different screen sizes. Such challenges are fun in their own right, since we get to learn about a variety of platforms.

JavaScript

JavaScript continues to evolve at a blistering rate, but it’s such a fun language to work with. From the difference between ‘==’ and ‘===’ to treating functions like classes to prototypal inheritance to functional programming methods, learning this language has been super fun. Being able to incorporate new features into our sites by transpiling with Babel (for home projects) has been a blast as well.

Wrapping Up

As a front-end web developer, I get to work with awesome people in workplace and get feedback for my ideas in the greater developer community. Why do you enjoy front-end development? What do you like about Vue.js?

Thanks for reading!

Denny Headrick is a web developer that likes his work way too much. On top of developing on a variety of platforms and with Vue.js when he can, he likes to blog occasionally. You can follow him on Twitter at @dennythecoder.