What goes into a blog post? Helpful, industry-specific content that: 1) gives readers a useful takeaway, and 2) shows you’re an industry expert.
Use your company’s blog posts to opine on current industry topics, humanize your company, and show how your products and services can help people.
I had the privilege to talk at FITC Web Unleashed today and it was a fun experience. I demonstrated the insights provided by Augury Labs’ Performance Profiler plugin to help tune the performance of Angular applications. I also gave an overview of the architecture and some hints about the future of Augury Labs. Unfortunately the video is not up yet, but here’s a link to the Debugging Performance Issues in Angular Apps with Augury presentation page.
I’m so excited I got to talk about Augury Labs during last night’s AngularTO. It’s an experimental instrumentation and inspection framework for Angular applications that is installed through a set of npm packages. In this talk I demonstrate the insights provided by Augury Labs’ Performance Profiler plugin, which can help you tune the performance of your applications. I then give an overview of the architecture and some hints about the future of Augury Labs. After my talk, Jason Jean from Nrwl talks about Building Large Angular Apps Successfully with Nx. I hope you enjoy!
Originally posted on Rangle.io: Five Things to Consider Before Choosing Micro Frontends
The idea of micro frontends is all the rage right now. It’s been gaining traction over the years, and we’ve noticed more clients asking us about it. Although it’s an incredible solution for a lot of use cases, it can be cumbersome if your organization’s expectations are not properly set. Here are five considerations to help you determine if the micro frontend idea is right for your needs.
Before jumping in, let’s have a quick review of what micro frontends are. There are many different approaches and definitions. However, the one we’ll consider in this article is from micro-frontends.org.
Stay up to date on what’s happening in the digital transformation space by signing up for our newsletter, here.
Micro frontends are distinct vertical slices of a web application that encompass the frontend, backend service, and database. This enables you to break down a monolithic web application into microservices.
On the frontend you can use Angular Elements, Stencil, Polymer or Nutmeg to create a Custom Element, which is a custom HTML element that loads your component.
On the backend, the component will communicate with its very own HTTP API service and a database specifically set up for it.
You can use this concept to tie different technology stacks together as well. For example, one component could use Angular, while another uses React at the same route on the frontend. Sounds straightforward and useful, right? However, there are a few nuances that you should know when considering whether to choose micro frontends.
Micro frontends enable teams to develop and deploy features end-to-end from UI to DB on large web applications, faster. An independent team can own and maintain a component slice without worrying about sharing technology or a release process with other teams. That means when a team uses components from other teams, all they need to know is the custom HTML element and its attributes.
<mi-account data={[[40], [50], [50]]} headings={["Account", "Balance"]}> </mi-account>
Furthermore, companies with multiple teams each using a different frontend framework can create a unified component library. For shared code like CSS, the DOM, events, local storage, and cookies, teams would agree on a namespace convention to avoid stepping on each other’s toes.
Some of the benefits are lost when there is only one small team working on the web application. In fact, the overhead created by micro frontends makes it harder for a team to manage components. A developer would have to switch to a different coding and deployment practice for each component slice they work on, which results in context switching and slower development. Although the team could establish common practices across components, there is a risk of components deviating. There may still be benefits to using micro frontends with a small team of developers.
“The thing is, the Frontend Platform team can’t just disappear for 6+ months and come back with a shiny new environment. It is too risky.” – Ben Ilegbodu
Breaking up a monolithic application into micro frontends may help to change technologies for an existing application. The team could deliver value incrementally by launching portions of the application without racking up much technology debt anytime there is a change in the existing application.
Micro frontends require all frontend code relating to a component to be contained within the Custom Element. Therefore, it relies on the DOM (element attributes and events) to pass information across components, as opposed to a shared library like a publish/subscribe system. The DOM is the API.
When a parent component wants to communicate to its child component, it makes sense to use element attributes to pass data. This is also known as the declarative approach and React always uses it when passing data to a Custom Element. However, this could create problems for complex data like objects or arrays, especially because you need to stringify them. It is expensive, and any object references will be lost.
<mi-account data={[[object Object], [object Object]]}> </mi-account>
When a child component wants to communicate to a parent or sibling component, it makes sense to dispatch custom browser events. However, DOM events require more work when using React.
React uses its own event system and cannot directly listen for native DOM events coming from a Custom Element.
One fix for both problems mentioned above is to reference the element using the ref attribute and attaching event listeners to it.
<mi-account ref={el => el.bar = baz}> </mi-account>
The approach seems unnecessary because it prevents the use of Javascript properties for all attributes. There are a few proposals on how to support Javascript properties by default for React 17, but nothing is yet announced.
Since micro frontends isolate the code of each component, they allow teams to convert, update or scale components incrementally without a significant upfront investment. Technically everything could be a component, even the parent element. In the below illustration of the Mi Bank sample app, the thin parent component calls several child components to build out the page. The child components can be further broken down into highly reusable shared components that can be part of a core component library and shared across the team.
| Thin parent component | ||
| Child component (account) | Child component (investment) | … |
| Shared components | ||
In this model, there would be a team assigned to the parent component: one team assigned to each child component, and maybe another team assigned to shared components.
An alternative solution is not to take the purists approach to micro frontends; not everything has to be a web component. For example, we can eliminate the thin parent component and have a team responsible for the whole web app, except for a few child components. Each child component is a distinct vertical slice of the web application that encompasses the frontend, backend service, and database. This enables a team to break down a monolithic web application into microservices without being too granular.
| Web app | ||
| Child component | ||
| Shared components | ||
Should a team use React, Angular, or Vue for the frontend of a particular component? There are pros and cons for each, and there are reasons why one library or framework fits better in a situation over the others. I’m not going to get into that debate here. Regardless of your choice, keep in mind you are choosing the frameworks so that you can build your web application; you are not building the web application just so you can use the frameworks. As Evan You said during his presentation at Rangle.io’s Vue meetup, the complexity of the libraries and frameworks you use should not overshadow the complexity of the overall web application.
Just like with any architecture, the users will benefit from reducing the number of libraries and frameworks you are loading on the client-side.
Adding another framework, the user experience will become slower due to the additional load. Whenever possible, the teams should mutually agree on using the same JavaScript framework. On the other hand, the time-to-market benefits of an offshore Angular team might be lost if they try converting to React to align with the highly skilled in-house team for example. A slower time-to-market may result in a worse user experience compared to the additional load from a second framework.
Let’s assume the teams can agree on the same JavaScript framework. Great! Now the teams need to decide if they’re gaining efficiencies on development and deployment from the independence that comes with using micro frontends.
For perceived performance optimization, implementing Server Side Rendering (SSR) with Progressive Enhancement for your frontend application is generally recommended, especially when improving SEO is a goal. You can continue the spirit of SSR with micro frontends by incorporating your Custom Element using Edge Side Includes (ESI). ESI can even support personalization.
For some organizations, there might be barriers to implementing a full ESI solution, and SEO might not be a concern for their applications. In these cases, Client Side Rendering (CSR) is the better choice. The micro frontend Custom Element can be loaded using AJAX. This approach can cause layout jumping issues, especially if the loading content changes the initial structure of the page. A skeleton UI can help keep the structure of the layout before content is loaded.
The micro frontends approach is a great technique to help divide the workload for multiple teams and to isolate code for each Custom Element. Due to the extra overhead, the considerations in this article will hopefully help before deciding to use this technique. It might not be a good idea to opt for the added complexity before you actually need it!
Interested in learning more about micro frontends? Follow this link to a recording of our webinar, ‘The Key to Scaling Single Page Applications’.
Originally posted on Rangle.io: What to Expect in Angular 6 and Beyond
Having recently attended ng-conf 2018, where the Angular core team announced that Angular 6 is “dangerously close to release,” I wanted to write about the exciting features we can expect.
There has been lots of chatter about Angular Elements since Rob Wormald spoke at Angular Connect last November. There will finally be a fully supported Angular Elements version in Angular 6.
Angular Elements allows you to use Angular components in non-Angular apps. After you build your Angular component and generate your ngfactory file, you can wrap it inside a Custom Element with only a couple lines of code.
// The my-popup.ngelement.ts file
import {platformBrowser} from ‘@angular/platform-browser’
import {MyPopupModuleNgFactory} from ‘./my-popup.module.ngfactory’
import {MyPopup} from ‘./my-popup’
import {createCustomElement} from ‘@angular/elements’
platformBrowser()
.bootstrapModuleFactory(MyPopupModuleNgFactory)
.then(({injector}) => {
const MyPopupElement = createCustomElement(MyPopup, {injector});
customElements.define(‘my-popup’, MyPopupElement);
});
The result is a JavaScript bundle (my-popup.ngelement.js) for your component. And then all you have to do is import this script and use the component just like any other DOM element. You can load it inside applications based on React1, Vue, and even jQuery.
<!-- Inside any app written with any technology -->
<my-popup message=”Use Angular!”></my-popup>
This feature will help companies that are using multiple frameworks to create a unified components library. Angular Elements is also a great tool to support your micro front-end architecture, which allows independent dev teams to each be responsible for a component running autonomously on the same page. Furthermore, it will allow companies to convert or upgrade to Angular 6 incrementally, component-by-component, without a significant upfront investment.
Angular 6 supports your UX design system so that your application can have a fantastic user experience. Design systems are a collection of patterns, component libraries, style guides, and more. They help you document design guidelines, have supporting building blocks, and let you design your applications at scale.
Although Material Design and Component Dev Kit (CDK) aren’t new, Angular 6 makes it easier for you to use them. Material Design is a complete, opinionated design system created by Google. But if your application needs to have a custom design system for your brand, Angular 6 exposes Material Design’s component infrastructure using CDK. Their libraries make it easy for you to create a design system that’s accessible, supports internationalization, and provides common interaction patterns like floating panels. There are several new packages and features to look forward to in 2018.
Furthermore, it opens up the possibility for community-driven patterns, libraries and tools. CDK makes it faster for your company to create a custom design system that matches your brand.
The CLI is probably one of the most liked features of Angular because it reduces the amount of work developers have to do. Angular 6 will extend the CLI with schematics, which are infrastructural components that create templates and execute code transformations in your application. Rangle’s very own Mike Brocchi has put in a tremendous amount of hard work into the CLI and you can watch his ng-conf talk about its schematics. Currently schematics include ng new and ng generate. Angular 6 is introducing new schematics including ng update and ng add.
This schematic will help you automatically update your npm dependencies, which will keep your application up-to-date. It will also update your RxJS and Material code to take advantage of all the new features that come with Angular 6.
This schematic will add new capabilities to your application. It creates instant code and library scaffolding. There are many libraries that will support this schematic, including Angular Material, Angular Elements, Progressive Web App, ng bootstrap, Clarity, and NativeScript. All you need to do is execute a simple command:
$ ng add @angular/material
$ ng add @angular/elements
$ ng add @angular/pwa
$ ng add @ng-bootstrap/schematics
$ ng add @clr/angular
$ ng add @nativescript/schematics
This schematic will make it easy to generate libraries that you can add to other Angular applications. You can include the project scaffolding, test infrastructure and build system setup.
$ ng g @angular/material-material-nav --name-main-nav
The most exciting feature coming up in Angular is its third generation renderer named Ivy. Although it won’t be production ready for Angular 6, there was a lot of well-deserved buzz at ng-conf this year. The renderer has been completely rewritten to be smaller, faster and simpler than all previous renderers. There are three features from Ivy that I think really stand out.
The best part of having a declarative UI framework is that there are virtually no incompatibility issues when the renderer is updated. Once Ivy is released, all you need to do is upgrade your package version of Angular without any changes required for your existing apps. It should be seamless. The only difference you should notice is that your application is faster, smaller and has access to new features.
Google can be so confident about its backwards compatibility promise because of its “One Version Policy.” They have over 600 applications all using the latest version of Angular, including Firebase, Google Analytics, Google Express, Google Cloud Platform, etc. In fact, they commit the head of Angular’s repo into the Google codebase on an hourly basis. If even one of the 600+ applications fails to work, then they roll back Angular! This approach ensures that Google has a comprehensive test suite to prove that every Angular commit is backwards compatible.
“[Google has] over 600 applications all using the latest version of Angular… In fact, they commit the head of Angular’s repo into the Google codebase on an hourly basis.”
The current Angular renderer requires global analysis to compile code into JavaScript. Ivy follows a different philosophy. During the compilation of templates, Ivy only uses information available on each component level and its decorator. It neither looks at its dependencies, nor the global analysis. This is referred to as “locality,” which means it looks at one file at a time to generate the bundle. This philosophy has five significant benefits:
The concept of tree shaking has been around for a long time. However, Ivy is written in a completely different way to optimize tree shaking like never before, without making you change the way you write your code.
Tree shaking is a build optimization step that removes the unused Angular code from your bundle that you don’t need in your application. This removal results in a significantly smaller bundle size and makes the application run faster because fewer bits need to be shipped to the browser. There are existing tools that can currently help with this, like Rollup and Uglify. The problem with these tools is their efficacy depends on how you write your code. Why? Because they use static analysis to determine what code needs to be retained, which means it doesn’t actually run your program. As a result, static analysis will retain unwanted code in certain circumstances, for example where the code is being called only under a condition that is never met.
// function a will never be used, but will be retained
// when using static analysis for tree shaking
let a = function() {}
let b = function(c) {
if (c) {
a();
}
}
b(false);
The scenario above can occur with Angular’s previous renderer. Your template HTML is parsed into a template data structure, and then passed to the Angular interpreter, which has to know how to do everything to be able to create the resulting DOM.
Template HTML >> Template Data >> Angular Interpreter >> DOM
For Ivy, Google has re-written Angular’s rendering pipeline by removing the clunky Angular interpreter that needs to know how to do everything. Instead of generating template data, it generates template instructions directly, which are atomic functions that do just the work you need from the template HTML that you’ve written.
Template HTML >> Template Instructions >> DOM
The template instructions are much leaner so there won’t be references to code that you do not need, which means the tree shaking tools can successfully remove unused code from the resulting bundle. The result is smaller bundle sizes. In fact, a Hello World bundle with Angular’s previous renderer is 36 KB. With Ivy’s new render pipeline strategy, the same Hello World application is as little as 2.7 KB! Smaller bundles mean a faster application startup time for your users.
The conference was jam stacked (pun intended) with information, smart people and memorable experiences. I wasn’t able to touch on every aspect here because no single article could capture everything at ng-conf 2018. It left me very excited about the upcoming features in Angular, especially Angular Elements, and sustained my confidence that Google is continuing to give their all into this wildly popular framework.
Ng-conf Day 1 Keynote 2018 – Public
Day 1 Keynote – Brad Green, Miško Hevery, Kara Erickson
Elements in v6 and Beyond – Rob Wormald
It’s common for a newly formed agile team to find it unnatural that they could be self directing. “What do you mean we decide the right path?” Creating a team of leaders means empowering the team to have a little more autonomy without a manager dictating their every task.
Ants don’t have a central command to coordinate their behaviour from a high level. Each ant decides what they need to do for the success of the colony through individual interactions with each other and pheromone trails from others in the colony.
Similarly, bees also don’t have a central command. Forging bees communicate their findings to the colony, allowing each bee to make a decision on what to do.
In a healthy agile software team, the individuals communicate with each other and pursue the best path to achieve their priorities. Although there is the occasional need for a manager to correct their path, the team will learn each time they derive a false assumption or conclusion.
This culture harnesses the collective expertise of the team to discover what’s best for the company. It produces a team of leaders.
Do you think software teams can be trusted with day-to-day decisions without the involvement of a lead or manager? Tell me what you think.
Managing stakeholder expectations is essential in the role of a software development manager. When a stakeholder has an unrealistic expectation of your software development team, you are setting up your team for failure.
Stakeholders should expect to have only 2 of the following 3 basic expectations at the release of their anticipated software.
The first two expectations are usually the highest priority: quality has a direct impact on usage and availability, and the deadline is usually tied to a marketing campaign or sales contract. The third expectation, the feature set, is less important in today’s web enabled world.
In a tech culture encouraging iterative improvements after the release of a product, especially with agile software development, feature sets are not static. They evolve with the product. Features once believed to be vital to the core product (i.e. Facebook’s poke) are later discarded or minimized, paving new paths towards innovation. Therefore, less emphasis should be placed on features and more emphasis on releasing a good quality product on-time. Features should be cut, drastically if necessary, when the quality or deadline is at risk. Convincing stakeholders of this philosophy will evade unrealistic expectations and will setup your development team for success.
Do you think all 3 expectations are always possible? Which 2 expectations would you choose? Tell us what you think in the comments below.
Imagine developers being force fed a consistent sense of urgency and anxiety aimed to persuade them to work harder, longer hours and produce more, more, more. All this to benefit a profit fixated corporation which is obsessively refocusing itself to the bottom line.
The consequence is a team of unsatisfied developers followed by high turnover and a related cost of rehiring, training and knowledge transfer.
Although not intuitive at first, the efficiency of an in-house development team is lost. Eventually as the software product grows, this overhead will eat up any extra profits the in-house model naturally endows. This scenario actually hinders ROI ultimately contributing less to the bottom line.
Software development managers can do better than being “slave-drivers”. There is a more effective way to impact the bottom line by motivating a development team to increase ROI.
Last year Intel published an article outlining the hierarchy of developer motivation. They cite that the majority of developers are motivated when playing a creative role and gain a sense of achievement from the projects they work on.
Another article by Rob Walling entitled Nine Things Developers Want More Than Money cites that developers want to exercise creativity and have a voice in the priorities of their team.
I won’t cover in this article how to setup a development team to exercise creativity. But it all starts with agile software development and you can read what a manager can do in my article about the manager’s role in agile software development.
Additional resources
The roles of a software development manager are numerous and too complex to explain in one post. However, there are two key roles in the waterfall model that are very visible in the organization and are missing in Agile. Managers create technical solutions for projects and direct the work of the team.
Contrarily, Agile software development teams do not need a manager documenting technical requirements and directing their work. These responsibilities lie with the team after a product manager has written a user story, which does not contain technical solutions.
Instead of these roles, the manager’s role in Agile is to setup the team for success. This includes:
What is lost: some control. What is gained: a team that is more self-directing allowing the manager to focus on managing humans.
Although “losing some control” sounds scary, it’s important to keep in mind that the manger isn’t losing control of the project or the team. In the spirit of a self-organizing team, the manger is losing some control over the solution process. Let the team discover its own technical insights as long as the team still reaches a correct solution (and remember there is more than 1 correct solution). The manager’s control is now exerted in the places that will make the team more efficient and self-sustaining. The “Give a man a fish…” proverb comes to mind, which can be adapted for the agile world.
“Give a team a solution and you help for a day; teach a team to work together and they solve problems for a lifetime.”
Many managers still want to be the source of all solutions. This usually includes controlling the communication from/to their employees. In my experience, this behaviour sometimes stems from an insecurity of being less visible or less relevant in the organization.
As the tech culture shifts towards more collaboration, there will be less room for insecure managers.
Additional resources
Before one of my scrum master meetings, I was tasked to bring a new retrospective to the team. So I looked at the 4 key questions that a retrospective should answer.[1]
I realized that many of the common retrospective activities only reveal 2 or 3 of these questions, and I wanted to create one that addressed all 4. I was inspired by the pop song lyrics “Clarity” by artist Zedd to modify the Mad/Sad/Glad retrospective[2] to Tragedy/Remedy/Insanity/Clarity.
I tried this retrospective a few times and it seemed to receive a good response from the team. Try it out and let me know how it went.
References
[1] Retrospective key questions
[2] Mad, Sad, Glad retrospective