Electron Apps Are Bad, So Now You Can Create Desktop Apps With HTML5 + Golang

[ssokolow]

Electron apps are bad because HTML5 on a desktop is bad. You can replace JavaScript with Go but that doesn't solve any of the issues in terms of user interface consistency, integration, accessibility support, ease of localisation and all the other problems that make it a terrible idea to begin with.

Not to mention that throwing out JavaScript just makes things worse because all of the frameworks which serve as cheap hacks to make it possible for people to make an HTML5 UI that even remotely resembles HIG-compliant are written in JavaScript.

[jacob]

Electron apps are bad because HTML5 on a desktop is bad. You can replace JavaScript with Go but that doesn't solve any of the issues in terms of user interface consistency, integration, accessibility support, ease of localisation and all the other problems that make it a terrible idea to begin with.

[Jabberwocky]

atom eats 30 of CPU time on my i3-4030 with 2 files opened. on the other hand, Visual Studio 2017 is below 10% when I just edit project files (of course while compilation it eats much more, but we can not compare it, because atom doesn't compile anything except it's fucking js.). recently I had to start using a postman. I wondered why this tool is so fucking slow. I wasn't surprised when I findout that it uses electron. this "technology" is cancer for destop apps.

TL;DR Do some research, the only thing you are correct about is that atom is slow.

Electron is a framework that provides a (massive) runtime. It supports for javascript code via nodejs which uses Google's V8 JIT engine. You don't have to write you code in javascript in order to use Electron, but since most people do lets ignore that for now. The inherent runtime performance hit for desktop apps from is something that should only be noticed on benchmarks not in actual use... even when using it on an slow i3 running under 2Ghz. VS Code is a good example of how practical Electron apps can perform. It is written in typescript and runs via v8 engine within nodejs within Electron. Electron has not always performed well. Electron is flash for the desktop was well written post with mostly accurate research. Things change quickly though, in 2019 performance is really not bad but still can be improved.

It is extremely ignorant to say that Electron is bad because atom and postman is not written well. I would argue that electron is theoretically one of the best truly cross-platform GUI frameworks that exist today. The remaining resource hogs comes from the underlying components used mainly nodejs/v8. Instead of optimizing code specifically for nodejs/v8 (which can solve many problems at cost of development time), it would be better IMO to replace it with other parts. The only project that I know of currently is Positron that unfortunately was discontinued. We might see more projects in this area when web-assembly becomes more used.

Javascript is arguably the worst designed popular language. The insane amount of development time from talented engineers has improved performance and semantics (native and preprocessors or supersets) which allows developers to do really cool stuff with it. The loose design at least allows it to change very quickly with backwards compatibility.

From a user's perspective I shared your frustration from 2013 H4 to 2018 H2. Using slack for multiple organizations ~10. From a developer's perspective I can't really complain, I wasn't paying for any Electron based apps (slack, vscode, etcher). I am a huge fan of Qt applications (vlc, telegram-desktop, teamspeak, battle.net etc). Personally find the cross-platform support is better than it's rivals but from developer point of view (single source project) you can't compare a desktop GUI lib to Electron at least not now. The ease of use (low cost) and portability is unmatched.

Back on topic with regards to Lorca, I want to encourage any new project but it's not easy. Relying on the system's browser is not really viable IMHO.

[ssokolow]

In some ways we already have some features like that in the browser. For instance you can do zoom on mouse hover with CSS:

https://www.w3schools.com/howto/howto_css_zoom_hover.asp

There is no javascript required and thus no garbage collector + interpreter/JIT step. It's some (hopefully) well designed Rust or C++ code pre-compiled to machine code, handling the transformation.

I bet there is a lot of stuff done in the general-purpose JavaScript language that could be replaced with some nice markup language and special elements (like your <time> example).

Yeah. I like to keep up on that sort of thing. I don't hold out much hope though, given things like retiring the effort to define an <iframe seamless> and making the definition of HTML components inherently dependant on JavaScript to bind the template to the custom tag when the JavaScript call isn't doing anything you couldn't do with HTML attributes in a more gracefully-degrading way.

[fuzz]

That will have zero to do with Electron...

Are you so certain? Have you not heard of WebAssembly?

[Delgarde]

what are you even on about? Server has no clue about client time display settings. I have mine to some ISO standard instead of dutch time format. It doesnt have to be a UNIX timestamp. it could be UTC time format. As long as there is an element that converts it to the clients native format.

While I'm not aware of any way of doing it in pure HTML, it can certainly be done in client-side Javascript with the new-ish Intl APIs... e.g:

new Intl.DateTimeFormat().format(new Date())
-> "11/02/2019"
new Intl.DateTimeFormat('en-NZ').format(new Date())
-> "11/02/2019"
new Intl.DateTimeFormat('ja-JP').format(new Date())
-> "2019/2/11"
new Intl.DateTimeFormat([], {year: 'numeric', month: 'long', day: 'numeric'}).format(new Date())
-> 11 February 2019
new Intl.DateTimeFormat('en-NZ', {year: 'numeric', month: 'long', day: 'numeric'}).format(new Date())
-> 11 February 2019
new Intl.DateTimeFormat('ja-JP', {year: 'numeric', month: 'long', day: 'numeric'}).format(new Date())
-> 2019年2月11日

[caligula]

Do you see the language situation improving in the future?

Sure. We have great languages these days. All the compilers and runtimes are constantly improving. It's still a bit disappointing that C/C++ compilers are so good compared to other compilers and this encourages people to stick with C/C++. If the other languages had such mature tools, switching to a new language would be much easier. Nevertheless, it's really great that the C/C++ compilers are in such a good shape.

WebASM - there's a growing number of languages that you can now compile into WebASM. If the WebASM API is expanded, we may be able to use that as an alternative to Javascript. Not ideal, but an improvement.

Yes, it's good that the web apps switch to a real bytecode format. But this is hardly revolutionary. Pascal community envisioned offering apps in bytecode decades ago. For example, the C# CLR bytecode has a long history. The C# lead previously created J++, Delphi, and Turbo Pascal. WebASM might be more suitable as a bytecode for JavaScript, but IMO it's a step backwards compared to what Anders Hejlsberg had already achieved.

On Apple systems devs are now frequently using Swift. I haven't tried Swift, but it does look far nicer than C++ (which is the closest equivalent to it). Unlike Go, Swift isn't garbage collected, so I think it has potential for being used for system programming and game engine development.

I don't have a Mac, but yea, I believe Swift attempts to solve similar problems as Vala, Go, F#, and Rust. There's also OCaml, which reminded me of this guy http://flyingfrogblog.blogspot.com/2...n-web-age.html

[brrrrttttt]

With Microsoft owning Electron, I'm just waiting for the day when they announce C#/XAML bindings for cross-platform desktop apps compiled from Visual Studio.

That will have zero to do with Electron... Also, XAML is a hot mess.

[fuzz]

With Microsoft owning Electron, I'm just waiting for the day when they announce C#/XAML bindings for cross-platform desktop apps compiled from Visual Studio.

[cybertraveler]

I was saying that it may be possible to do something like augmenting the HTML5 <time> element with an attribute that says "If you support this attribute, ignore the contents of the text body of the time element and render the contents of the datetime attribute in the user's local timezone in accordance with their locale settings."

Something like this, where the localize attribute would invoke the behaviour in supporting browsers:

<time datetime="machine-readable date as spec'd" localize>fallback text</time>

"Without JavaScript" doesn't automatically mean "server side" and there is precedent for HTML elements where the text body is intended as a fallback for unsupporting browsers.

In some ways we already have some features like that in the browser. For instance you can do zoom on mouse hover with CSS:

https://www.w3schools.com/howto/howto_css_zoom_hover.asp

There is no javascript required and thus no garbage collector + interpreter/JIT step. It's some (hopefully) well designed Rust or C++ code pre-compiled to machine code, handling the transformation.

I bet there is a lot of stuff done in the general-purpose JavaScript language that could be replaced with some nice markup language and special elements (like your <time> example).