The assumptions made often turn out to be wrong. What’s worse is that these choices may prove to be correct for a very long time before coming back to bite us. During this period of blissful ignorance, toolkits can become tremendously popular and become a vital part of large, complex codebases.
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. Traditionally, you would go out, buy an album, maybe from a band you knew, with a great album cover and a list of interesting tracks.
Perhaps the album was currently #1 in its popularity on the Billboard charts? Maybe you even sample a few tracks while in the music shop. However, once you got home with your CD and played it over your kick-butt, valve amplified, highly optimized sound system, you find out that it was mixed by someone who thought that no one listening on an MP3 player through cheap headphones would ever notice the low sample rate and removal of the bass! Instead of feeling like you are in the middle of a concert, you feel like you are listening to a band playing in a toilet over a phone. So the album was optimized for its look and feel while ignoring the foundational architecture needed to create an album that scales under the demands of a highly optimized stereo system!
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. In this post as part of our ongoing series about frameworks, we are going to explore in depth the ways in which frameworks enable an overall UX design.
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.
Probably the most common question we get asked as we get to know an organization is “What framework should I use?” No matter what some people would have you believe there is no straightforward answer. The answer though is founded in our typical response of “What are you trying to do?”
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!
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!
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.