Break on through to the client side (2014)
How did frontend development feel six years ago?
This is something I wrote in 2014, during the time I was switching from .NET backend programming to Javascript applications. It was originally posted on my then employer RedRadix blog, at December 9th 2014. The site was taken down, but thanks to the Web Archive I was able to find it out.
http://web.archive.org/web/20150219065455/http://blog.redradix.com/break-on-through-to-the-client-side
I find interesting to read it six years later: React exploded and wiped Backbone away, but recently the whole SPA wave seems to be taking some steps back into server-side rendering with client enhancements, ala Next.js or Gatsby.
Anyway, here’s the post, untouched: how I felt and explained myself 6 years ago. :)
A server-side programmer’s journey into the wilderness of JS, single page apps and MV* frameworks.
A little bit of history
In the beginning, there were only server-side programmers, and all they did was HTML documents. The Web was browsed using text-based, console applications that basically rendered text and highlighted links with inverse colors. Web design was not invented.
Then came Mosaic, followed by Netscape, and all of a sudden Javascript was born. Microsoft gave birth to IE4 and DHTML. The browser wars started. And all the Perl guys, who were the rulers of the /cgi-bin folder, laughed with confidence. They had started building dynamic websites — basically, returning HTML templates filled in with data coming from databases. In practice, however, it was too often a mix of HTML and server code presented on spaghetti plates. They used Perl, Python, PHP, ASP, JSP, ASP.NET. Javascript was only used for some form interactions, and some ill-advised eye candy like falling snow flakes during Christmas.
It’s been some time since then. The browser wars are over and, most importantly, today’s browsers are pretty awesome. Gmail and Facebook are among the most visited websites on the Web, and they’re both Single Page Applications. Suddenly, what we -server-side developers- had been doing for years was no longer the cool thing but the old thing. The newest web development trends left us with two options: going client-side or being relegated to be just the new kids on the block’s domain database, their RESTful servant.
For me the choice was clear- let’s go where the fun is!
Know your enemy — Javascript
Let’s face it: the moment you start writing Javascript, it feels awkward. It’s a tricky language. Powerful but strange. Depending on your background, you may encounter some of the following WTF moments:
- If you come from strongly typed, compiled frameworks like Java or .NET, having no types in your function definitions looks weird, at best. In addition, you’ll miss compile time syntax and type checking. A single typo breaks your app. Yes, it’s that delicate.
- If you come from an interpreted language with tons of library functions, like PHP… Well, if you come from PHP, anything without hundreds of dollar symbols and an infinite list of function names to memorize will probably look $trange to you, sorry!
- If you’re used to big IDEs such as Visual Studio or Eclipse… Then there’s good news: you only need Vim, Emacs or Sublime Text to start going. To be honest, I still miss Visual Studio’s IntelliSense every single day. Accept there will be tradeoffs.
The fact is that Javascript is an awesome language. You’ll have doubts, you will want to cry sometimes, but there will be a click in your head one day and you’ll be back in your confort zone. Have faith. You need to stop thinking in your previous language terms and learn Javascript. Not just the syntax, but the inner workings, its conventions. Once you do, or even as you do, you’ll start thinking how to model, organize, and design your apps in a way that feels natural.
For me, this is the fun of programming and, being an amateur musician, I find it similar to learning how to play a second instrument: a sax player and a guitarist use the same broad musical vocabulary (harmony, rhythm), but they articulate the music according to their instruments’ strengths and limitations. It’s the same in development. You can apply your generic, logical mental patterns learned during your server-side years, but an effort is needed to find out how to make your JS code shine — bright enough to take the stage and perform a solo.
Read code, read blogs, read some good books or study your beloved GoF design patterns Javascript implementations. It’s just another sound but you’ll still be making music. OK, enough with the music metaphor, stay with me. :)
From jQuery to the infinity… and beyond
The browser wars are over but some cold war remains. As a programmer, the cause and culprits are irrelevant. The fact is that if you want some acceptable backward compatibility, and some confidence that you’re building future-proof applications, you’ll end up needing a JS library, like jQuery. It’s an awesome piece of work and makes web development a breeze, abstracting you from little browser differences most of the time. This is at least what I felt when I started playing with it.
The problem with jQuery is that it does so many things that normally you’ll tend to write spaghetti code. You start doing all kinds of anti-patterns and forget about actually designing, just to be able to keep your jQuery code in a single file, waiting for $(document).ready. You could make a full Single Page Application this way, but it will be painful. You need a client framework. An MVC or MV* framework.
Why do I need an MVC client framework? — I hear your complains. In my particular case, I was already using MVC in the form of ASP.NET MVC, and enjoying it from day 1. I find that using well known patterns helps you understand, explain, compare and extend your code. You know the extensions points and the responsibilities are well defined. I once read something like “you aren’t a good developer until you stop thinking what this piece of code should do and start thinking where this piece of code belongs.” I agree 100%, and that’s why a framework will be useful to you in your journey.
My personal favourite is Backbone (http://www.backbonejs.org). It’s not the best, not the fastest, not the fanciest and certainly not the newest. But it gives you just a little layer over raw jQuery code, and has just a few concepts to understand. With those new concepts and classes in mind (Events, Model/Collection, Router, View) you can create pretty much any web app you see around. You’ll have room for your own design and organization. That’s what I love about it. In addition, you get a bonus: Underscore, which I loved too — functional programming is fun.
It’s not important which framework you use. Some may prefer AngularJS from Google, and that’s fine too. The important step is done: you’ve started designing your client-side app like you did in the server side, if it’s big enough: with some good programming abstractions.
If you still think you don’t need a framework, here are some concepts that have worked for me in the transition.
1. Single Page Apps are like desktop apps
A Single Page App is much closer to a desktop app than to a traditional server-side based app. If you’ve done some desktop development like Win Forms or native mobile with iOS or Android, you’ll feel at home. The kind of state you’ll be keeping is much more fine-grained and detailed, and the size of the data you keep in memory will be bigger. It won’t be your server taking the load, but the user’s browser.
For example: in the backend, you may be reading a cookie to perform a database query to find out the logged in user’s preferences. Every time, on each request. You regenerate the state on each roundtrip. On the client, you’ll find yourself keeping which tab the user is currently on. Which item on a list is selected, or if the user is in the middle of a drag and drop operation. That’s the kind of state you’ll be keeping.
2. Views are the “screens” users interact with
All frameworks will, to some extent, force you to separate your app’s User Interface from the domain logic, using views and templates, with as little logic as possible. Good for your workflow with your designers. Even if the designer is you. ;)
3. Your backend API is your new database
You’ll probably be consuming some data from the server, and it will be returning you JSON, accessed through a REST API. They’re fun to use and even funnier to design. Embrace them, and believe me if you’ve never used XML-RPC or SOAP Web Services: they’re the Holy Grail in comparison.
I tend to think of a REST API as my SPA database. And endpoint (or resource) like /contacts is my relational database table. If you GET the resource, you’re running a SELECT. If you POST you’re INSERTing and if you PUT (or PATCH) you’re UPDATing your table. I will omit DELETE, you get the point.
Nice side effects
As your Javascript skills grow, you’ll have access to one of the coolest technologies that have emerged lately: NodeJS (http://nodejs.org).
You will be capable of reusing code and patterns and to write the full stack with one single language, Javascript Object Notation (JSON) on the database level when using MongoDB, Javascript on the server, and Javascript on the client. A breeze. :)
NodeJS has a vibrant community that is producing tools, libraries and projects at an amazing rate. And your jump into the client-side Javascript bandwagon will add all of them to your developer belt, which is always good to grow, don’t you think?
In addition to NodeJS, there something else big enough to invest time in learning how to write JS apps: Phonegap. Once you’re able to write a decent SPA for the browser, you’ll have walked a long part of the path to writing native-looking HTML5 mobile apps. You will be able to publish them to the AppStore / Google Play and make trillions of money. ;)
Another project worth keeping an eye on is node-webkit, which allows you to reuse your JS and NodeJS skills to produce full-fledged desktop applications that can be installed and executed in Linux, Mac and Windows. Written in the same language: Javascript. Sweet, isn’t it?
So… is it worth it?
My experience, as you can tell for sure now, is that the journey to client-side development has been hard, but at the same time fun and rewarding.
There’s a wow factor in building modern web applications that I think it’s clearer client-side than server-side. You can build amazing UIs, impress your friends and have something to show. If you’re like me, you’ll find your friends and family won’t exactly appreciate your server-side optimizations, but will notice that the page doesn’t reload and will adore all the little effects and transitions.
It’s just like Facebook mom, can you see it?
