Journey back to Front-end Development

Journey back to Front-end Development

It is 2016, and the world of Front-end Development is absolutely crazy.  In the last 3-4 years alone, we have seen literally hundreds of tools for tackling front-end problems.  Many have failed, and many have been adopted into workflows.  This blog post is a quick outline of how I ended up where I am today.  Scratching my head, wondering what are the tools I need to build a web application in 2016.

Set the stage

Ok, some background.  I started as an ASP.NET/C# developer in 2006’ish.  I had a mentor which threw me into a mess, but taught me the tools of the trade. SQL Server, ETL via Integrations Services (SSIS) packages, managing IIS, managing a VPS, managing clients, a little WordPress development, and generally developing robust applications for the web.  It was great.  I was building a huge portfolio, and I was learning at an insane rate.  Outside of code, I was also interacting with designers, and taking their unnamed, multi-layered, Photoshop/Illustrator files and transforming it into a website.  The concept of “web design” wasn’t really a thing, so designers just sort of, did what they felt like.  No methodology, no grids, no mobile or tablet, IE6 compatible, it was a nightmare.  It made front-end development extraordinarily difficult, but also very satisfying when the finished product looked and functioned perfectly.

Look and Feel and Data

jQuery made it super simple to manipulate the DOM in a few lines of code.  By comparison doing it in JavaScript which could be 5 or 10 times more.  This created a nice separation, where you could take out event handlers from your HTML, and put them in separate JavaScript files, thus isolating your presentation markup from your code.  For me, this is where static webpages started to evolve into dynamic interfaces, where interactions would instantly respond with an animation and some data.

More and more data began flowing directly to the front-end, and there was no way to manage it efficiently. jQuery was good at making the request for data, but couldn’t manage the object(s) in the response.  Backbone.js solved this through its Model, View and Collections approach for managing data between the client and server.

Backbone.js was great for managing all this data, however it was challenging to keep your Models and Views in sync.  It often required additional tools such as Underscore.js and a templating engine like handlebars.js.  I haven’t really used Backbone for this very reason.  There is simply too much overhead for managing massive amounts of data or effort needed for very little data.

Front-end Engineering

I detoured my career to WordPress and custom .NET CMS work for a few years.  I dabbled with other JavaScript technologies in between, but I tried to keep it vanilla.

More recently, I began working at a shop which run a Java/Oracle/Tomcat stack. They needed some work on their front-end, and AngularJS was the framework chosen by the team.  A framework which by this time had matured over 3-4 years, and had abundant support for.

To me, Angular provided a complete JavaScript framework for client-side applications.  However, having not fully embraced front-end in the last few years, my tool set has become slightly outdated.  Jumping into Angular has drastically changed my perspective of the front-end, it has become a rich and thriving world of engineering.  The front-end is much more than just the presentation. It has become a piece of software which is designed, built, tested and deployed with all the checks and governance expected from any other piece of software.

Next steps, the tools needed to build this thing: Augmenting Toolset: Yarn + React + Webpack

Leave a Reply

Your email address will not be published. Required fields are marked *