Blog

Apr 18

7 habits of highly ineffective developers

By on April 18, 2017 7:07 am

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?

Mar 29

What TypeScript can offer to Dojo 1.x

By on March 29, 2017 7:24 am

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.

Aug 24

The long and winding road to Dojo 2

By on August 24, 2016 10:46 am

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. It has taken Dojo 2 a long time to get here and to really solidify our vision. We first started brainstorming about plans for 2.0 almost 5 years ago! Around a year ago we solidified our plans and have been unwavering in moving down that path.

Jun 9

Dojo is Doing it Again

By on June 9, 2016 12:34 pm

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. Even 3 years later, there are a lot of modern solutions that were solved in Dojo 1.

Apr 7

On the leading Edge

By on April 7, 2016 12:55 pm

Microsoft Edge Web Summit Logo

I attended the Microsoft Edge Web Summit in San Francisco. I will be honest, outside of meeting a few people, I wasn’t expecting much. Instead, I found myself face-to-face with the “new” Microsoft. I have grown accustomed to the openness and true collaboration that the TypeScript team have engaged in, but I wasn’t expecting seeing this mode infecting cross-pollinating the rest of the company. What I saw was far from a marketing ploy. It felt as if Microsoft was going through a revolution from the inside out.

Nov 6

Death of Object.observe()

By on November 6, 2015 9:47 am

flight

Adam Klien, software engineer at Google, announced on ESDiscuss that they were withdrawing the proposal to implement Object.observe and plan to remove it from V8 by the end of the year.

While I was never sold on the approach of this API, I assumed long ago it was the API that would be used for data binding to plain old JavaScript objects. I am also surprised because I was discussing the state of Web Components with a member of TC39 just a few weeks ago. While I listed all the parts of Web Components that are in V8/Blink but not elsewhere, including Object.observe, they assured me the other browsers would eventually implement the rest of Web Components. I also missed that Polymer 1.0 abandoned Object.observe.

Nov 3

FullStack Conference Recap

By on November 3, 2015 8:10 am

I had the opportunity to speak and attend FullStack 2015 organised by Skills Matter and hosted at their CodeNode location in central London. It was a great experience and it’s clear that JavaScript is everywhere and permeating every aspect of technology today! It was no surprise that ES6/ES2015 and TypeScript were popping up in every conversation. Even at a full-stack conference, the front-end seemed to get a lot of focus, most likely because everyone is challenged with improving the web experience.

Oct 8

Stronger JavaScript?

By on October 8, 2015 8:23 am

The V8 team (the JavaScript engine that powers Chrome, Opera, Node.js, MongoDB, etc…) are moving forward with an experiment in defining a stronger version of JavaScript that ensures that code being run is behaving well, and introducing run-time typing based on TypeScript’s typings. V8’s motivation is always performance, and a more stringent set of ECMAScript would obviously allow them to tune the engine to streamline performance, but are there other benefits?

Sep 29

Code Coverage for TypeScript and Other Transpiled Languages

By on September 29, 2015 11:01 am

Transpiling or compiling code has become a necessity today for JavaScript-based web development. Whether you are using TypeScript, Babel, Dart, Traceur, or CoffeeScript to provide additional language features, or trying to optimise your code with the likes of UglifyJS, r.js, or Closure Compiler, once you have modified your source code, you start to run into challenges.