As we create and improve open source software, and build many applications for our customers, we’re constantly looking for things that will improve the software we create. Part of this is looking at an often dizzying array of proposed and emerging standards, and finding those that feel efficient and ready for use.

Unless you have a time machine or a TARDIS, it’s pretty rare to have solid documentation in place before an open source project is released! While we’re getting close to a beta release with the Intern 4 and while we still have a fair amount of documentation and refinements to complete, a number of people

Test early, test often, and test some more. Why put our heart and soul into our web applications only to be let down because we are not completely testing them. Let’s explore how the different web frameworks approach testing.

Let’s figure out how to play our album. Is it a 45 vinyl or some sort of fancy SACD? Gaining insight into how we might develop and deploy an application built on a web framework helps us figure out if it is the right fit for our team.

As new user interface component frameworks are created and old frameworks are replaced with emerging technologies, methods for styling those components must change with them. Long gone are the days of creating a simple HTML component and importing a simple CSS file with corresponding class names.

Traditionally, engineers use mixins, decorators, inheritance, and plain code duplication to add common functionality to a handful of components. Mixins and decorators can modify the target object in such a way that you are never really sure what methods are safe to override without unwanted side effects.

Previously on Web Frameworks, we looked at how various frameworks deal with the concept of applications. Akin to listening to the whole album, we got a sense of how the frameworks pull it all together.

There are many reasons to like React. It provides a nice library for writing reusable components and leverages its own virtual DOM, abstracting away the obtuse native DOM APIs in favor of a simple method calls, which are further abstracted away with a JavaScript language extension, JSX.

Applications built with web technologies, something that was a curiosity a few short years ago, have emerged onto the scene as a must have for most organizations. Transcending websites and providing users with a more open and unbounded experience, web applications are everywhere.

Whether it’s Game of Thrones or an old season of Rupaul’s Drag Race, it’s pretty likely you’ll be streaming something tonight from your TV. Netflix, Hulu, Sling — these are the apps that dominate our quiet evenings.

As businesses expand into new markets and existing markets become more diverse, it is increasingly rare that enterprise applications can expect to serve speakers of only one language, with identical expectations for how they should be addressed or be presented data.

A significant amount of work on JavaScript toolkits and frameworks has centered around trying to fix, normalize, and optimize browser implementations. Doing so requires making many assumptions about what the problems are, how our tools will be used by developers, and what we expect of the future.

We have previously discussed the look and feel of web frameworks. While we often become interested in a framework based on the stylishness of the widgets and applications it can create, this may lead to a similar approach to how we have historically selected music.

The TypeScript 2.4 release might be a minor update in terms of not requiring substantial changes within our open source work and customer projects, but it provides some major benefits that we are already leveraging throughout the Dojo 2 codebase.

While instruments such as guitar and drums are part of a band, how they are used by the musicians define the style of the band’s music. Similarly, the elements of an application user interface connected together define the user experience.

Since we released Intern in 2013, the state of JavaScript testing has changed substantially. The JavaScript world was a very different place. Node.js was at version 0.8, and core modules like http were still being heavily developed! Popular tools like webpack, React, and TypeScript were still in the early stages of development.

Whether it is Top 40 or classical or R&B, artists and music have a recognizable look and feel. When looking at frameworks, some simply provide us with a bag of instruments, while others provide us with chord progressions and album covers we can customize.

…we would all be using justin-bieber.js. We as an organization have been working with JavaScript since 2000. We have seen frameworks rise and fall, including being responsible for some of them. We have seen trends come and go. We have seen browser dominance ebb and flow. We have seen winners and losers.

For a concise read on why the enterprise should care about using TypeScript in its applications, look no further than Remo Jansen of the Aon Centre for Innovation and Analytics’ presentation on the 6 reasons you should be using TypeScript.

As we noted in our post about the open and incremental approach to TC39, one of the challenges facing TC39 is that it has grown in size substantially along with the community interest in JavaScript.