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. Let’s take a closer look!
Last month we looked at various approaches to scaling enterprise development, and the challenges found within development organizations in our Time for InnerSource? post. This month we continue looking at the need for InnerSource by taking a closer look at the Law of Diminishing Returns.
dojox/gfx is Dojo 1.x’s vector graphics library, with support for SVG, Canvas, and other legacy rendering environments through a drawing API based on the semantics of SVG. This API also provides the foundation for dojox/charting. Often the biggest challenge in working with vector graphics is the large number of possible configuration settings and permutations.
TypeScript makes it easier to leverage auto-complete within an editor. We’ve been working for a while to add and maintain typings for Dojo 1.x. One of SitePen’s support clients kindly suggested that it would be very valuable to put gfx and TypeScript together, and happily sponsored our efforts in making this happen!
Over the past several months, the SitePen team has been hard at work on Dojo 2 along with the tools and infrastructure to support it. Part of that infrastructure, and one of the major priorities for Dojo 2, is to have top notch developer documentation, complete with examples, tutorials, and API documentation. The early fruits of this labor can be seen on the new dojo.io website.
For API documentation of JavaScript projects, JSDoc is a solid tool that gets the job done, and we wanted to be able to use something similar for TypeScript. JSDoc has support for type annotations in source code documentation comments, but this is redundant in TypeScript as the type annotations are provided in the code. We wanted to find a tool that was similar and a defacto standard, but that would take advantage of the TypeScript compiler API to derive the types of nodes.
While the SitePen team is widely known for its expertise in building JavaScript and TypeScript applications, providing support and training to enterprise teams, and for helping create Dojo and Intern, it also has a fair amount of insight and expertise with helping teams be more effective. Whether it’s Milestone Mayhem or InnerSource or just knowing how to keep software projects running smoothly, we’re often called upon to help organisations be more productive in modernising their approach to building applications.
Recently, we explored some of the habits that can sap the effectiveness of a developer. Even the best of us can get bogged down by challenges that make us struggle for too long. We believe that developers who better understand themselves and can identify these challenges before the bandwidth drain are more likely to be happy, satisfied, and productive. Do you recognise any of these bad habits?
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. However, much has changed since the early days of the web.
Back in the early 2000s, standards bodies attempted to codify features already implemented, and attempts to extend the web were often overly complex. The process typically occurred behind closed doors, usually with a few large companies attempting to push their technology agenda, with little opportunity for the public to participate in the process other than perhaps a mailing list. The collaborative tools we rely on today simply did not exist, and most browser implementations were not based on open source software. Simply put, it was difficult to make progress in that environment.
Here we’ll look at the non-technical side of the standards process, and how modern web standards are evolving in a more open and collaborative manner, leading to a better web platform.
As many of you know, Dojo 2 is being built on TypeScript. Many of us involved in Dojo 2 believe that TypeScript brings several advantages to developing with web technologies these days. Features like structural typing and interfaces help us write code that is less prone to errors as well as being able to express to those consuming Dojo 2 what the intent of the code is.
If you have worked with Dojo 1 for any extended period of time, you will realise how feature rich and complex the Dojo Toolkit is. Because of the power and backwards compatibility of Dojo 1, it can often be daunting, even for an experienced user, to effectively use Dojo. If as a developer, you need to utilise a new part of Dojo, it can be confusing to understand what part of the API to use and how to use it. I know from personal experience, I would often review the test cases for a part of Dojo I wasn’t familiar with to try to figure out what the intent of the original author was.
As we have continued to work on Dojo 2, several of us realised that TypeScript could offer a lot to Dojo 1, potentially allowing people to start to migrate code to TypeScript and ES6+, making their current code even better, but giving them an easier path to the future. In order to be effective at using TypeScript with Dojo 1, we need to do a bit of enablement.
InnerSource is a series of strategies and tactics from the open source world that help companies share source code across teams. While it might seem odd at first, it turns out that the things that work for well-managed open source projects are really helpful for businesses that want to encourage a culture of collaboration and reuse.
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.