Discovering the World of Web Development using Flutter

Here at TGH Tech, we primarily use Flutter for developing apps since we can ship out to Android and iOS devices with the same codebase. For the web, we primarily use Next.js, but recently we were thinking about exploring Flutter Web.

Two months ago, we got a project that had a flexible time schedule. So our CEO Sachin suggested we explore and try something new this time, and we decided to do the project in Flutter Web.

First things first, the initial loading time of Flutter Web stinks! There is around 5–6 seconds of loading time when the Flutter web engine is loaded. By default, it is a blank white screen, which is very boring to a user who will think the website is very slow. Initially, efforts were spent on finding some way to reduce this loading time, but when I understood that it's not that easy to reduce it, I decided to add a good loading indicator so that the user would be less frustrated.

I followed this article from FilledStacks: https://www.filledstacks.com/post/6-tips-to-make-your-flutter-website-feel-premium/. This initial load duration happens primarily on the first load, and on subsequent loads, the request is cached and the load happens under 2 seconds.

And you know what? The client told me that the animation was so nice that it had to be played a bit longer!

Since hot reload isn't supported on the web, and for this project, we didn't have to think much about responsiveness, I thought to just debug in mobile, and then finally everything would be exactly the same in the web version—a big rookie mistake! On the web, several issues can arise with third-party packages that work perfectly fine on mobile.

Before choosing a package, make sure it has web support, and even then, there is a chance that some issues might come up with packages that explicitly say that they support web. One issue I faced was that I had to implement a glass morphism design for a card. I had worked with the package a couple of times previously for other mobile projects, but when I implemented it for the web, I found that some properties of that package were throwing exceptions in the web version but were working flawlessly in the mobile version. This cost me some time, and from now on I will totally debug the web if I am building primarily for the web.

In the project, there was a requirement for displaying a list of apps, and on clicking on them, if the device is Android, then open the Google Play Store; if on an iPhone, open the App Store. Usually, when such a requirement comes, we can call Platform.isAndroid and handle the condition easily, but on the web, I had to dive into Stack Overflow for a bit to find a good solution. I ended up obtaining userAgent using device_info_plus and string comparison to find out if it's Android or iOS, but I'm still not sure if it is the proper way. If any of you who are reading this know a better way, do reply to this newsletter.

Hosting the Flutter Web was actually easier than I anticipated. We usually host our projects in Amplify, and to deploy Flutter, we first had to build the project. I used GitHub Actions to create a release web build and get auto commited to a specified branch. This branch is then connected to an Amplify mono-repo. I followed this resource: https://medium.com/flutter-community/hosting-flutter-web-applications-with-amplify-hosting-and-github-actions-d53ba213767.

Some key points to look into while building for the web are:

• Update the title and description in index.html.

• Use flutter_launcher_icons to generate a favicon.

• Avoid page transition animations and animations in general. I felt a lot of jank in many places, especially while scrolling.

• The web performance overall is on the lower end compared to building for Android and iOS, but the performance of the web on iOS browsers felt superior and less janky.

• Learn more about Navigator 2.0, I used Go Router; the documentation wasn't that great, but there were some great resources.
  
  That's it for today, I will be back soon with another piece of content, probably non-tech next time!

  
  Thank you for reading.