My First 24 Hours with Flutter

Last weekend, I decided to re-structure my depth year and go on a learning adventure. I asked myself, how long will it take me to learn Flutter?

The answer to that is — not very long at all.

So why Flutter?

I’ve heard and seen it around a lot lately, with other devs asking when I’ll get my hands dirty in it and start writing about the framework. I’m going to keep it real — I’m a complete Flutter noob and this is what I’ve learned about it over the past 24 hours.

All in all, I’ve probably only spent about 3 hours on it so far, split over a 24 hour period. Most of it was spent playing around with everything and seeing how the pieces fit together — or should we say, widgets.

How does Flutter work

According to the official tagline, Flutter is:

Google’s UI toolkit for building beautiful, natively compiled applications for mobileweb, and desktopfrom a single codebase.

But what exactly does this mean?

From a developer learning perspective, it’s like the guys at Google sat down, picked out the best bits of web development, decided that JavaScript and CSS should have a child together, and didn’t invite HTML or any kind of XML structuring to the party.

A lot of it just works, in part, it’s because it comes out of the box pre-configured. This makes it highly accessible to developers and learning developers. You don’t have to construct everything from scratch, not really, because there’s already a pre-coded widget shipped with Flutter.

It works with a design-first approach, meaning that you’ll need a clear visual outline of what you want to achieve. It’s not like your traditional JavaScript, HTML, and CSS combination where you can just make it up as you go along. Sure, you can technically do that in Flutter too, but it’s easier to get lost in the tree if you’re not strategic in your approach.

So how does Flutter work? Well, everything is a widget.

Everything is a widget

The idea behind Flutter works like this: everything is a widget until you can’t abstract any further. A widget is basically a class object that’s instantiated and can be reused across your application.

Image for post
Hypothetical Flutter app

What does it look like?

When you use the default Google Material widget that’s shipped with Flutter, it gives you access to all the pre-configured Material design visual assets and possible settings such as colors and icons.

In a simple starter Flutter app, you have the main() class that Flutter looks for as the entryway into your app. It’s got void declared because there’s nothing to return.

A simple view can look something like this:

import 'package:flutter/material.dart'; void main() => runApp(MaterialApp(  
home: Text('heeeeey')

The MaterialApp() class is a wrapper widget that applies Google Material design principles on your app. It’s a bootstrap wrapper that makes your app uniform with user expectations and the general design ecosystem of apps currently available. While it does create a level of generic feel for your app, it’s a trade-off for rapid prototyping out a working solution.

To create something more useful than just printing text onto the screen, using Scaffold() widget lets you draw on specific and commonly used visual features such as the app bar, the body area, bottom bars, and navigation areas. And because everything is nested, it means that your view can be broken down into its smallest sub-set piece. So within the Scaffold(), you can have another Scaffold().

While it may sound counter-intuitive in code and almost akin to an impending pyramid of doom, it’s not. How so? Because each code block represents a widget, a widget within a widget is based on how well you can coordinate your design.

If you really look at it, the nesting idea is similar to a DOM tree. But Flutter takes it one step further by keeping your separation of concerns based on grouped values rather than language type.

In a traditional setup, the view and logic would be separated from one another. However, the integrated nature of view, data, and layout in Flutter makes it easier to manage. With Flutter, you get to focus on the object itself and how it visually renders. You get to think from a design first perspective rather than jumping around between different files. It’s self-contained within the widget (aka class).

If we were to compare it to something we already know, a widget is almost like a module. The only main difference is how it’s written, the general size and the name. Modules tend to be bigger, while widgets in Flutter are advocated to be as small as possible, allowing you to compose your views with your personalized set of building blocks.

Flutter’s widget catalog has most of what you’ll probably need

Flutter’s widget catalog contains everything that comes pre-built with Flutter. The extensive list includes a majority of what most information-based applications need.

You can potentially look at an app and re-created it fairly quickly by just using the pre-built widgets that are available. It’s almost the coded version of a WYSIWYG. While this may sound like a bad thing, the major difference between WYSIWYGs and Flutter is that the latter is extensible and highly customizable.

You can probably make games with it too, but that’s not the kind of target market the official Flutter documentation leans into.

Is it going to be the next big thing?

This is probably the multi-million dollar question that every company and developer asks before they jump into new technology. Unlike web to mobile frameworks and libraries like React Native, NativeScript, and Ionic, Flutter runs on Dart.

Dart is one of the youngest kid on the block and looks a bit like JavaScript, but more grownup from the pains that JavaScript sometimes exhibit. It’s a standalone language that’s being used to translate into JavaScript, Java, and even Swift for iOS devices.

Dart also solves the disconnect between large HTML, CSS, and JavaScript, where the relationships between them can fall apart over time. Someone, somewhere, is going to be tempted to use !important to override your overrides.

In the age where UI is a make or break situation for applications and businesses, Dart makes it easier for developers who aren’t necessarily designers. It gives power to the people who understand how to code but not necessarily the finer points of how to design.

Final initial verdict

I’m going to be honest — it’s only been 24 hours of playing with Flutter, so this might just be the code honeymoon phase. Most of has just been playing with the UI and building views with the different widgets available. The next step is figuring out how to connect and manage data within Flutter.

After that, it’ll probably be time to build something and release it into the wild to see how it will perform.

So what’s my final initial verdict on Flutter?

I like it.

For anyone that already knows a programming language and understand the basic concepts of OOP like classes, methods, functions, and inheritance, picking up Dart is sort of like writing in JavaScript with a dash of Java – but not at the same time. No. It’s much more simplified with the option to be both statically typed and dynamic, based on whatever you want it to be.

Dart is easy. Making something in Flutter with minimal or no knowledge of the framework is a matter of figuring out what you need from the widgets catalog.

I’m sure there’s probably more it. Whether I encounter them or not is something I’ll find out soon.



About Author /

I code. I write. I hustle. Living the #devLife remotely. Subscribe to my newsletter to stay connected with my latest posts and dev thoughts. Want to collaborate? DM me on LinkedIn

Leave a Comment

Your email address will not be published.

Start typing and press Enter to search