JavaScript for Line of Business Applications

I recently introduced you to JavaScript generators which I think are a really interesting feature that we should look at for the future of JavaScript. In that blog post I was talking about LINQ in JavaScript and kind of glanced over an important part of generators, and that's how you use them if you're not using a for-of loop. While generators make a lot of sense in the scope of managing datasets that isn't their only usage, in reality generators are quite useful if you want to lazily execute any function.

Copying all properties of one object to another one is a common operation in JavaScript. This blog post explains ECMAScript 6’s implementation of it, which is calledObject.assign().

This merging operation has a name in the JavaScript ecosystem that is only used there (and, unfortunately, clashes with classic OOP terminology): “extend”. 

This function copies all enumerable [1] own operties from source to target. It returns the (modified) target. The exact signature of the function is still being debated, there may eventually be support for more than one source. 

Koa is a new application framework for Node.js. Its whole point is to eliminate the callback madness that plagues many Node.js apps. It achieves this previously-impossible feat by using the powerful generators feature which is new in JavaScript ES6. Koa is built by the same people who created Express, the best-known Node.js application framework, so it’s at least worth a look.

Having written plenty of callback-heavy JavaScript, I was excited to give this thing a go and see how much simpler it could make my code.

This blog post is purely about generators and async in Koa. If you want to actually build an app with Koa, go and read the framework’s website. If you’ve never used Express (the earlier incarnation of Koa’s ideas) then be sure to learn aboutmiddleware, the central architectural pattern in Koa, so you will see how the framework intends your application to be organised.

A quick walk throught the fresh ES6 modules spec coupled with the front MVC framework EmberJS.

The ES.current as we know it doesn’t feature a standardized module system, you cannot require some fragment of code inside another fragment of code and use it while being inside a namespace (and not a global). AMD and CommonJS came along and proposed two impressive yet incompatible solutions to let developers use modules (AMD is mostly used in the browser, while CommonJS is more used server-side). The new ES6 modules spec aims at solving this module problem and also let ES6 modules transpile to both AMD and CommonJS as a polyfill.

The ES6 modules spec is done and will not change before the ES6 specs release, we can now use it and feel safe about the new semantic we learn.

This an introduction to ECMAScript 6 modules and how they can be used in current browsers. In contrast, this blog post explains how future browsers will support them natively. As part of that support, we will get the <module> tag, a much better version of the <script> tag.

The main advantages of ECMAScript 6 modules compared to current module systems are: Their syntax is more elegant (than even Node.js modules), they work both synchronously and asynchronously (without an extra compilation step), and they unify the JavaScript module landscape.

There are many design patterns used in Javascript and I would recommend taking a look at Javascript Patterns by Stoyan Stefanov for a full introduction to the most widely used patterns. Of the design patterns available, the Module pattern has gotten the most recognition in the past few years thanks in part to the maturation of the module pattern via commonjs as well as the wild success of node.js.

In a nutshell the module pattern allows you to create code that can expose a public API while safe guarding private variables and methods behind a pseudo blackbox.

We’ve looked at the basic Module pattern and seen how to use it to create some really powerful Javascript. We then took a look at how AMD works and how we could easily change our code to build our modules following the Commonjs specification for asynchronous modules, lastly we took a look at the bleeding edge harmony modules specification. I find that it is easy to see the beauty of where ECMAscript 6 is heading, with respect to modules, when you take a look back at where we’ve already been and how we’ve evolved up to this point.

ECMA5 has given JavaScript a number of new ways to define and manipulate objects. In this session, attendees will learn how to combine Require.js and ECMA5’s object manipulation functions to create an inheritance model similar to class-based languages.

The ECMAScript Internationalization API is a standard JavaScript API that helps with tasks related to internationalization: collation, number formatting, date and time formatting. This blog post gives a brief overview and points to more reading material.

The specification of the ECMAScript Internationalization API is edited by Norbert Lindenberg. It is available in the formats PDF, HTML and EPUB. Additionally, there are several comprehensive introductory articles...

* Collation
* Number formatting
* Date and time formatting

ES6 is coming and with it brings many great things that will help us develop better and faster web applications. Let’s have a look at the most significant ones.

In ES6 there is a lot of syntax sugar that will shorten development time and speed up our applications. Let’s have a taste, shall we?

Finally, ES is turning into a true object-oriented language. With the introduction of classes, we can write our code in a clean and structured way. It will remove the need for the current coded solutions present in nearly every popular library...

* Syntax Sugar
* Classes
* Modules
* Maps and Sets
* Iterators
* Weak Maps
* Proxies
* Template Strings
* Conclusion

Latte is a superset of JavaScript with lots of useful extensions. Get the power of CoffeeScript, but keep the syntax you know and love.

* Let Statement
* Functions
* Arrays
* Monads

JavaScript is single threaded, meaning that two bits of script cannot run at the same time, they have to run one after another. In browsers, JavaScript shares a thread with a load of other stuff. What that stuff is differs from browser to browser, but typically JavaScript is in the same queue as painting, updating styles, and handling user actions (such as highlighting text and interacting with form controls). Activity in one of these things delays the others.

* What's all the fuss about?
* Events aren't always the best way
* Promise terminology
* Promises arrive in JavaScript!
* Browser support & polyfill
* Compatibility with other libraries
* Complex async code made easier
* Promisifying XMLHttpRequest
* Chaining
* Error handling
* Parallelism and sequencing - Getting the best of both
* Promise API Reference

We live in a fluid world. I first started hearing about HTML5 several years ago now, and I’ve been using it for at least two, yet it won’t be officially ready until next year at the earliest. While HTML is making great strides, another leg of the stool is progressing nicely as well. New Javascript features are coming, outlined in the standard known as Ecmascript 6. Though it’s not finalized, it is approaching stability and implementation is coming along in various forms.

You’ve probably heard about some of the cool features on the way, like module support, classes and a bunch of syntactic niceties, but you might not have had a chance to try them. 

An often overlooked piece of JavaScript examples, tutorials and discussion is the writing of libraries/modules.

While there is a vibrant community of people writing UI centric jQuery Plugins with a de-facto style and methodology, paging through Github repositories of the many libraries, frameworks, plugins, etc will show an extremely disparate set of coding styles and methods.

As more and more browsers support experimental ES6 Module Features, and others use transpilers to write in ES6 transpiling to shim'd JavaScript/ECMAScript5 which export to AMD format & client-side JavaScript becomes even more complex and large, users will use module style coding as the standard.

Regardless of whether or not you want to support CommonJS, RequireJS/AMD or just write a library which aliases its' constructor or main method/object to the window: anyone could benefit from writing small, testable and compartmentalized modules.

In this post, I’m going to take a close look at how JavaScript’s prototypal inheritance works by analysing how Microsoft’s TypeScript language uses it to provide a simple implementation of classes. Don’t worry if you’ve never used TypeScript, we’re not really concerned with the language itself here, just the JavaScript that is produced by its compiler, and how it achieves class-based inheritance in a language that doesn’t natively support it.

This is of particular importance because EcmaScript 6 will include classes that work a lot like TypeScript’s. The idea of adding classes to JavaScript is controversial, but I think some of the hostility stems from a mistaken belief that classes are some kind of competing inheritance mechanism to prototyping, or are an attempt to turn JavaScript into Java. In fact, modern proposals for classes in JavaScript are just a syntactic codification of prototypal inheritance patterns that are already in use.