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. In this post, we explore what are common types of applications and how the frameworks we are considering might work in those use cases. If you are going to throw a party, you want to know if your favorite band is going to set the right mood.
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. Likely the main reason you are reading this series is to determine how modern frameworks enable you to build web applications.
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?”
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?
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.
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.