Live data from Hacker News

ElectronCGI – A Solution to Cross-Platform GUIs for .NET Core

blinkingcaret.com

51–60 of 87 posts

Re: ElectronCGI – A Solution to Cross-Platform GUIs for .NET Core

#51
post #48
post #43

What's really needed is a standard GUI markup language (SGML) and probably a dedicated browser, or at least a browser pluggin. Emulating desktop-like GUI's using JavaScript and DOM has proven clunky and unreliable, largely because HTML browser makers do what they want when they want. A dedicated GUI browser wouldn't break GUI's because doing GUI's is its sole purpose. HTML browser makers usually don't care if they br…

> What's really needed is a standard GUI markup language (SGML) What's wrong with HTML? Isn't it already everywhere, including in all browsers? > HTML browser makers usually don't care if they break a particular JavaScript library by adding or tweaking features. HTML and JS are two different languages. One is a markup language, the other a scripting language. If changes to the markup language break a library in the s…

Re: "What's wrong with HTML?"

It doesn't handle "state" well, and lacks common GUI idioms like menu bars, tool-bars, editable data grids, combo-boxes, model dialog boxes/windows, MDI, and others. Perhaps HTML can be modified to do those well, but it probably wouldn't be "HTML" anymore.

Re: "If changes to the markup language break a library in the scripting one, its clearly the library that needs fixing."

I'm comparing the emulation of desktop GUI's via HTML + DOM + CSS + JavaScript + JavaScript libraries to something that natively handles GUI's. Those 5 parts together have proven fragile. The chain is as strong as the weakest link.

Re: "Expecting browser makers to somehow keep their HTML engines backward compatible with JS libraries isn't really realistic or practical."

That's why we need a dedicated GUI markup language and browser (or pluggin). You would be very careful about breaking GUI's if GUI's are your tool's only job. HTML (current) browser makers have a lot of other concerns. Breaking a GUI emulator library is just collateral damage to them that makes them yawn.

Those who tried to do something somewhat similar failed because they put too much on their plate: Flash and Java Applets. They tried to be entire virtual OS's, making them a hacker haven. Lesson: don't be an application programming language, don't be a compiler, don't be an OS, don't be a code editor, don't be a toaster, just be a GUI browser and only a GUI browser.

Re: ElectronCGI – A Solution to Cross-Platform GUIs for .NET Core

#52
post #43

What's really needed is a standard GUI markup language (SGML) and probably a dedicated browser, or at least a browser pluggin. Emulating desktop-like GUI's using JavaScript and DOM has proven clunky and unreliable, largely because HTML browser makers do what they want when they want. A dedicated GUI browser wouldn't break GUI's because doing GUI's is its sole purpose. HTML browser makers usually don't care if they br…

I like your idea and Microsoft probably hoped for XAML to become that standard.

It's fairly close to what I have in mind, but it's also mostly static, I believe. It would need enhancements to handle interaction and UI updates better.

And I'm not sure about its cross-platform abilities, but I haven't tested the limits.

Re: ElectronCGI – A Solution to Cross-Platform GUIs for .NET Core

#53
post #41

Earlier quoted context omitted.

Last I checked (late last year) JavaFX hadn't HiDPI support.

According to the release notes for version 8 HiDPI is supported.

Is that for Gluon? Sorry for not looking it up myself, but it's probably worth pointing out that at least Swing has (kindof) Oracle and a major Java desktop app behind, whereas JFX hasn't seen any love at all. I played around with JFX a couple years ago but there were serious problems with its WebKit integration. Coming to think about it, I'm wondering if there are any plans to integrate JFX and WebKit on GraalVM as a serious Electron contender.

Re: ElectronCGI – A Solution to Cross-Platform GUIs for .NET Core

#54
post #42

Earlier quoted context omitted.

I'm waiting for Tornado to support Java 11+ before I jump on the bandwagon. It's getting closer[1], but it's still not production ready, from what I can tell. [1]: https://github.com/edvin/tornadofx/issues/899

Well I guess that makes it easier. I'd rather write Java than Kotlin anyway.

Really? That's the first time I've ever heard someone say that. What is it about Kotlin you don't like?

Re: ElectronCGI – A Solution to Cross-Platform GUIs for .NET Core

#55

Earlier quoted context omitted.

Would that Java application be capable of running in the browser? JavaFX, maybe?

That "Hello World" example uses Java's Swing GUI framework which is older and does not port to the web as easily as JavaFX. Here is the JavaFX-based "Hello World": https://docs.oracle.com/javafx/2/get_started/hello_world.htm... There are also numerous Java to Web frameworks and solutions like TeaVM ( https://blogs.oracle.com/javamagazine/java-in-the-browser-wi... ), JSF ( https://javaee.github.io/javaserverfaces-spec…

Isn’t that generally the main benefit of using electron based apps? The ability to target both desktop and web?

We can bemoan the inefficiency of this, and how wasteful it is, but at the end of the day, it’s a very portable way of delivering applications.

I think VSCode is a huge success because of this model.

Re: ElectronCGI – A Solution to Cross-Platform GUIs for .NET Core

#56
If it uses Electron it is not a solution.

Even Microsoft's own React Native team bashes on Electron's resource usage.

https://www.youtube.com/watch?v=IUMWFExtDSg

https://www.youtube.com/watch?v=TZnajQqqKV8

About 160% more resource usage, ideally to use a computer as heating replacement.

Re: ElectronCGI – A Solution to Cross-Platform GUIs for .NET Core

#57
post #12
post #3

Steve Sanderson (creator of Blazor) is working on something similar that doesn't use Electron: https://blog.stevensanderson.com/2019/11/01/exploring-lighte... From Blazor roadmaps a few months ago, I think the idea is that Blazor will become the recommended .NET Core cross-platform UI choice sometime after .NET 5.

But the big advantage of using Electron is that you know exactly what browser and Node version you are targetting. That takes away a lot of the cross-browser HTML/CSS pain.

Except for the users that have to take with dozens of Electron instances running on their low to mid range computers.

Re: ElectronCGI – A Solution to Cross-Platform GUIs for .NET Core

#58

Earlier quoted context omitted.

One of the comments on that blog leads to WinUI, which I would assume Microsoft would recommend first https://github.com/microsoft/microsoft-ui-xaml/blob/master/d... Not sure if it's cross-platform though.

Microsoft is not a single entity; there is plenty of room for innovative ideas like what Steve has that challenges the status quo around formerly innovative ideas like electron. We certainly have no shortage of highly successful electron apps at the company either (e.g., VS Code and Teams).

I don't consider the return of MSHTML or XUL an innovative idea.

Re: ElectronCGI – A Solution to Cross-Platform GUIs for .NET Core

#59
post #13

This is a great step forward, but it seems like a great deal of overhead and complexity to have a cross-platform GUI. If I were creating a new cross-platform desktop application I would probably reach for Java instead. I know that's not the popular answer, but if a .NET Core cross-platform GUI requires either using Electron or simulating a client-server setup with Node then it's not there yet. To illustrate, here is…

Good luck getting that Swing app to look nice, though. Which is a breeze with HTML/CSS.

Not only it is a breeze, after reading books like "Filthy Rich Clients", I have full control over hardware acceleration instead of playing CSS tricks with Z ordering in the vain hope that the browser will do the right thing.

Lack of design skills doesn't improve just because one changes UI stack.

Re: ElectronCGI – A Solution to Cross-Platform GUIs for .NET Core

#60
post #47

Earlier quoted context omitted.

Customizing the appearance is one place where Swing's age shows. It is possible to create a custom "Look and Feel", but it is not as easy as HTML / CSS: https://docs.oracle.com/javase/tutorial/uiswing/lookandfeel/ JavaFX does allow CSS to be used to style it: https://docs.oracle.com/javase/8/javafx/user-interface-tutor...

I remember >10 years ago there used to be some "plaf" libraries that provided very easy themeing abilities for Swing that even came with a WYSIWYG tool to create themes. It is a shame something like that never became part of Swing itself and instead you have to create tons of classes just for a theme.

Or actually buy them.

http://www.jgoodies.com/ is still in business, to give a possible example.

Post reply on HN