Engineering SimpleWeather.

Async: Both JavaScript and the GNOME platform have heavily evolved since then, which led to outdated programming techniques and recurring performance stability problems. One of the main issues was the extension's handling of asynchronous programming such as network requests since async/await didn't exist at that point. Therefore one of my main goals with SimpleWeather was to elegantly handle any asynchronous programming with promises.

Separation of Concerns: The old extension's UI system was directly connected to the network system. This led to many performance issues. Because the networking, application state, and GUI layers were tightly coupled, the GUI could not be updated independently of a network request. This meant that updating the UI was extremely difficult, changing a setting caused a new network request, and that the weather API's JSON output was directly tied to the UI. SimpleWeather had to separate the network connection and weather state from the UI frontend.

Performance: Because of the aforementioned issues, the old extension was full of performance issues and performance was a common complaint among users (#86, #99, #107, #110). Minor performance hiccups may not be a critical issue in something like a Desktop app, however a GNOME Shell extension runs on the same process as the desktop shell, which means any freezing or slow-downs can affect the whole system, and not just the app itself.

Experience: OpenWeather Refined was the first project that I shipped that gained a real user base. I learned a lot in my year of running this extension, including experiencing failure because of poorly designed behavior (#32), poor testing (#40), and unforeseen issues (#49). The goal of SimpleWeather was to have an extension that could reliably ship stable updates and working features, which lead to me doing more rigorous testing and using the development version myself for a while before shipping a new release.