Interview With Dmitry Zhifarsky at Flutter Warsaw

Following our custom, we again interviewed our speakers at Flutter Warsaw #16. One of the speakers in this edition was Dmitry. We asked him about his beginnings with Flutter, what he likes about it and what was frustrating at first while developing apps. We also tried to find out what motivated him to create the Dart Code Metrics tool that has gained popularity.

Dmitry Zhifarsky is a Dart Code Metrics co-author. Co-founder and CTO of a startup with its main product built with Flutter. He is currently working on the Sidekick browser as a Frontend Architect. He says he fell in love with Dart ever since working on a huge frontend codebase at Wrike written in Dart Angular.

[Matej Rešetár] When did you write your first line of code?

[Dmitry Zhifarsky] I guess when I was at school, haha, probably like 10 years ago. We had the basics of C++ and Pascal, of course. 

Did you make any games or try to create any?

Yes, actually, I tried to create games with C# and Unity when I was at the University. I worked with a friend on the platform where you could do jumps and kill monsters, and it was fun. First of all, we tried to create our own physics and engine just like Windows 4, but then we decided to switch to Unity and experimented with it a bit more. But in the end, we gave up on this project.

When have you heard about Flutter for the first time?

I think I had heard about Flutter for the first time when version 1.0.0 was officially released, somewhere in fall or winter 2018. I guess it was when I started to play with it and see what it is capable of doing. I began to work with it closely later in 2020.

What kind of apps were you creating at the beginning? Did you release any?

I was only testing Flutter and didn’t release any apps at the beginning. I was trying to recreate the functionality for the eCommerce site, the website I was working on at that moment, and it was straightforward. It felt very different from what I experienced earlier with iOS development. I had one medium app written in Swift, and the experience in Flutter was way better. 

I’m personally also interested in writing clean code and keeping it neat in Dart Analyzer. What made an impact on your decision to create Dart Code Metrics?

The tool was created in Wrike, and Wrike has 2.5 million lines of code written in Dart only and a massive codebase. You get to the point when you need to ask yourself a question: How good is my code? How can I find bugs in my code? What part requires the most attention now? It’s tough to go through each line of code and check it out. We started to think about collecting metrics from the codebase and getting a high overview of how good or bad our code is. That’s what started it. That’s how the Dart Code Metrics tool was created. Also, that’s the reason why Dart Code Metrics has metrics in its name because the metrics were the first element that was provided. And it helped us to see how huge our codebase was and what needed to be improved.

What is the most frustrating thing about Flutter for you?

For a long time, there were performance issues with the iOS application. Those junk problems were significant issues for everyone who tried to use such an app. I still sometimes notice that on the app I’m working on, it really is frustrating because you rarely can fix it yourself. You need help from the team and extra knowledge to be able to do that properly. Now, nothing seems very painful.

What do you absolutely love about Flutter?

Flutter brought the easiness of web development such as feedback cycle, covering different browsers and platforms to the mobile world. And I really like it. I like how Flutter changed everything when it was released. Before that, iOS and Android development were different. They didn’t have hot reloads. You needed to write a Swift app for iOS, a Java app for Android, and Flutter made it easier to create cross-platform apps with custom UI. You can say React Native is a solution too, but not how Flutter does that.

Last question, what do you choose: Provider, Riverpod, or neither one of them?

I think Provider, but only because I have used this one so far. I looked into Riverpod briefly, but I’m still not sure how to manage the state in Flutter properly. It seems there are so many solutions, and they all differ. The problem I see in all of them is that I expect there might be issues with code understanding on the scale. Because if you have multiple blocs and they are connected somehow, then it might be hard for a new developer on a project to follow its flow. Same with Riverpod. These are my insights.

[Matej Rešetár]: Ok, I need to add. If you use Provider, then Riverpod, once you get used to it, it makes the code easier to write and maintain, in my opinion. Because you don’t put Providers in the widget tree, you can kind of place them wherever you want. And still, all the benefits of the Provider remain. So you can use whatever you like: bloc, change notifier, write specific future Providers for Riverpod. It doesn’t matter. I encourage you to take a look at it.

If you want to take part in Flutter Warsaw as a speaker just fill the form below:

Flutter Warsaw Call For Papers

Flutter Warsaw is now one of the biggest Flutter meetups in Europe, attracting 100+ people for each online event. If you want to join us as a speaker and share your knowledge with others, please fill out the form below.