While pulling down an existing Backbone.js project that I was helping with, I felt confident enough with JavaScript that I figured I could start cranking out JavaScript fairly quickly. What could have changed since I rolled my own AJAX framework in the mid-2000s? Sure, there have been some changes to the Ecma specification, but JavaScript is still JavaScript, right? I’m not saying I was a JavaScript expert, but I thought I knew JavaScript well enough to comprehend what the code was telling me.
Since the mid-2000s, I’ve used JavaScript for what the Java EE frameworks let you. With front end frameworks like JSF, JavaScript is not the developmental focus. There are AJAX-ified components which let you add some JavaScript to do some more stuff, but most of the heavy JavaScript is abstracted away and it usually just works. jQuery is thrown in with most Java EE front ends to make things a little easier. JavaScript is just the filler to the heavy Java EE web application client-server pattern.
My Journey
I was wading in the Single Page Application (SPA) waters and ready to tackle Backbone.js. I knew I had a lot to learn before I could start swimming with any efficiency, but after reading a few Backbone.js blogs and perusing the Backbone.js site, I felt like I had enough to put my first foot in. I was excited and eager to get my feet wet.
I put my foot in the SPA water to test things out and found the waters a little cold. I found JavaScript syntax that I had seen before, but haven’t had hands-on yet. How does this existing JavaScript code work? After adjusting to the temperature a little, I figured I’d try the old copy ’n paste routine to get my new view started from an existing one.
Now the new view is was to be displayed on my laptop monitor. Instead of seeing all the HTML goodness, I was greeted by the first wave pushing me back. I only saw a blank page. That’s okay, I’ll just check the dev tool console to see what the error is. Blank. The second wave pushed me back even more. I figured that I would just step through the code with the browser dev tool to determine what I did wrong. Why did my debugger suddenly die after stepping over a few lines? This is when the tidal wave engulfed me and pushed me back to land leaving me there without a clue what happened or even how to fix it. I realize that I didn’t really know JavaScript. And, if I didn’t know JavaScript, then there was no way I could start correctly using Backbone.js or any SPA framework.
Sorry for my poor attempt at novel writing.
With any major paradigm shift, there is a learning curve and mistakes will be made. I tried to change the JavaScript code, but things were getting worse. My confidence was bruised, but now I truly knew what I needed to do. I had to go back to the basics before getting back into the water.
Since then, here are the things that I have found to help make the journey to the SPA waters from Java EE a little easier:
Tip #1 – Read a Good JavaScript Book
JavaScript: The Good Parts was a book recommended for me to read. It is a small and efficient book that will allow a developer to establish a good foundation. It isn’t a reference book, so it is easy to read. As the name suggests, the book focuses on the good parts of JavaScript and why you should use them. Although the book doesn’t give too many pages for the bad parts, it does give a brief description and a reason why to stay away from them. I’ll let the book tell you which are the good and bad parts.
Along with learning which are the good parts, there are some language caveats that will give you cold SPA water shock and will prevent the application from being reliable or readable. Here are a few items that you must completely understand to prevent shock:
- scope
- context of ‘this’
- prototype and inheritance
JavaScript frameworks like Backbone.js and AngularJS have online examples that solve the same problem, but are not consistent across bloggers. The different examples make it hard to filter out the fluff and to know what the real stuff is. Once you find a couple good authors, try to stay with just those. It will be easier to understand other SPA patterns once you are familiar with their styles.
Having a good JavaScript foundation will help you separate bad patterns from the good ones. It is highly advisable to take some time and stay with one foot in the water and really get to know the good parts of JavaScript before trying to swim. How can you swim without knowing the mechanics of swimming?
Tip #2 – Read Blogs on Debugging JavaScript
Debugging JavaScript is a little different fish than debugging most Java EE applications in an advanced IDE. With all the listeners and events firing, only setting breakpoints on a specific line number doesn’t cut it. There is too much going on in JavaScript and the DOM that you’ll never be able to capture race conditions if you don’t know how to debug properly. The information you glean from basic console logging and breakpoints will not protect you against the powerful waves of frustration.
Here is a nice tutorial series to get you going from Keyhole’s Zach Gardner:
Tip #3 – Browse the Docs on Your Favorite Browser/Developer Tool
To build upon Tip #2, browse the documentation on your favorite browser and development tool combination. I had been using Firefox and Firebug for a while and didn’t know I was only scratching the surface of the capabilities of Firebug. How handy is it to log when a specific function is called without having to break each time or manually add logging statements? Do you want to be notified when a DOM element gets a child appended? This is just a fraction of what a good developer tool can offer.
The water is starting to become more calm and manageable!
Debugging tools have become really powerful and will continue to add features to help you debug.
Tip #4 – Test on Multiple Browsers
This seems like an obvious tip. Of course Firefox, Internet Explorer, and Chrome can potentially give you different visual results. Everyone knows that, but did you know that they may also give you different exception messages?
For example, I spent an amount of time that I would rather not admit trying to debug a message logged with Firebug. I tried and tried to determine what “javascript mozilla error invalid scope variables” meant. I found several threads complaining about the related bug in a JavaScript framework. The thread was solved and closed with no explanation. For a reason I can’t explain, I decided to try to debug the process in Internet Explorer. To my surprise, Internet Explorer and the Dev Toolbar gave me a message that made the issue obvious. Internet Explorer logged the message “property ‘name’ not available on ‘undefined’ object.” Ah hoy! There is a reference to a property on my view that doesn’t exist!
Yes, you should also test on other browsers for the obvious reasons. Everyone knows that!
Tip #5 – Use WebStorm for JavaScript Development
We all know what Eclipse and Netbeans has done to boost productivity for Java. My first several Java programs were written with Notepad. I felt like I got something accomplished when I got a task like organizing my imports finished. Can you imagine if you had to spend time on such a trivial item today? When first trying to develop with Backbone.js, I felt like I was back to using Notepad.
While some of the major IDEs lag behind on support for JavaScript and popular JavaScript frameworks, there are new IDEs like WebStorm with the sole focus of JavaScript. The newest version of WebStorm supports frameworks like AngularJS, Grunt, and Bower. Improvements have been made to RequireJS and AMD.
WebStorm brings you closer to the modern tooling era with JavaScript code completion and refactoring capabilities. At least with Java, if you changed the name of a method without letting the IDE refactor all the references for you, a compilation error will immediately be displayed. With JavaScript, an incorrectly refactored method will not be evident until the browser behaves unexpectedly. It does not fail as fast compared to Java. The time spent correcting the bad refactor will be magnitudes more costly. You’ll be amazed at the tool support an IDE like WebStorm offers the JavaScript environment.
Having an IDE that is a huge productivity booster makes you feel like you have fins to cut through the SPA water.
Tip #6 – Use a Code Quality Tool
My last tip is to use a code quality tool like JSLint to help confirm the code you are adding is a good part of JavaScript. It is very easy to write sloppy and hard-to-read JavaScript code. Anyone who has had to support Java written by someone who didn’t use a formatter or any code standard knows how hard it is to understand the intent of the code. JavaScript has the potential to be worse as browsers tend to be lenient towards JavaScript bad practices. Similar to how the number of Java class files increase in a Java EE application over time, the amount of JavaScript files will also increase rapidly with a SPA. The buildup of the bad parts will eventually create a tidal wave of issues that will be a nightmare to fight against.
JavaScript can be elegant, but it takes a lot of practice to consistently produce such code.
Does JSLint’s message of “Warning: JSLint will hurt your feelings.” make you actually feel better? I don’t like inflicting pain on myself, but I guess I can make an exception.
Is it a coincidence that JSLint recommends reading JavaScript: The Good Parts?
JSLint’s effect is like having a snorkel and goggles to help you see and breath easier no matter the depths of the SPA waters.
Final Thoughts
Since a large group of developers interested in SPAs have Java EE backgrounds similar to mine, I bring my journey to light as my mistakes are not unique. Hopefully, my journey and bruised ego may prevent others from following the same path.
If I would have used the tips above in my initial SPA swim from Java EE lands, the initial learning curve wouldn’t have been as steep. It isn’t easy transitioning from the Java EE paradigm. There are enough design considerations to keep in mind that make the transition difficult. Why make it harder and add understanding JavaScript to the mix? Understanding the features of JavaScript also helps in integrating the various JavaScript frameworks. With Backbone.js, there are frameworks like RequireJS, jQuery, Underscore, and possibly Marionette that must work in concert. AngularJS requires fewer frameworks to get up and running, but patterns are similar.
I now feel comfortable swimming in the SPA waters, but I’m not deep diving to find old shipwrecks yet. My bruises have healed and I’ve learned a lot in the process. I’m excited to keep exploring SPA and see where the journey takes me.
- John Hoestje, asktheteam@keyholesoftware.com
