Earlier quoted context omitted.
Non UI code lives in a static/shared lib that gets called from UI code. The non-UI code shouldn’t be coupled to a UI at all, instead reporting progress/completion via callbacks or other notification mechanisms. If you must run on every platform for whatever reason, there is Rust, C, C# (Xamarin), etc.
That's a valid architecture, but it's not a cross platform UI library that uses fully native looking UI on every platform which is what I'm skeptical of working.
From Markdown to remote code execution in Atom
151–152 of 152 posts
Re: From Markdown to remote code execution in Atom
#152Earlier quoted context omitted.
All your positives about Qt can be applied to electron but even better. From a business point of view electron is a winner. For example at our company we have built a desktop app, web app, salesforce plugin, chrome extension, outlook plugin, cli app, and are working on mobile apps all using one JavaScript codebase. It’s a business and developers dream. There really is no competition and any claim to the contrary woul…
Electron is not really fast, nor does it generate great GUIs. It's much younger than Qt, only four years old. It's not frequently updated, it uses an insecure version of the Chromium browser. So... not all positives can be applied. In fact none can be applied except ease of use and it's about the same, until the app grows and one realizes that the typical JS architecture is as easy to structure as a pile of mush. Ele…
You have your unshakable opinions and I’ll leave you alone with them.