Maintaining software is challenging. Stagnant software quickly becomes obsolete and this couldn’t be truer than in the JavaScript ecosystem.

SitePen participates in a number of conferences around the world presenting new technology and ideas to engineers and designers. Recently Dylan Schiemann and Tom Dye spoke at the HalfStack Conference in London and Paul Shannon spoke at Phoenix TypeScript meetup.

The CSS Paint API is a modern web platform feature to programmatically create images in JavaScript which are rendered to the page when referenced by CSS. You create images using the Canvas API, an API with which you may already be familiar.

For many front-end developers, components have become a central concept in their development workflow. Components provide a robust model for architecting and scaling complex applications, allowing for composition from smaller and simpler encapsulated parts.

Nest is a scalable framework for building server-side applications. It is authored in TypeScript and relies on the Express framework.

At the recent TSConf, SitePen engineer Sarah Higley delivered a talk titled Escape the Office: Designing Interfaces for Other Developers. The moment you step into any large project or open source venture you must accept that code you write gets used in ways you did not originally intend.

WebAssembly is an emerging standard for a low-level assembly-like language in a compact binary format that runs with near-native performance, and is available as a compilation target for a variety of languages. We’ve heard significant misunderstanding around WebAssembly and what it means for the web and JavaScript.

Intern Recorder is a Chrome extension that can kickstart the process of creating functional tests for Intern. It was initially released in 2015 users of Intern authored test suites as AMD modules.

Intern is a popular JavaScript testing framework with an extensive feature set. While Intern has traditionally been focused on testing applications written in standard JavaScript, it has also had great support for TypeScript.

It has come time to read the liner notes and write some conclusions. When we started writing this blog series, we knew that JavaScript/web application frameworks were not easy to summarize.

It is like the old proverb, “It takes a village to raise a web framework.” As we explored in the previous post, choosing a framework goes beyond the technical features of a framework and this is certainly true when it comes to the wider community, which includes considerations like licensing, how open the framework is, and where to turn for education and support. While each web framework we have been discussing is an open source framework, there is a wide spectrum of what that actually means and how it affects the use and future development of a framework.

Many modern web applications depend on JavaScript. When the complexity of your JavaScript increases, so does the maintenance cost.

For a web framework to be effective, it should offer you more than just functionality. It doesn’t matter how much hard work you put into your application if it breaks when people use it.

Over the past year we’ve been heads-down working hard on Dojo 2 and its component architecture. The ability to change default component behavior is essential to a widget library, and several tactics exist for doing so.

Angular is an application framework favored by many in the JavaScript community. Angular provides a library for building encapsulated components, dependency injection, a templating language with data binding, an application router built on observables, and a command line interface that lowers the barrier to entry.

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 have started using Intern 4 to leverage its support for easier testing with modern ES6+ and/or TypeScript features. Intern 4 has many benefits and improvements over Intern 3 and previous approaches to testing.

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 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.

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.

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.

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.

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. The SitePen engineering team has been using TypeScript since it came onto the open source scene 5 years ago.

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. ECMA has started to address this by creating a few additional standards bodies for sections of JavaScript that can be decoupled from the core language.

TypeScript 2.3 is the latest version in the quarterly release cycle from the TypeScript team. This release contains several useful additions to TypeScript which we have already started to leverage within some of our current projects.

In our recent post about the key features in ES2017, I was reminded just how much the standards process has changed in the past 15 years. As someone who tried to get involved early to improve standards, the process was broken and I was quickly discouraged.

As we near the finalization of the proposal, it’s looking like ES8 is going to deliver much more than the simple updates of its ES7 predecessor! We wanted to take a few moments to highlight our 5 favorite things about the upcoming 2017 release. This change is one we’re very excited about, and something we’ve already shimmed in Dojo 2.

Functional programming and reactive programming principles are not new to JavaScript, but their adoption has recently become widespread across most modern frameworks and toolkits. The ease of using these approaches has improved as we’ve finally seen the decline of legacy browsers, and as we’ve seen the introduction of functional and reactive paradigms within ES6 and ES8.

The TypeScript team recently announced the TypeScript 2.2 release candidate which will contain key improvements to the TypeScript language. Most notably, are the introduction of the object type and improved support for mixins and composable classes.

The motivation for Intern 4 is to make it easier to author tests with ES6+ features within tests, with or without transpilation. Want to skim? Here’s the Intern Roadmap which lists our high level status for each Intern release going forward.

As the new year starts to unfold, it’s time to take a quick look at the things our team at SitePen resolves to do this year. Too often, we see large enterprise customers who have multiple teams creating the same features, without having a simple way to share and maintain code over time.

Thanks to a generous Mozilla Open Source Support program award, Intern has expanded its testing ecosystem to include new and robust sets of tools. Engineers can now easily write tests to benchmark sections of code, test for accessibility (a11y) support, and test for visual differences.

Over the past few years, TypeScript has iterated and greatly improved developer ergonomics. With our efforts on Dojo 2, we’ve been very excited about many of the features and improvements made, including several key improvements that have landed for TypeScript 2, which is currently in beta release! TypeScript 2 adds a major improvement in the type analysis of code.

FullStack is a large London JavaScript conference hosted at the Skills Matter CodeNode. The conference brings together an impressive line-up of speakers and workshops covering five tracks over three full days of festivities.

In this installment of our series on building web applications, we look at the SitePen approach to solving challenges in web application development. We employ all of the solutions described in part 2 of the blog series.

While there are many challenges today with building web applications, there are also many options to address the issues we face with technology, process, and people, allowing us to reap the benefits of the web as an application platform. While many of the challenges with today’s web applications come from the vast array of technologies that are available, there are clear strategies that can be employed to turn those same issues into advantages that can make building applications easier.

Web applications provide many benefits. Most organizations seek to improve the efficiency and effectiveness of business processes through the use of software.

Peter Higgins, former project lead for Dojo, gave an excellent talk at JSConf in 2013 titled “Dojo Already Did That” (which reflected a humorous meme started at the first JSConf). It was highly informative about how Dojo had already solved problems that the JavaScript community were solving again in 2013.

Symbols are a new, unique, primitive type introduced in ECMAScript 6 (ES6). They were added to the language in order to solve the problem of extending the functionality of Object while maintaining backwards-compatibility with code written in earlier versions of JavaScript.