Venture into the world of single-codebase development with Flutter Bro

I've been programming for a while - mostly full-stack web development. As a self-employed one-man show, I have to "know everything." This means keeping up with increasing and ever-changing techs and stacks. The Flutter promise is irresistible: just one platform (Flutter) and just one language (Dart). This allows generalists like me to become specialists. Maybe I'll talk one day about by 31-topics-a-month approach to staying up-to-date. Thankfully, it's now history.

My journey to Flutter

I have to serve clients who use different platforms, and web-based isn't always possible. Some of the techs I've tried, with varying time investments:

• Java: JVM-based apps generally feel sluggish on Windows and Linux, don't feel native anywhere, and aren't as "develop once deploy everywhere" as advertised. And let's not get started on Java's verbosity. (I gave up on the JVM dev stack before Groovy, Scala, or Kotlin became serious contenders.) I still miss the rawness of these gray interfaces and lilac scrollbars, though:
• "HTML Applications" (HTAs): Windows-only, client-side web apps that run with full permissions outside the browser's sandbox. Use WSH, the FSO object for filesystem access, MSXML for client-side XSLT transformations, and client-side web technologies like HTML, CSS, and JavaScript (JScript, in this case). HTAs were great a long time ago, if only for the lack of better options. But being limited to Windows and Trident (IE's rendering engine with all that comes with it) spelled HTAs' end. (Remember HTC files? Quite ahead of their time.)
• Adobe Flex and AIR: truly cross-platform, consistent user experience, and one codebase. You get to use ActionScript, a customized implementation of JavaScript, with lots of goodies baked in for development ease and speed. But distribution and installation weren't great. (I bought a software package whose name I forget that generated cross-platform installers for AIR apps.) But AIR apps didn't feel native on any platform and nearly always felt sluggish.
• Xojo (fka REALBasic) was the closest solution to delivering a true one-codebase experience. But Xojo relies on native controls without letting you customize them much on a platform-by-platform basis. Example: the text-editing control for Windows is stuck with an 8-character tab. And if you don't want to rely on the underlying Win32 control, you have to do some heavy lifting to draw your own controls. And all that in a BASIC-inspired syntax:
• PWAs: progressive web apps are mostly great, but they can't easily leverage the host platform's APIs. PWAs are perfect for offline-capable web apps, but not much more. And still, in 2022, browser support remains patchy.

Enters Flutter

Unlike most of the solutions I've tried, Flutter itself draws all the controls you see on the screen. And since Flutter is open-source, you can view how any built-in control was created and customize it to your liking. Xojo (for example) supports "preprocessor directives": you can instruct the compiler to behave this or that way when compiling for this or that target platform. Flutter, on the one hand, supports platform targeting at runtime. This makes your code much easier to read and quite a bit more flexible (in the metaprogramming sense).

Dart

If you've coded in any ECMAScript variant (JavaScript / JScript / ActionScript / etc.), you'll feel right at home in Dart. It also has a C-style syntax and has many things I wish existed in JavaScript. Dart is a mature language, actively maintained and still evolving. I dismissed it initially since Google was pushing it as a compile-to-JavaScript language. Since then, though, thanks to Flutter, it's evolved into the language to write-once-deploy-everywhere. Flutter initially supported Android and iOS / iPadOS. It now also supports desktop operating systems - Windows, macOS, and Linux. It even supports compiling / transpiling to a web app.

You can play around with Dart by going to DartPad.dev:

IDEs

You can write Dart code in pretty much any editor. But for Flutter development, you'll probably stick to IntelliJ or Android Studio, both of which are based on JetBrains' legacy platform (not Fleet). Flutter supports hot-reload, which is near-instantaneous after the first build, and if you keep your code healthfully modular. You can also develop in VS Code, though I haven't tried that approach.

Docs and community

Surprisingly (given its potential and implications), Flutter still has a small-ish community. But its docs are second to few: they're actively maintained by Google staff. Google has a vested interest in the success of Dart and Flutter, as they dogfood it for some of their own projects. The main selling point is the single codebase that reliably (and convincingly) creates native apps on all platforms.

The Dart website and docs are available at Dart.dev:

The Flutter website and docs are available at Flutter.dev:

Conclusion

In my experience, clients don't care about your tech stack as long as the product works and as long as employees don't complain. (My narrow perspective comes from a developer who typically only served companies with under 200 employees. Nearly all my clients have less than 50 employees.)