I was recently asked how I would optimize an Angular site for speed. Interestingly, I’ve never written about this explicitly even though I’ve done a lot of work related to this issue.
For the purposes of this article, I’m going to assume you have already implemented most of the things that Angular gives you “for free.” For example, we won’t discuss “Tree Shaking” or “AOT.” Those are given.
Here are my 30 or so tips on how to optimize an Angular application for speed.
Over the course of working on SmartNgRX, I’ve discovered a secret to making NgRX faster. A way that is so obvious now that I know about it, I’m surprised this isn’t the recommended way to use NgRX.
As most discoveries occur, I’m building on the backs of giants. In this case, I’m specifically building on the back of the increasingly popular NgRX facade pattern (done well) and a statement with regard to Angular Signals that says “Don’t use Signal Effects.”
There are, of course, other minor improvements but these are the top two catalysts for what I want to share with you today.
Imagine an NgRX world where you almost never knew you were using NgRX. A world where you never had to write a reducer, action, or effect. A world where you never had to call store.dispatch(). A world where the data you worked automatically persist to the server. A world where the data is retrieved from the server as it is needed and removed from memory when it is not, or never removed if that’s what you want. A world where the data automatically refreshes from the server, or you can use websocket messages to refresh the data and, in either case, the only data that refreshes is the data the code is actively using. A world where optimistic UI is built into the framework.
Last week, I announced a project I had been working on for over 10 months. I call it SmartNgRX and it solves many common issues most of us have using SmartNgRX, including the boilerplate issue, over-fetching, and memory pressure caused by stale data.
Today I want to talk about a few things I learned while creating SmartNgRX that can be applied globally to any project.
Sharing experiences with a friend has highlighted the complexities we all face in the workplace. Together, we’ve often speculated on how work life could unfold more smoothly. It’s a captivating dance we all do, navigating through life’s ever-changing rhythms.
I’ve cultivated a daily ritual—tiny reminders that influence my perspective and guide my daily interactions. These cues become the cornerstone of my morning, offering a touch-point for clarity. They may resonate with you or maybe not, and that’s perfectly fine. Feel free to create your own set of reminders that evolve over time. After all, our beliefs can always use a gentle reality check.
In the vibrant town of Bugville, known for its thrill,
There lived a brisk coder named Sam, climbing up a skill hill.
One day, he embarked on a project so grand,
To craft an entity, a creature named ClutterSand.
There are different opinions about whether or not to use return types in TypeScript. I respect that, but I would like to share why I think they are helpful.
First, let’s acknowledge the reasons why some people prefer not to use return types.
This past week several of us have been working hard to implement a SharedWorker from a library. We found a number of articles on the web that demonstrated how to get Web Workers setup for Angular that all assumed the Web Worker was being generated in the main Angular app. We wanted to use a library and include that file in the main app.
One of the recurring complaints I hear about NgRX is that it requires too much boiler plate code. But, it doesn’t have to be this way. In fact, I’ve been working on a project that has a lot of NgRX code and I’ve been able to reduce the amount of boilerplate code to a minimum and gain features in the process.
Once again I’ve run into a situation where the code I’m looking at doesn’t resemble how the code was meant to be written.
I’ve spent the last month fixing bugs that can all be summarized by the following problems: