Category: ES6

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. It leans heavily on modern language features such as async/await and decorators to reduce cruft and place the focus cleanly on route-handling business logic.

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. With version 4, Intern has been completely rewritten in TypeScript, allowing it to provide a more seamless testing experience for TypeScript projects.

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.

Many modern web applications depend on JavaScript. When the complexity of your JavaScript increases, so does the maintenance cost. To improve the maintenance of complex JavaScript codebases, you most likely adhere to some clean code practices in your codebase.

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. Beyond testing, let’s explore how frameworks can help us build better code before we test 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

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.

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

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.

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

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.

Recently on GitHub, someone accused Dojo 2 of being vapourware. This opinion came from a position of misinformation. I was glad the individual then engaged with the Dojo 2 project to understand where we are today. We are making swift progress and a beta is on the horizon.

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. We were invited to speak at FullStack, and also enjoyed many of the other sessions and met many great engineers.

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. Additionally, we have some overarching principles we apply to our work.

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.

Web applications provide many benefits. Most organizations seek to improve the efficiency and effectiveness of business processes through the use of software. The benefits of web applications include: Simple distribution model for end users (e.g. no installation required) Instant propagation of changes Unified code base to support many platforms (desktop, tablet, mobile, etc.

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.