Why Not Just Flutter? Benefits and Use Cases of Flutter Markup Language

Isaac Olajos
10 min readJan 11, 2023

Just over two weeks ago Flutter Markup Language was released to the public for the first time… and the same question was asked over and over.

Why would I use Flutter Markup Language instead of Flutter?

The short answer is, you wouldn’t. Flutter Markup Language was not designed as a replacement for Flutter, but as a tool for anyone regardless of technical background to easily build high quality applications that can run on any platform, are interpreted rather than compiled, easy to build and effortless to deploy.

FML covers some use cases that Flutter simply does not fill without a lot of time, effort, and knowledge. As well as offering some pretty serious time saving capabilities to build out entire applications, prototypes, and more. In this article, the reason FML was developed, and the business problems it solves will be outlined and discussed.

Before we get into the background and details of the problems FML was built to solve, the TLDR use cases for Flutter Markup Language are as follows:

  1. Over-The-Air, instant application updates and deployment on all platforms, in real time at the same time. No standard development pipeline needed. No need to manage multiple environments or code-bases for individual devices and platforms.
  2. Real-Time-Interpreted Language on all platforms. Normally reserved for web and html, this feature allows for the instant updates as mentioned above, and includes real-time FML-injection, widget manipulation, and more.
  3. Significantly faster speeds when creating fully functioning cross-platform applications and prototypes. This greatly reduces the cost of development, and can allow for proof of concept and prototype applications to be utilized in production immediately.
  4. No development environment needed to create, update or edit applications. This allows for anyone to quickly modify and create applications and their components without the overhead of setting up an IDE and downloading SDK’s.
  5. The ability to create a single, human readable page that works across all platforms. Allowing for single codebase cross-platform applications, simplicity of management, and instant all-platform updates.
  6. Easily understandable syntax, and a shallow learning curve allows anyone to quickly understand, edit, update, and create new FML templates and complex applications without previous programing experience.

FML has found a lot of success in enterprise level application development. Both development timelines and cost have been reduced significantly with single platform applications, without any added cost for cross platform development.

The Original Business Problem and Where it all began…

The advent of Flutter Markup Language started with the death of flash. Its conception was brought about as a replacement for a similar markup language that was used internally between a host of large industries to quickly build out inspection applications across multiple platforms. The tech lead of Flutter Markup language worked for 10 years creating this software and rolling it out to multiple plants and enterprises globally.

The goal of the initial engine, and the business problems to be solved were the following:

  1. Have an inspection application that worked on all platforms that were used by these enterprises in the same way.
  2. Allow for IT professionals and Engineers to edit these inspection applications without needing deep programming knowledge, dev environments, or other overhead that generally comes with the development cycle.
  3. Any updates made must be instant, Over-The-Air, and uniform across all devices. This was designed to minimize downtime and adapt to the ever changing parameters of enterprise environments.
  4. Any changes must take effect on all devices, instantly, without having to compile, install, or go through any of the normal dev pipeline.
  5. Finally, it must be quick to create new applications and edit existing ones. This translates to massive cost savings, on top of the ability for in house teams to edit and update their own applications.

Once the alpha stages of the Flutter-Based engine had gone through the ropes and the dev team had ensured they met the base functionality of the pre-flutter system, they had created an engine with massive leaps in performance and functionality outside of the original scope, yet the format simply did not meet the ease of use and expandability that modern application building demands. Through client requests, time and time again new functions that the original flutter engine couldn’t handle when presented with new challenges. The major downsides of this original iteration which needed to be rethought were:

  • The original engine locked data and application flow into a very specific way of being done, which was unused outside of its current environment. It was designed essentially to create a single type of application in the prescribed way.
  • The rules and addons in the original engine made it too difficult to memorize all of the exceptions, overly specific widgets, and endless attributes that patched specific holes rather than allowed widgets and functions to work more intuitively together.
  • The UI of the original engine was restrictive, unresponsive, and locked into a very industrial aesthetic. It took major forethought and testing to build out any UI that wasn’t the base behaviors of the system.
  • The ability to create non-inspection based applications was incredibly limited and convoluted when straying from the standard form/formfield template.

Seeing all of these challenges, the dev team embarked on a complete rebuild, redesign, and rethinking of this old framework, which birthed Flutter Markup Language.

The Start of Flutter Markup Language

At this point, inheriting the original base design specs, Flutter markup language could create fully functioning cross-platform applications with a single, interpreted codebase. This allows for no-compile application updates, instant rollouts, and OTA updates within app stores and desktop applications both online and offline. Despite these improvements, additional goals needed to be met in order to satisfy most application builders’ needs.

The main additional goals of Flutter Markup Language were:

  1. While previous iterations were limited to building inspection software that worked a very specific way, FML should be able to build any application on any device.
  2. FML should be able to connect to any data source, hardware or network, and utilize that data source in any structure within the FML application.
  3. FML should be able to handle its own data flow, navigation, and user flows both online and offline, in any way the developer sees fit.
  4. FML should be intuitive, easy to use, and follow general rules and principals.
  5. FML widgets should work together in an intuitive way and be non-restrictive, limiting the ability for users to make mistakes that could result in errors.
  6. FML should be performant on all devices, utilizing any hardware.
  7. Implement modern data binding techniques in a way that was both simple and powerful.

Through extensive testing and design with enterprise clients and applications of all types, these goals were met and exceeded. After a significant refinement process and field testing, Flutter Markup Language was finally released in public beta.

The features Flutter Markup Language offers

At its initial release, Flutter Markup language as a whole has realistically been in development in flutter for around 3 years. If we count its metamorphosis from previous software in both Flutter and Flash, Flutter Markup Language has had a development, testing, and improvement period of over 10 years. This massive life cycle allowed for the development team to refine, test, design, and redesign a host of features while testing these features and concepts in the field.

The majority of benefits of FML over Flutter come from the aspect that it is both an interpreted language (rather than compiled), and a very simple to use and understand markup language. For a deep dive into FML, visit the Wiki or the code base. To talk about some of the high level benefits, we can get into each point a bit more than in the previous paragraphs:

No-compile rollouts and Multiplatform instant Deployment

The first and one of the most prominent features of FML that set it aside is its use as an interpreted language rather than a compiled one. This allows for a multitude of different use cases, most prominently being instant deployment within any app-store or OS. The Flutter Markup Language engine, once loaded, is supplied an endpoint by the developer. This endpoint fetches and interprets FML templates, building them in real time.

Real Time Over-The-Air updates within production applications

A feature of being interpreted rather than compiled, FML allows for real time updating on all platforms at the same time. It was important for the initial use case of FML that a singular application running across multiple devices could be updated in real time, across all devices running it as needed. This allows for a host of benefits including iterative design, rapid response to user feedback, and more.

Significantly faster development speeds to fully functional applications

One of the biggest challenges of FML was creating a simplified system that encompassed all of the generally complex systems a developer would have to implement, and making it highly useable for 95% or more of application building needs. The majority of the development time with FML was creating systems that could be used simply and predictably across all platforms. While the developer using FML would simply use and see a singular widget, the interpreter handles all of the logic for state management, platform specificity, data typing and usage, and more.

No-IDE Scripting

Any FML file can be updated in a simple text editor. No downloads of SDKs, IDE’s, or any other typical overhead a dev would use to set up their environment before coding can begin is needed. This allows for anyone to instantly edit and update anything within an FML application without having to set up and manage a development environment.

Online and Offline data handling

FML has simplified the complexity of forms, online and offline capabilities, and handling connectivity. FML uses many different resources to handle this in a more automatic way but one of these is the POSTMASTER. This service allows for connectivity loss to happen and will save and continue to attempt posting once regained.

Simple data source integration

Connecting to multiple data sources in xml or json format has been simplified using FML. Users can easily connect and bind to REST calls, hardware specific data like NFC, CAMERA’s and more. All of the idiosyncrasies of data structure and access across platforms have been automatically handled for the developer so they can focus on the function and UI of their applications.

Low Cost Learning Curve

The simplification of UI building, built in automatic state management, simplified data source integration, and easy to understand structure all allow the cost-of-entry for FML to be low and fast. The highly technical aspects of application development have all been handled by the interpreter and abstracted into easy to use yet powerful FML widgets. With this, you can build and edit applications in a matter of minutes.

Cross Platform singular codebase

Developing cross platform applications has never been easier. FML widgets are both responsive and predictable across all platforms. That means that a single FML template and endpoint can be used for any platform needed. Whether that’s a desktop application, iOS, android, or web. On top of this, updating that single file will instantly update all of the applications on all devices uniformly.

Performant Applications

The FML interpreter is built in Flutter, which means native compilation to every device. Though an interpreted language will almost always be less performant than a well-optimized native application, modern hardware allows FML to run smoothly and performantly across all platforms.

Flexible and Responsive Layouts

Layouts in FML are standardized with a general set of rules, endless customization options, and robust THEME layers that allow for changes across entire applications from a single file. A developer can build responsive and flexible applications that conform to any screen size or platform with minimal effort.

At the end of this cycle and with the public release of Flutter Markup Language, it has been used to develop applications from public facing finance portals to inspection systems that coordinate with manufacturing plants and machines around the world. Major corporations have adapted FML such as Goodyear Rubber and Tires, and more are coming to the table as they see the cost benefits and time saving aspects that FML can offer.

As any tool, FML has its pros and cons over frameworks such as Flutter, and can be leveraged to provide some massive cost and time savings for any teams including those of Flutter Developers.

For more information, or to get involved in the community:

If you would like to get started using FML, you can check out our guides:

You can also check out our developer talking about some of the use cases and origins of Flutter Markup Language on the Flying High With Flutter podcast!

--

--

Isaac Olajos

Health and Technology. Flutter Markup Language developer, Integrated Movement Training owner.