Welcome to this review of the Pluralsight course Large Scale JavaScript on Client and Server by Shawn Wildermuth.

I am not going to go quite as in depth in this review as I do for some other courses. Do not think that this has anything to do with the quality of the course. The only reason is I watched this course a couple of years ago and would prefer to give a quick summary than rewatch the whole course again.

This course is 2 hours 49 minutes so is a little shorter than average and covers many very important topics for JavaScript developers.

It is one of the intermediate level courses in the Node JS Learning Path

What is Large Scale Javascript?

Large scale tends to be subjective, but that doesn’t prevent us from using good technique throughout our development.

JavaScript alone isn’t up to the challenge of large scale problems.

JavaScript must be written in a rigorous way, and good development practices solve many of the ills of large scale JavaScript.

The three keys that will be the theme of this course are:

1. Maintainable
2. Scalable
3. Testable

Frameworks and meta languages can help, but they must be backed up with good development practices.

Maintainable JavaScript

This module covers techniques for creating code that is more maintainable over time.

• Avoiding Global scope means we have one less collision to worry about
• Using strict mode will help highlight errors earlier
• Structuring your code into modular units will increase stability
• Injecting dependencies allows us to not handle the wiring up of dependencies
• Abandon nested callbacks in favor of promises and async patterns
• Use eventing and messaging to loosely couple your modules.

Before anyone begins a large scale JavaScript, it is important to know that the team understands how to write clean code.

The JavaScript Best Practices course covers the benefits of strict mode at length and I also recommend checking that out.

You can also find more information on Structuring JavaScript code from Dan Wahlin.

To learn more about Asynchronous Javascript see Wes Higbee’s Reasoning about Asynchronous JavaScript.

Scalable JavaScript

This module covers techniques for JavaScript that scales well.

• Knowing you have a problem is the first task
• Focusing on better code will make your application scale better
• In most cases being lazy about how we are executing our code is the best approach
• Minification will help you improve performance of downloads and parsing
• Only loading the JavaScript required to do the job is crucial
• Late loading JavaScript as it is needed is another useful technique

Testable JavaScript

This module stresses the importance of unit testing our code.

• Event-driven, nested JavaScript is hard to test
• Too many mixed concerns are a problem to testing
• Maintainable and Scalable JavaScript should be easy to test
• Unit testing is critical, but don’t get bogged down with dogma of process (are TDD or BDD etc)
• Jasmine and GruntJS are a great combination to simplify this
• Automating running unit tests can speed up your overall testing

I have been using Jasmine for a couple of years now, however Mocha and Ava are two popular alternatives that you may want to check out.

See Testing Clientside JavaScript for details on QUnit, Jasmine and Mocha.

Mocha is used in Cory House’s course Building Applications with React and Redux in ES6

Gulp and NPM Scripts are alternatives to Grunt JS which many people prefer today.

Jeff Valore uses Grunt JS with Browserify in his course Creating JavaScript Modules with Browserify.

Finally Wes Higbee has a course on Seamless JavaScript Testing with Wallaby.js

Large Scale JavaScript in Node JS

• Node is a great solution for server-side development when you have JavaScript skills
• It isn’t magically suited to large scale projects (as with other server-side technologies)
• Still needs to be Maintainable, Scalable and Testable
• Modularization and CommonJS are keys to maintainable JavaScript on the server
• For scalable JavaScript, understand the runtime environment and optimize for the V8 engine.
• You still need to test your code, even if its just on the server