Over the years, my company’s main application has been under continuous development, evolving and gaining many features. Naturally, as time went by, our engineering team developed many frameworks and utilities that were needed for the app. For example — performance tracking, background worker system, analytics, storage access and even our own ORM, and much more.
Over time, systems as a whole become more robust, and as do their frameworks.
At this point we started to think differently. We can no longer write frameworks that are bound to a certain application. In order to really scale things out, we need to build reusable modules and libraries, which will provide the building blocks for all our applications.
When you are working on an embedded device, you usually start simple. A main loop that does something.
As you start to add more features, the complexity of the code grows. You add more ifs, more loops, more conditions, and even, god forbid, switch statements.
This is the point when you should to pause and ask yourself: "Am I doing the right thing?"
There must be a better way...
Better way to make these kind of systems, which is not tangled, hard to debug and hardly testable.
“A failure” can be a result of a software or hardware problem. A fault tolerance design intents to enable the system to continue operate properly in an event of failure. In this post I’ll talk about a way to treat a special cause of failure – a timeout using a really cool open source framework named Polly.
A while ago I found that interaction with a component in our site results in many detached dom elements. At first glance, it wasn't clear from the code what was causing it.
After some research I realized that the detached dom elements are still referenced by prevObject- an internal property of all jQuery objects which is used by the jQuery .addBack() and .end() methods.
If you're not familiar with prevObject or these two rarely used methods, you can use jQuery chaining in a way that essentially creates a memory leak.
In my particular case the effect on the page's memory consumption was minuscule, and I'm generally against micro-optimizations. But since jQuery is used by many people, and since I couldn't find much info about this topic online, I thought I'd share.
MVC is one of the most commonly used design patterns in web applications. It can be used both with server and client side rendering. Frameworks like ASP.NET MVC and Angular adopted the pattern and made the development extremely easy and straight-forward.
Despite its popularity, I claim that the MVC pattern is no longer the best solution for creating rich and modern web applications.
A lot of different factors can affect a web page's performance. For this reason, truly effective Web Performance Optimization starts with identifying the most significant perf bottlenecks of your site. This is usually done with tools likeDevTools, WebPagetest, PageSpeed Insights, etc.
Once you've identified a possible lead, and taken the time to refactor and optimize it, it's important to follow-up by properly validating and understanding the impact of your change. Getting this right will help you learn whether that's something you should race to implement across your site, or a best-practice that in your particular case amounts to a micro-optimization.
This type of analysis is not trivial because web performance data is typically noisy. You can reduce noise by running your optimizations as A/B experiments side-by-side with the existing implementation, and by visualizing your data with a suitable graph such has a histogram.
This post explores these techniques in-depth.