How production ready is Fabulous?

[cmeeren]

I really like the Elm(ish) programming model. I'd love to try out Fabulous for a Xamarin app we currently have in production; it would likely simplify things quite a bit over the current architecture (which is a kind of homegrown, half-Elmish, MVVM/Redux-like hybrid).

But how production ready is Fabulous? I can live with a reasonable amount of breaking API changes, but I am concerned about a couple of other points:

1. Correct behaviour and general runtime stability. I don't want our customers experiencing Fabulous-related bugs that only crop up far into or at the other side of a rewrite - or even worse, for only certain end-user devices in certain contexts (such as Elements multiplied after pressing a button #343, which I realize is not Fabulous' fault).

2. Performance. I'm not creating games or running a stopwatch at 100 FPS, but I must be able to depend on Fabulous (with necessary optimizations, e.g. dependsOn) handling any human typing speed. For example (intersecting with the point above concerning correct behaviour), a good while ago I started the discussion at Discussion: MVU architecture gives feedbak loop when UpdateSourceTrigger=PropertyChanged and update loop is sufficiently slow elmish/Elmish.WPF#40, where I attempted to explain a problem relating to feedback loops due to e.g. Entry.TextChanged being fired both from user input and programmatic changes. This caused a feedback loop if the Elmish update loop was "too slow". The behaviour was not too hard to provoke on a hardware-accelerated emulator, and was what prompted me to go for the hybrid MVVM architecture I mentioned (where I use view models for Entry.Text updates).

3. Any other known issues, drawbacks, caveats, or battle stories that might be good to know about.

[TimLariviere]

@cmeeren The core of Fabulous is pretty stable and most likely won't change.
No important issue is known as of today.
There's still some discussions on how we can make Cmd testable though, which might have an impact on the API. See #320

Fabulous.DynamicViews on the other hand is still subject to some breaking changes.
Nothing fundamental, but we're still in the process of fixing some invalid behaviors, missing properties or removing useless properties (for MVU)
See #304 #341 #369

One issue (#158) I wanted to fix for 1.0 will have a significant impact on the core of Fabulous, but I think it will wait for 2.0.

Regarding performance, it depends on the platform you target.
Some slowness is to be expected on Android (not super slow, but still noticeable).

We did have the same issue than elmish/Elmish.WPF#40 and we added a debounce helper to workaround (#237).
Fixing #304 should also remove definitely this feedback loop.

Overall, I think Fabulous is already good enough for modest production apps.

[cmeeren]

Thanks for the clarification!

Fabulous.DynamicViews on the other hand is still subject to some breaking changes.
Nothing fundamental, but we're still in the process of fixing some invalid behaviors, missing properties or removing useless properties (for MVU)
See #304 #341 #369

Yes, the first one (#304) represents one kind of bug I'm afraid of. The other two are dev inconveniences I can live with.

Some slowness is to be expected on Android (not super slow, but still noticeable).

This is one of my primary concerns. Could you elaborate a bit? Specifically, how is the slowness noticeable, and in which situations?

One issue (#158) I wanted to fix for 1.0 will have a significant impact on the core of Fabulous, but I think it will wait for 2.0.

Hmm... That seems like a fairly serious issue that will impact our app (where we occasionally do stuff when navigating). Unfortunately, that means I might have to wait until 2.0 to be able to use Fabulous (or live with some workarounds)... Seeing as 1.0 is still in development, I suppose it'll be a while before 2.0? Do you have any idea of the timeframe for 2.0? (Like, 6 months or 2 years?)

We did have the same issue than elmish/Elmish.WPF#40 and we added a debounce helper to workaround (#237).
Fixing #304 should also remove definitely this feedback loop.

Glad to hear it! Looking forward to the fix for #304.

[TimLariviere]

This is one of my primary concerns. Could you elaborate a bit? Specifically, how is the slowness noticeable, and in which situations?

The slowness is noticeable when going from one page to another (to which you never navigated before). On iOS, it's instantaneous. On Android, you can see up to half a second of wait (still previous screen) after you triggered the navigation before the new page appears.
Other than that, performance are good.
If you want to test that, the ElmishContacts app (on the Play Store) should give you a give idea of this slowness.

Seeing as 1.0 is still in development, I suppose it'll be a while before 2.0? Do you have any idea of the timeframe for 2.0? (Like, 6 months or 2 years?)

Yes, more like 1 year I think.
v0.33.2 is a becoming a good candidate for v1.0 (minus the few big issues we need to fix)
To check progression: https://github.com/fsprojects/Fabulous/milestone/1

[cmeeren]

The slowness is noticeable when going from one page to another (to which you never navigated before). On iOS, it's instantaneous. On Android, you can see up to half a second of wait (still previous screen) after you triggered the navigation before the new page appears.

Thanks. I tried the ElmishContacts app and see what you mean.

• Do you know if the slowness is device-dependent? On my device it's not a deal-breaker, but if it's significantly worse on slower devices, that'd be good to know.
• Do you know what causes it? Is it something that can be fixed, or is it fundamental to the way Elmish works?

Update: See new issue #383

[cmeeren]

I made a separate issue #383 for the navigation slowdowns because I couldn't find any existing issue for it.

With that out of the way, I think my questions here are answered: While I love the Elmish architecture and would like nothing more than for Fabulous to be the most, well, fabulous choice for app development, the navigation slowdowns alone are a no-go for us. Combined with a few other notable bugs (#158, #304), the conclusion for my part is that Fabulous is not yet mature enough to be a safe choice for production apps (low "employer/client acceptance factor", so to speak).

YMMV, feel free to disagree. Thanks for hearing me out and responding to my concerns!