The Future Is JS on the Client and I Won't Be Left Behind

Back in June I started working with my company’s X team. (The team’s name isn’t X but since I’m bound by NDA not to disclose any details about the project I’m calling it that – it does have a cool acronym name though). The X team is a group of genius backend developers with all sorts of different specialties who came from all parts of the company and assembled to create the company’s Next Big Thing.

This project was the future both for the company and in the broader sense of web application development. We’re using Angular as our front-end which talks do our API backend. The fact that I was invited to join in on the fun was puzzing since JavaScript has always been my weakest skill but at the time I joined I was the best front-end dev they had so I wasn’t totally useless. After working with Angular for the past few months I have come to realize that client side apps are the future and JavaScript, despite being ugly, is also incredibly powerful and useful in countless ways. As someone coming from a PHP background I found the idea of client side apps distasteful at first and resisted the idea of jumping on the client-side app bandwagon. After working on Project X with this team of brilliant developers I’ve changed my mind. Client-side frameworks, used properly, are just amazing and the future of web applications (arguable it’s the present). That’s why the next version of Write.app will be using a client-side JavaScript framework that talks to an all-new Ruby API. The new Write.app will be a huge leap forward for both end users and developers wanting to access its API.

Why we resist JavaScript

JavaScript on the server feels unnatural. Why would we ever use the language that’s supposed to be doing DOM manipulation on the server, right? I, like many others, have had this misconception of JavaScript as a toy language that’s only good for making sliding carousels in hero banners across the web. No matter how often we point this out I’m living proof that not everyone is buying into this idea. I urge anyone who thinks this to write a command line program on top of node instead of using a bash script, or running a node web server, or try the incredible Yeoman workflow tools as an alternative to ANT for build scripts. These tools show off the incredible power and utility of JavaScript as more than just a tool to add interactivity to the DOM.

Now, I will concede that the fact that JavaScript is so flexible as to be used both for its original purpose as a DOM manipulator and as a full fledged programming language like Python, Ruby, or Perl makes it an oddity and can cause us to be wary of trusting it. After all, the right tool for the job, right? You wouldn’t use Ruby to build a desktop application or manipulate HTML documents, right? Sorta… but you get my point.

The Benefits Aren’t Always Obvious

I can’t tell you how many articles I’ve read (just like this one, in fact) that try to convince developers that the benefits of developing client-side applications with JavaScript frameworks are obvious. I don’t think the benefits are always so obvious. Or maybe we’re trying not to hear it. My thought was always that only huge, real-time web apps like Facebook or Twitter would have any use for client-side JS frameworks. I mean, unless you’re needing to continuously update the DOM with new data the standard request/response cycle was just fine and the performance benefits are questionable. At least that’s what I always thought.

It turns out more apps than you think can make good use of the features frameworks like Angular provide. Rather than go over these features I’m going to spend the rest of this post outlining how the new Write.app will be making use of a new architecture.

Write.app is moving to the future

Write.app is currently undergoing a complete ground-up rewrite. This will be the second rewrite of the app. The first was converting to a proper backend framework from the original homespun bunch of PHP scripts that Write.app started as back in 2011. This time around we’re focusing on developer happiness through a brand new API that’ll be open to third party developers as well as a far better experience for end users. The new Write.app will feature new collaborative editing features that take advantage of the technologies present in client-side frameworks like Angular.

Decoupling views and data

Most backend MVC frameworks claim to separate logic, data, and presentation layers and they mostly deliver. Once you’ve tried a client-side JS framework for your views, though, you’ll start to see the way that frameworks like Rails handle the presentation layer as inferior. I want different things from my front and backend. I want my backend to handle logic and data storage and nothing else. Ideally I want my backend to be nothing more than an API that sends me data. I don’t need it to preprocess the data for my view, my front-end should be handling that. Its exactly this kind of processing that makes a mess out of pure server side frameworks after some time.

Angular lets me do that with great ease. I’m not only able to completely decouple my presentation layer from the backend but there’s added benefit of being able to use a build system that’s more flexible and concerned only with front-end optimizations minification, concatenation, and image optimization. The Rails asset pipeline is an example of a great build system too but it’s far too opinionated. Convention over configuration is great for developer efficiency on the backend but a developer’s needs vary far more on the front end and there’s more divergence in front-end workflows than backend workflows. It isn’t harmful or innefficient to learn the Rails way of handling assets but as a front-end developer you get to a certain point where you begin to develop a unique way of doing things and sometimes have special considerations that a framework either doesn’t handle (in which case you wrestle with it) or the alternate solutions are more hacks than real solutions. Front-end development is one area where I believe its justified to stray from the backend framework’s recommended workflow and standardize on something else. Client-side JavaScript lets you do that.

More tools in the box

Node is a tool we can use in our development on the front and back end of our application. We can use it to run our build scripts or we can replace some of our cron jobs with scripts meant to run on Node. I’ll grant you that here my argument gets a little fuzzy because I don’t have any concrete examples yet but I do have ideas. The current version of Write.app has a series of scheduled cron jobs that run bash scripts or PHP scripts. Some of the tasks being run include checking which user accounts have run out of time on their free trial of premium features, others run maintenance on the database, still others backup data, and some do things like report how many new accounts have been created each day. I can see some of these scripts being replaced by JavaScript that runs on node if it ends up being a better choice for performance or other reasons. Like I said, I don’t have many good examples here but the point is that there is now another tool in the box to choose from.

Better organization of front end code

I can’t tell you how many times a project begins with a well organized set of JavaScripts that take care of front-end interactivity and AJAX requests. These scripts usually rely on some framework like jQuery but some are vanilla JS too. Eventually, in almost every project I’ve worked on, the developers end up with an unmanageable mess of jQuery and other JavaScript as the app grows. Even with build scripts and strict workflows things start to get out of hand when some areas of the codebase require certain scripts and other don’t. Client-side frameworks take care of a lot of this for you. Yeoman’s Angular generator is an excellent example of a tool that sets you up for success from the beginning by organizing your code. Add Grunt and you now have a task runner that will run automated tests, lint your JS, concatenate it, and minify it. Bower will manage your dependencies so you can better standardize across development machines, test environments, and production. If you’re using Angular you’ve got the Karma test suite that’ll test not just your logic but your front-end code too. Oh, and did I mention that Grunt can also minify Angular scripts in a safe way. Angular minification can be quite tricky and this comes in handy. Using Angular, Ember, or another front-end framework also lets you free yourself from jQuery hell. How many times have you seen an app thats running a server side framework that’s serving up views from the backend that include scripts for the front end that are supposed to work like client-side apps but are really just a huge mess of jQuery and AJAX calls lumped together in a way that resembles true organization but is really just a fragile mess. A client-side JS framework lets you work with the DOM in a cleaner way than pure UI libraries like jQuery do and in the event that jQuery offers you something you just can’t do in one of these frameworks you can always use it without having to worry too much about conflicts. Client-side JavaScript apps just encourage better JavaScript development practices.

It’s not just JavaScript

These new tools let you work with more than just JavaScript. When you’re done getting your client-side app to request data from the backend (which shouldn’t take long at all) you can easily work with SASS, LESS, or STYLUS for styling, compiling to CSS at build time or as you work with the built in server. You no longer need to run a webserver stack separately from your app either. Grunt lets you bundle a development server in with your other tasks and gives you the ability to see changes on the fly with live reloading any time you save a file.

It’s the future, you need to get on board

Client-side JavaScript frameworks are becoming commonplace and its starting to become obvious that they’re the wave of the future. Not every site needs one. If you can consider what you’re making a web site then you probably don’t need a JS framework. If you plan to build anything somewhat large that has interactivity then its worth looking into projects like Ember or Angular. While we won’t see pure server side frameworks become a rarity any time soon we will see client-side apps become far more common and anyone wanting to keep their skills up to date and stay relevant should starting learning these new frameworks or be left behind.

Web development

« We Don't Need Yet Another Non-profit Securing API Keys in a Client Side JavaScript App »

Comments