Live data from Hacker News

From Markdown to remote code execution in Atom

statuscode.ch

151–152 of 152 posts

Re: From Markdown to remote code execution in Atom

#151

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.

I'm late, but I think wxWidgets tried this. It was OK, I wrote some stuff with it, but mainly targeted Linux. There were definitely some differences in widgets between platforms, but it looked pretty good for not much effort.

Re: From Markdown to remote code execution in Atom

#152
post #108
post #16

Earlier 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…

I absolutely disagree with all of your statements and think they are equally unjustified.

You have your unshakable opinions and I’ll leave you alone with them.

Post reply on HN