When I first studied the new Composition API, I was confused that there are two watch hooks: `watch()` and `watchEffect()`. From the documentation alone, it was not immediately apparent to me what's the difference...
I am currently working on porting vue-lazy-hydration to Vue 3. With that comes the potential to make some significant improvements since Vue 3 has an API that allows controlling the hydration of VNodes. Working with the new APIs got me thinking about the general concept of hydration...
I'm kind of obsessed with Dependency Injection. But for a good reason. I believe that an essential factor when it comes to building maintainable, large-scale applications is to get Dependency Injection right...
Some time ago, I read a very informative article by Pete Hodgson about feature toggles. I'm thinking a lot about the Context Provider Pattern and the types of problems it can help solve, and it appeared to me as if feature toggles are one of the use cases where this pattern can provide a lot of o value...
In the React world, React Hooks are basically what in the Vue world is the Composition API. Although React Hooks and the Vue Composition API try to solve similar problems (mainly, reusability of stateful logic), how those two frameworks deal with reactivity under the hood is quite different...
With the new Composition API and Vue 3, there is a lot of talk about whether or not we still need Vuex or if it is possible to replace Vuex completely by making reactive objects globally available. In this article, I argue that thanks to the Composition API's new tools, Vuex is rarely necessary anymore...
Certain coding practices seem superfluous when you first encounter them, but sooner rather than later you get into a situation where you wish you had stuck with them. Wrapping third-party libraries instead of using them directly in your codebase is one of those practices...
I recently played around with the idea of using renderless provider components not only for data but for styles too. This pattern seems especially promising when it comes to building base components with style modifier props...
We use Dependency Injection to achieve loose coupling. But loose coupling and Dependency Injection can make it harder to understand how our code works. It can make it more challenging to determine where a particular dependency is coming from...
Again and yet again, we hear and read about the problems of CSS. And there are some pitfalls you can fall into, mostly because of the global nature of CSS. But I argue that we solved those problems now multiple times...