JavaScript for Line of Business Applications

There is no doubt that AngularJS – the self-proclaimed “superheroic JavaScript framework” – is gaining traction. I’ll refer to it frequently as just “Angular” in this post. I’ve had the privilege on working on an enterprise web application with a large team (almost 10 developers, soon growing to over 20) using Angular for over half of a year now. What’s even more interesting is that we started with a more traditional MVC/SPA approach using pure JavaScript and KnockoutJS before we switched over to using the power-packed combination of TypeScript and Angular. It’s important to note that we added comprehensive testing using Jasmine but overall the team agrees the combination of technologies has increased our quality and efficiency: we are seeing far fewer bugs and delivering features far more quickly. 

If you are familiar with Angular, this post may give you some ideas to think about you hadn’t encountered before. If you know Angular and are trying to justify its adoption at your company or on your project, this post can provide you with some background information that may help. If you have no idea what Angular is, read on because I’ll share why it’s so powerful and then point you to resources that will get you up to speed, quickly. 

I can only assume other organizations are seeing positive results after adopting Angular. According to Google Trends the popularity of AngularJS (blue) compared to KnockoutJS (red) and “Single Page Applications” (yellow) is exploding. 

So you love the way single-page apps like Gmail and Trello feel, but aren’t sure where to start.  Maybe your JavaScript code has become disorganized enough that you are convinced to try one of the numerous  JavaScript MVC libraries/frameworks on your next project but aren’t sure which one to choose.  I’m writing  a book on single-page apps so I’ve pretty much “read the internet” on the topic.  I’ll attempt to provide some not so obvious insights to help you make your decision.

The frameworks discussed are the ones with the most traction at present AngularJS, Backbone, Ember, and Knockout.  Batman, CANjs, Meteor, and Spine are also mentioned but not covered in-depth.

Each project is examined from several different perspectives including community, leadership, maturity, size, dependencies, interoperability, inspiration, philosophy, and features.

Originally it took me a while to get on board with using Bower as part of my main development workflow. My biggest gripe was the way it handled repositories that were missing a bower.json file to configure ignored files etc.
In that scenario the whole repository is installed into the bower_components folder and although there are two sides to it, checking that fluff into my Git repository doesn't feel right. That is of course, until Grunt came along.

Like most of life's problems, Grunt can help.
The process goes a little like this:
* Instructing Git (or your chosen VCS) to ignore the bower_components folder
* Checking for and installing any updated packages
* Copying the required files across into a directory that gets checked in to the VCS

By selectively copying files this way our repository can be kept free from test folders, READMEs and other cruft.

If you then needed to update jQuery to the latest version all it would require is changing the version number in the bower.json (or by installing it on the CLI), running the Grunt task and then committing the updated files to the repository. No manual downloads or file copying required.

Our goal was to provide a library to our customers that is modular, lightweight and supports browsers from IE8.

It is common sense. Your growing codebase will be harder and harder to maintain it, period. But if you have modules created for one purpose and one purpose only, and they are covered with tests your life will be happier.

And so the evolution of front-end development continues with Gulp, the new build system that has already garnered praise amongst many web developers.

After spending some time reading the docs and playing around with Gulp, I’ve finally decided to test its adoption in an existing project that currently uses Grunt. From what I’ve seen so far, Gulp is blazingly fast when compared to Grunt for similar tasks.

Let’s dig a bit deeper though, and get a little understanding of the differences between Grunt and Gulp, beyond superficial speed comparisons.

In this post we’ll cover:

* A shallow dive into Gulp, and how it compares with Grunt.

* Things to consider when choosing between the two tools.

As you might now react.js is a framework to create user interfaces in a web context. What is special about this? Is amazingly fast! (and supports server-side rendering) But has a downside, which requires you to change the way you think about web interfaces (see above).

There are a lot of tutorials about react.js but almost none, or very hard to find, in pure JavaScript. They all use the react.js special syntax. But I don't want to have another javascript pre-processor between each code change so this is the main reason.

The most complicated part of understanding react.js was how exatly the arguments passed in the components, and which ones can change and which can't...

Over the holidays I have discovered Facebook’s React, an interesting library for generating reactive user interfaces. I wanted to try it out in a real-world application, which reminded of one I still had running as a demo: sse-chat, a little chat application I wrote last summer for learning how to make Play Framework and AngularJS cooperate in a very basic way. So I thought, why not rewrite the client side using React, offering the exact same functionality as the AngularJS version. Both are available at the same time in the new version, with no changes to the backend code, except for the added route as both versions can be accessed in parallel.

The contraint of making it behave exactly like the AngularJS version was a great exercise and it really only took an afternoon to complete. Touching the existing demo version also had me notice that the live version of it had been up for like 4 months or so, without any trouble. I have the same experience with my BirdWatch application. Kudos to the Play Framework developers for that, and same for Akka, which provides the supervised Actor architecture presumably enabling such reliable server systems.

Learn JavaScript programming from scratch and fast. This web development series focuses on client side JavaScript from the client-server model. The first part of the series teaches basic software development concepts, such as variables, data types, logical operations, functions, classes, etc. Later you will learn how to program DOM scripting, cookies, sessions, and other advanced HTML5 techniques. The apps and examples shown will be executed in the best modern web browser I know: Google Chrome. However, you can follow along with your favorite browser, be it Firefox, Internet Explorer, Opera, or even Safari.

Once you become an expert JavaScript programmer, you'll be able to develop 2D games from scratch. That's right! Web development is that awesome. Just keep in mind that the Java language is not at all related to, or the same thing as EcmaScript, even though they share similar names.

Let me start by saying that Microsoft wins the overall dev productivity competition hands down. Visual Studio is an absolutely top-notch, amazing IDE, and there really is nothing that can compete with it in the overall category. On top of that, Microsoft has produced some top shelf Web dev tooling over the years. There really is no doubt about that, but there is always room for improvement.

The Web, in particular, presents a very challenging, wild-west environment for tooling. The technologies in themselves don’t lend themselves well to that, and there are all sorts of hacks and workarounds to address the problem, including some produced by Microsoft. To be a guru in Web dev requires mastery of so many different moving pieces and nuances, multiple, not-very-well-defined languages, innumerable libraries and frameworks, and a vast number of potential runtime environments. It’s a hard egg to crack when it comes to productivity tools, not to mention just general dev productivity, defined as time spent actively producing value-adding software assets.

Previously, I talked about some tips and tricks I use with Grunt.js. If you haven't heard of Grunt.js you may want to check out my article on the basics of grunt. This time I want to wrap things up by talking about custom tasks in grunt. While there are a lot of great plugins for grunt sometimes you need something custom, lucky for us grunt makes it easy for us to define our own tasks.

Grunt.js provides two types of tasks: Basic Tasks and Multi-Tasks. Basic Tasks are little more than a named javascript function you can run from the command line. Multi-Tasks are what most plugins provide, you provide a namespace and code to run those tasks, then the user creates instances of that tasks by placing options under a config object of the same name.

Function binding is most probably your least concern when beginning with JavaScript, but when you realize that you need a solution to the problem of how to keep the context of this within another function, then you might not realize that what you actually need isFunction.prototype.bind().

The first time you hit upon the problem, you might be inclined to set this to a variable that you can reference when you change context. Many people opt for self, _this or sometimes context as a variable name. They’re all usable and nothing is wrong with doing that, but there is a better, dedicated way.