[zaSmilingIdiot]

> There's a reason every single company wants to just build web apps and electron apps, because it's actually the best and simplest platform for delivering a cross platform UI [...]

Maybe, but consider that possibly the reason why many companies go that route is more to do with financial incentives: it provides for the cheapest option (both in terms of resource costs and time), while still retaining complete control over the use of the software (and consequently their revenue generation). Even ignoring the latter aspect of that, its cheaper to have 1 team build out a single interface than multiple teams each working on platform specific interfaces. Then theres a follow-on reduction in support (and troubleshooting) costs in dealing with platform specific updates, less coordination/communication needed and thus reduced need for management level resources, etc etc. Theres also lower costs in terms of skills the company is hiring.

I'd also extend that to the possibility that the prevalance of tooling such as electron and its kin is a response to a demand for it, rather than arising out of being "best in class".

So best and/or simplest platform... well that depends on whats being measured. From a financial perspective, sure, why not. Other measures though... Im not so sure.

[tripleo1]

> ... web apps and electron apps

Can you now consider NOT Flutter with respect to the above?

Also, remember Titanium SDK?

thx

[zaSmilingIdiot]

Is Flutter as ubiquitous as html/css/js? Is it similarly cross platform?

I responded to the suggestion that every company was choosing electron (html/css/js) because it was the best and easiest, by pointing out that the reason it might be picked may not have anything to do with simplicity or being the best choice, but rather based on other factors (like financial motivations). Flutter is a different toolkit, and isnt the typical "web page" type building of application UI, and so was outside of the scope of my original response.

I've never used Titanium, but have used similar types of toolkits... all of them, regardless of whether they compile to native apps or not, are (very broadly) generally selected based on the criteria mentioned in my previous comment: why build out different platform native apps when you can largely get by with a web dev(s) building a single app that compiles to the native system? Theres tradeoffs involved, and the typical optimisation in an org is to favour lower cost and/or quicker market time. Theres the "we can do it better later when we have the money to" mentality, except once a system gains enough traction, that perspective changes to "why spend time and budget on changing something thats working". The term "working" though, is subjective... its "working" for the org, but is it truly "working" for the user that is interacting with it?