Change core to Flutter?

[clsource]

Maintaining two code bases is though, specially considering the small team we have.
I'm no expert in Android nor Flutter. But I think is a reasonable investment to learn Flutter in order to create a new core that could be easily maintained by a small number of people.

Please, I would like to receive some feedback before any futher actions.

Thanks :)

[dumblob]

Flutter seems to get traction over the course of the last 4 years. On the other hand, I'm pretty sure it'll (by far) not become any more widespread as existing huge frameworks (e.g. maintained by Facebook, Apple, etc.). That being said, I don't think Flutter would ease development/maintenance of Jasonelle any better than any other huge framework.

On the technical side, yes, Flutter has some nice properties. But it has also some really not nice properties and in the end I wouldn't say it's any better than the best other frameworks.

So in the end a subjective poll (who would prefer what) would be better than arguing about objective reasons to go for Flutter, because there will always be many strong contra arguments 😉.

---

My subjective observation: if Flutter were in practice really better than others by a significant margin (as it's being regarded by some), it wouldn't account only for this fractional negligible part of market. IMHO what holds Flutter back is its whole ecosystem, not the core technology itself (which is anyway slowly being superseeded by even better & easier to use concepts).

[clsource]

Thanks,
Yes at the end is no different in the ease of development. The difficulty of implementing a new core its the same regardless of which stack its chosen.

But we seriously lack contributors in both Android and iOS.

I hope the maintanence burden will be more slim if the core technology stack can have more contributors and people who can help with code.

Since Jasonelle is not a company nor I have funds to hire dedicated iOS and Android developers is difficult to maintain both projects with same peace, features and bug fixes.

I would love to have 100% native Kotlin and Swift projects. But that would require huge amounts of time and effort that I currently cannot afford.

If better techs are available and alternatives to Flutter I would love to try them 👍

[dumblob]

Let's think up some numbers 😉.

approach	average cost per year after any bigger transition is over
Jasonelle maintenance/development with current setup (i.e. Android separate from iOS):	x manhours
Jasonelle maintenance/development with Flutter setup (i.e. Android and iOS exactly the same):	x/2 manhours (because only one "app" will be needed)

Now assume bringing Jasonelle-Flutter from zero to the current state of Jasonelle will take maybe 5-10 times x manhours. So throughout the next 5-10 years, there'll be double (current Jasonelle maintenance/development and at the same time Jasonelle-Flutter dev.) work needed to get Jasonelle-Flutter to the state of at that time 5-10 years old state of the former Jasonelle.

Ok, this is overly pessimistic, but I just wanted to flash out what I have in mind when working with "big" technologies/platforms/frameworks.

On the optimistic side, I'd guess we can ignore the 5-10 years slip (as outlined in my last sentence of the prediction above) because the painful "exploration" will not need to be done and thus an "exact" specification is already known and can be thus coded immediately without taking any closed roads.

Second positive thing is, that there might be some newcomers helping out with that (this has many reasons: first, PR about rewrite reaches more people than just "yet another maintenance release of Jasonelle", second most programmers prefer to work on new stuff because they feel much more freedom than when working on existing big codebase, third Flutter/any_other_modern_framework has more motivated users than the current "stable/legacy" technology, etc.).

Third positive thing is, that if x was so far as low as tens to low hundreds of manhours, then making it thrice or more times bigger with even one or two motivated newcomers is actually quite easy (i.e. realistic). So it might take less than those 5 years.

---

One more thought: what about commercionalizing it a bit? I mean not to change licensing to a commercial one, not to change governance, not to immediately start any business etc. But just do the necessary mental shift and only change the web page for now - for such purpose it should be completely redesigned (search for "PR" or "marketing" site designs on https://screenlane.com/ ) look like a professional service (consulting & commercial support) built upon a mature product. If anyone contacts you, then we can think how to deal with it (formally starting an organization/company or getting a freelance license is a matter of one day usually and can be done after the first request for professional support comes).

[clsource]

Yes it would be reworking some parts and could take some time. But is not needed to reach the current state of Jasonette in the new version. Many of the current features can be developed as a plugin or extension instead of the core. I think most of them are underused (Most of the projects I have seen over the years are just a wrapper around a website, push notifications and some components like layers and timers) and can be externalized and have its own set of maintainers and versions.

The idea would be a slim core and a set of most used extensions. Other extensions can be gradually implemented if the usage demands it or some other member of the community implements them. Most of the core functionality can be reused from the current version since its written in JS.

Similar to Laravel framework that the core is slim and all the other functionality is done by plugins.

The problem with the current state of the art, hence the need for a new core. Its dependency hell, outdated code and low trhoughput of fixes and new features due to the complexity of the codebase and in both android and ios.

---

About the monetization part. I quite not sure of it since this is a project made by a lot of different contributors and earning money as a organization would mean to somehow pay them a portion of the profits, which unfortunally is logistically impossible for me to do so right now.

What I currently try to do is some freelance works from here or there, but it was never a sustainable way of earning money for me.

[dumblob]

Yes it would be reworking some parts and could take some time. But is not needed to reach the current state of Jasonette in the new version. Many of the current features can be developed as a plugin or extension instead of the core. I think most of them are underused (Most of the projects I have seen over the years are just a wrapper around a website, push notifications and some components like layers and timers) and can be externalized and have its own set of maintainers and versions.

The idea would be a slim core and a set of most used extensions. Other extensions can be gradually implemented if the usage demands it or some other member of the community implements them. Most of the core functionality can be reused from the current version since its written in JS.

Oh, than it's by far not just what I thought. This sounds great! Thanks for sharing these plans/ideas/goals!

---

About the monetization part. I quite not sure of it since this is a project made by a lot of different contributors and earning money as a organization would mean to somehow pay them a portion of the profits, which unfortunally is logistically impossible for me to do so right now.

Understood. This will sound harsh, but the idea was truly the "capitalistic eagerness" - e.g. on the first come first serve basis. In other words, nobody could say a word if you did simple "publish subscribe" mechanism (i.e. those who'd like to get potential business offers would subscribe first and then you'd just resend the customer requests to all subscribers and the first one who'd be eligible in terms of law as claimed by her - realized through a simple declaration towards you - would simply get the contact of the customer and hey, thing done).

This way you'd not have nearly any work with that and the product could thrive. Later you could start sharing the "publish" right with others to increase the bus factor, but it's not necessary for the beginning (it's ok to leave the domain expire and let someone else to pick up in the worst case).

What I currently try to do is some freelance works from here or there, but it was never a sustainable way of earning money for me.

Same here 😉.

[christianswanepoel]

Could be interesting to trawl Flutter hangouts and find keen contributors? I mean Jasonelle has history and some Flutterers might like to get behind this.

[christianswanepoel]

I think it's a great idea to unify codebase!

[clsource]

Ok I gave thought to this matter and after some coding I have some resolutions:

1 - Learning a complete new programming language and environment is though enough. So my time would be better spent learning Kotlin and Android than Flutter.

2 - If the codebase is solid and have a well documented architecture it can be ported to other runtimes. So first I will make something in the technology I have more knowledge of (Objective-C) and then something can be developed to other runtimes based on the docs.

3 - I have decided that is best to continue with the native route. Since many of the plugins and extensions can use native SDKs. Having something like a middle layer like flutter would be required to . 1 first adapt the SDK to flutter bindings. 2 then you can implement Jasonette bindings. An extra layer like flutter would require an additional binding, so it would not be pleasant.

4 - I want the new core to be super slim and minimalist. And have extensions that could be implemented and be optional. So people can choose. The idea would be a cohesive environment with selected plugins that work well together.

5 - The main programming languages would be Kotlin (primary) / Java for Android and Objective-C (primary) / Swift for iOS. The idea is that the primary language would be the most used and the secondary language only used if there is no other option.

6 - Minimize the dependencies. Try to stick with the available tools for the native SDK as much as possible. Without implementing Gradle or Cocoapods if an external dep is needed (manual import). This is for ensuring a slim codebase and adding a dependency would be a thoughful process for avoiding it as much as possible.

7 - The current versions (Jasonette 2.1) I want to stop develop them because the codebase is hard to grokk. So the idea would be to add a few more fixes and then focus on creating the new core.

[dumblob]

Thanks for the write-up and valuable insights! I like it.

It actually reminds me exactly of the situation Delta Chat was about 2 years ago. In the end they chose the very same architecture as you're describing (universal core with a comprehensive API and then just shims for each of the platforms - in their case Android + iOS + Electron). They even decided to not only share the API, but also the whole core codebase. For that they chose Rust (though it could have been C++ or C or maybe even other language which compiles for both iOS and Android). The first year was enormously tough - both because of Rust (one just needs to learn a lot about the beast) but especially because of the radical change in the architecture (in other words the toughest was the decoupling, not the programming language nor anything else - but it pays out!).

Nowadays one cas already see it was a great choice - the trend actually changed and from initially planned minimal core it became a fatty core. But the reason is simple - after they've built a minimal core it was much easier to extend it and just connect e.g. a button in each of the UIs (iOS and Android) to the backend API call. This way the iOS and Android apps became a very thin and lightweight code bases with no logic.

But I myself can not easily imagine Rust powering Jasonelle core (ask for the reasons if you like). What I can imagine though is - quite surprisingly - to use Swift for the core (no Objective-C, sorry) and use it on both iOS and Android with zero code duplication.

Thoughts?

[clsource]

Swift is a great language, but is another one that I would have to learn before doing something meaningful. It beast that I stick with the languages and technologies I already know to allow quick prototyping.

Also the core must be implemented in the native language of the platform because the need for accesing low level apis for example JavaScriptCore framework.

Rust can be used through static libs both in objective-c and android. So it is a possibility for using common utilities compiled in rust and link them as static lib. But that is something to be seen later.