Hacker News Reader

Comment by anticnstrctv | Hacker News Reader

Does anyone else feel that there's a huge hole in the UI world?

I like the electron/react/react native ecosystem - I really do, and this is coming from someone who dislikes javascript a priori. But is HTML/CSS/JS really the best we can do for desktop and mobile applications? I know responsive-cross platform saves money for a lot of startups and orgs, and I'm not saying the web stack doesn't have it's place.

I frequently imagine something that takes the best ideas from react/redux and from other ui and layout frameworks and lets you build something that has consistent, cross platform (desktop and mobile, maybe even web with some kind of compilation pathway to js or webasm), responsive ui, without the huge web stack. Maybe Python? It's got lots of competent developers in the market to support it. Maybe Rust or Go, if something lower-level was desired. Or language-agnostic, though sticking with one might be valuable.

View on HN

Yes, I think we all feel it. Every UI lib has something wrong: C++ sucks and is hard to iface w/ other langs (Qt, wxWidgets), not enough widgets (IUP, libui), not native enough in my OS (GTK), carries a full browser (Electron, nw.js), carries a full JVM (JavaFX, Swing), etc, etc. And then every subreddit and community always has people asking what's the best UI lib for language X. We all travel back to awesome-lang-X lists' GUI section every so often hoping someone will finally fix it.

Qt or wxWidgets, make a supported C iface (I am aware of some work on both fronts, e.g. wxc that was used by wxHaskell I think?). IUP and libui, thicken your libs (libui guy just got permission from his new company to get back working on the lib, yay). World, don't hate non-native-OS-widgeted apps. Browser vendors, stop being so tunnel-visioned into your my-OS-only, non-embeddable, or must-be-multiprocess shit. And let us trim some fat off at compile time please (waiting on you Servo, but please stay lean and single-process for embeddability). JVM AOT...we're waiting, we know it's coming.

And no, I would rather not have an interpreted (or dynamic) language if I can help it.

Edit: To clarify before a ton of responses pick apart my specific criticisms, I'm making these points to show there is a void. I could poke a ton more holes in these libs and more (I have used most), but it's hardly worth arguing the nuances here.

Both Qt and wxWidgets have bindings for a bunch of languages. Also, in case AOT compiler comes to Java, JavaFX and Swing might become viable options as well.

In many times bindings are:

* incomplete

* immature

* not up to date

and definitely out-of-tree, aka not maintained by the folks that make the original toolkit.

Would you bet your company on those bindings?

Agreed, Qt binding are only officially supported for C++ and Python is a major player here as well, Golang has quite good bindings but a few minor methods per class as still missing, it's good enough to write a major desktop app tho.

Yes, but some of them are of very high quality, such as wxPython or PyQt.

And to be honest, modern C++11/14/17 is quite a different language, more friendly to beginners compared to 90s C++ people remember.

Writing C++ with wxWidgets or Qt really feels like Java or C# with their batteries.

There are bindings and there are bindings. I'd bet my company on PyQt - if anything I'd say bugs get fixed there quicker than in Electron. But part of the reason for that is that PyQt is a commercial (dual license) project with a dedicated company behind it.

>Also, in case AOT compiler comes to Java

What? AOT is available in Java even on Debian, the next step is Java-on-Java stack. HotSpot is about to be deprecated in 4 weeks once Graal becomes default for all platforms in Java10.

> java --list-modules | grep aot

> jdk.aot@9-Debian

I'm not in Java world, but I remember there were talks about future AOT awhile ago - is this a thing now? i.e. you don't have to ship the whole JVM, and no more bytecode, just a native executable?

If this is a thing now, supported and official - why it's not more popular? (or maybe I'm wrong).

Because of the crowd that doesn't want to pay for AOT compilers.

The majority of commercial JDKs always supported AOT to native code, only Sun did not, as they were religiously against AOT.

Oracle thankfully thinks otherwise, has kept sponsoring MaximeVM research, which became Graal and SubstrateVM, and now they are in the process of even re-writing the C++ parts into Java (Project Metropolis).

>I remember there were talks about future AOT awhile ago - is this a thing now?

Yes, AoT is now supported in Java out of box. Java after Jigsaw projects is modularized and you can build an executable file, like .exe or .bin which contains minimal JVM in it with JVM modules and your own modules and it's dependencies. You can read more about it here https://steveperkins.com/using-java-9-modularization-to-ship...

>If this is a thing now, supported and official - why it's not more popular? (or maybe I'm wrong).

Probably because a lot of developers still think Java is slow, many peoples opinion on Java is from 10 years ago. AoT was officially released in OpenJDK a few weeks ago, so as you can see, a lot of people don't know about it yet.

With Java 9 jigsaw and jlink you can now build fairly light JavaFX apps. The entire jre no longer has to be bundled. Only the pieces you're using.

I recently started experimenting with JavaFX. I was pleasantly surprised how nice it is, and how easy it is to package application bundles.

Looks like that's about 45 MB [1]. For comparison, Electron is about 80 MB. Qt starts at 50 MB depending on what you need, but a few years ago I got it down to 16 MB with UPX and a customized ICU. Gtk starts at ~20 MB and compresses to about half that with UPX. You could probably get those a bit smaller if your license permits static linking, but then you have to write C++.

[1] https://steveperkins.com/using-java-9-modularization-to-ship...

Unfortunately JavaFX still does not support Wayland, just like most Java GUI things (except for SWT which seems to have some support https://bugs.eclipse.org/bugs/show_bug.cgi?id=516841)

Given the progress of Wayland's adoption, I don't see it as a major issue.

It's interesting that you mention that GTK is not native enough, but do not mention that for Electron. It looks like (and I feel this way) GTK hits the uncanny valley, whereas Electron is different enough (and applications written in it are used to spending effort on looks) to not run into that problem.

otoh, I think that with Electron, people are sufficiently acclimatized to web apps for them to feel at home with it. GTK feels like a java app.

Yup. The default interface for almost every normal users these days is a web interface. Yes, there are mobile apps, but even on mobiles, users will need to use websites, despite the best efforts of vendors at lock-in into their walled app gardens.

Heck, even on desktops, sometimes the UIs feel quaint and antiquated: no back button/undo by default, many times scrolling failures at different resolutions (the settings screen doesn't fit at a certain resolution and the button is out-of-screen somewhere), text can't be selected and copy-paste by default...

I find this inconsistency interesting as well. It's like if you used a "flat" GTK theme and avoided traditional UI elements like MDIs, menus, and toolbars, you'd be divorced enough from native to leave that criticism behind (granted there are others). I think this is what makes QML, JavaFX, and HTML+CSS more popular recently...desktop-like expectations are out the window (per se) before you start.

> JVM AOT...we're waiting, we know it's coming.

https://www.excelsiorjet.com/

It might as well not exist in this day and age: https://www.excelsiorjet.com/#pricing

Yes, you can argue: "that's not fair", "for a professional programmer that's worth only a few weeks of work's for massive productivity improvements", etc., but things don't work that way.

Most developers have been conditioned to not use commercial products, if they can. With an extra downside for the commercial product being closed source.

That was only one example, and I explicitly mentioned Excelsior instead of other alternatives, because it is free for open source projects.

Fun aside, I once wrote a JVM AOT [0]. Instead of compiling to low level code and building my own GC and runtime, I just transpiled to Go. And it worked, but the Go compiler couldn't handle it well[1] so I started trimming identifier names and shortcutting JRE libs to use Go versions. It became tedious so I gave up. I should revisit that project one day, heh.

0 - https://github.com/cretz/goahead 1 - https://github.com/golang/go/issues/18602

There is a void because OS vendors are actively hostile to top-notch cross platform UI toolkits. They learned their lesson from software companies of the 80's and 90's: https://www.joelonsoftware.com/2002/06/12/strategy-letter-v/

Making a super high quality cross platform UI toolkit is very hard, both in regards to core implementation and maintenance. Open Source did its best, but it apparently wasn't enough. Commercial vendors can't really get adoption cause everyone expects free and even Open Source solutions.

I feel that there's a catch-22 somewhere here :)

But isn't web browser currently is a de-facto cross platform UI toolkit for displaying web pages it is just that we managed to make web pages look and behave more like apps.

So it is definitely possible to make a framework/toolkit although if you look at development history of browsers how many years it took them to get where they are and Opera throwing in the towel and switching to Blink.

Only question is, if they do such a toolkit what is there remaining for OS vendors to do? Kernels? Users will just choose faster one.

The browser is a cross platform UI, yes.

But is it on-par with native offerings? Where are the standardized components? How many years did it take to get a simple grid layout present in Tk back in 1991? Where's the fool-proof GUI editor? How long did it take for it to have a date input?

The web had to fight its way to where it is now. And that's why it has so many scars (besides the self-inflicted DOM and Javascript before strict mode and ECMAScript 5).

Regarding the OS vendors, well, yes, kernels, tools, basic apps. Also not all applications are graphical.

Native offerings kinda suck too I don't know any standardized one. Swing, QT, GTK all look different depending on the OS.

Before web stack there was Flash it had hardware access but it was insecure, now web tech going the same way with web assembly and webgl.

"Swing, QT, GTK all look different depending on the OS."

They're supposed to. They're fitting in with the OS's native look and feel. And that's a GOOD THING.

Exactly, and building a UI framework as powerful as the web tech is very hard.

It took decades of development and an immense amount of resources - the current web engine we all use is the work of dozens of developers from KDE, Apple and Google. If we could've got those all to collaborate on a native UI toolkit you could probably have got something equally good, but such a joint Apple-Google project would probably have been politically impossible at both companies.

Sorry if I go OT, but I wouldn't know where else to ask this since the question comes from the article you linked.

So, by the logic of making your complements a commodity, what is FogCreek trying to make a commodity of with Glitch? Are they trying to make "building apps" (and thus "getting into programming") a commodity so they get more users to StackOverflow?

Also, does anyone have any good material to suggest on this topic? I'd like to learn more about it and learn how to be able to recognize the things for what they are: complements or products.

Well, as I think Joel says in the article, you want some sort of Econ 101 textbook. Regarding FogCreek, you need to be aware of the whole picture: when Joel's talking about strategy, especially at that level, he's talking about big companies. Fog Creek doesn't have the kind of pull necessary to really care about complements or substitutes. Their strategy is probably: "fill whichever niche we deem free" :)

Oh yeah, I was thinking of something more specific, but I'll look into that too.

Well but then there's a big missed opportunity there, isn't it? I mean, it sounds like a principle like that would apply to most scenarios, unless you are too small to even think of making an impact on your complements markets with your financial power. In that case, sure.

I think part of the UI problem is more fundamental than UI.

The only common ABI among all programming languages is C. For a UI lib to work with all languages, we end up with wrappers for C libraries. If not we end up with language specific libs like Swing. We need a common ABI that's better than C.

I agree with you, and I tried my best to change things.

A few years ago I made Anvil - a React-ish framework for Android for native UI (reactive, declarative, works best with Redux) and have been using it in many production apps as long as I was doing Android development. But it still is a niche product, most developers prefer visual UI editor and whatever is the official Google way to do Android apps. Still, I'm very proud of Anvil.

https://github.com/zserge/anvil

Then, once I had to deal with desktop apps I figured out that HTML/CSS/JS seems to be the best option for custom (no native widgets) and modern (animations, shadows, nice fonts etc) UI. But Electron was a heavy beast, so I made a tiny wrapper over native browser engines (webviews). So far I'm very happy with it, it's much lighter and smaller than electron. And it's very convenient to use from C++ or Go. Some kind people added Rust and Nim support, I'm now working on Python and Node.js bindings. So yeah, it's pretty much language-agnostic, although it's still web UI.

I really hope it can take it's niche for small desktop apps that don't need the full power of Electron, yet need to have a good look.

https://github.com/zserge/webview

Been enjoying your library webview for some small home projects. Thanks!

I'm not the biggest fan of this sed reinvention of PostScript we call the browser stack, but my main problem with Electron and the like isn't this, but their design target: Making desktop apps look and feel like web apps.

We're throwing away all kinds of HIG achievements since 1984, for the sake of pretty colors and superfluous transitions. Not too long ago, a considerable effort was spent to make web apps behave like desktop apps, now the inverse is true.

I blame the rise of "UX", just like "DevOps" is too blame for needless infrastructure.

  Making desktop apps look and feel like web apps.

This is a good point. However, it does seem like web and mobile apps and their ilk are the future for the bulk of software the majority of people use (excluding, let's say, "Pro" apps like photoshop, excel, dev tools). I'm not a huge fan of this, but the times have changed. I'm not sure that traditional desktop apps are really what I'd use the hypothetical framework I described to build.

Something like my business expense tracking app, though? If I wanted it to sync and be functionally identical to the app on my phone? I could see this framework being used for that.

> I blame the rise of "UX", just like "DevOps" is too blame for needless infrastructure.

you can't just drop a sentence like that and not elaborate on it - unless you want to offend somebody.

Each resource hungry "DevOps" tool has its place and has its worth. They're just often misused. A small IT firm with <10 Hypervisors won't need openstack for example. Thats only worth its maintenance if you're working with tens or hundreds or hardware machines.

And a webapp which consists of <10 services probably doesn't need service discovery and advanced de-/commissioning of containers/vms. Administering hundreds of microservices without that is borderline impossible however.

DevOps as a practice isn't wrong, of course. Sysadmins scripted and programmed since the dawn of the silicon Pleistocene. But if every small company hires someone with that specific job description, well, you have to spend your 80+ startup hours somewhere.

UX is not some evil witchcraft, it is an accumulation of best practices that are not based on hunches that solo developers conjured up out of thin air, but resulted from measuring user feedback.

We used to call that "usability", and it was mostly done on the OS/API level (cf. Tog's work at Apple). In the web space, I see way too many individual practices (as what's "best" in the long run across all domains might not be the "best" at funnelling people through your web app).

Never mind that if it's your sole job, you have to demonstrate value and that often leads away from generic solutions.

But you cant solve this on OS level, really. People read New York Times differently when compared to how they shop and want to checkout.

People browse Stack Overflow and hacker news differently too. There is no set of rules that are generic AND usable in all these cases.

And you do not read a Medium.com article the same way you set something up with your goverment in a goverment website, browsing through hundreds of options.

But why bring this misery to desktop apps? A lot of this arose out of the lack of standards and (initial) widgets in a browser.

Not that I believe that the amount of different interaction patterns is justified on the web; the lack of almost any kind of standard widgets just made this a free-for-all bikeshedding design space. In the long run, I doubt that your measurably superior solution to editing an entry in a grid is better than using the same pattern in every data grid.

Quite often I'm reminded of readability tests using different fonts, where the one people liked best often wasn't the one with the best reading comprehension. If you're picking a font for your OS, there was little choice and the customer probably bought it already. On the web, they can go to <rival product #341> because that uses Helvetica Neue and not Akzidenz Grotesk.

You just dropped that comment about UX in at the end, but I think I know what you're hinting at.

What I see from UX/UI people is that consistency means an app has the same look and feel across OS platforms and the web, and it matches the corporate house style/identity.

The idea that apps should be consistent with the platform they are running on is completely dead. Even the OS platforms themselves don't have a consistent look and feel in any given version. Not to mention that that metaphorical fish has been flipped in the pan so many times that it has just disintegrated.

No one cares about consistency with OS platforms except us nerds on forums like this.

It's not that simple. You can go three routes:

1. Make the apps look pixel perfectly the same on all platforms - that's what the Java Swing did. Result - all the apps feel "alien" and not native for the users.

2. Make all the apps look and behave native and use UX patterns consistent to the given platform. Result - you will have to program them differently.

3. Somewhere in between - all you get is mediocre GUI with not very pleasant development model.

So the problem is not with the GUI toolkits but with inconsistent UX paradigms between the platforms / different input models, interaction models, etc.

I have no problem with things feeling alien, so that would be my preference.

For example I love the Telegram desktop app.

Telegram looks native on Windows 10 though. It was designed to look like a flat modern app and it excels at that, hamburger menu and all.

Hmm, the header bar doesnt look native to me (it looks amazing)

Alien would be okay, were it not ugly.

Swing is unusable and ugly.

Just look at and try to use a Swing file picker.

...

Anyway, I'd gladly program them differently for closer to native experience, if it were easy to program. Currently it's either Qt (C++) or GTK (C), or completely useless/out-of-date bindings.

And thus any glorified WebView reigns supreme.

Yeah, I agree - C/C++ are the reasons why Qt is not popular.

Python bindings for both Qt and GTK+ are really, really good. For other languages it sure is hit-or-miss though.

I started to type a rather pessimistic reply about how horrible it is to set up py3 + qt, but actually pip3 install pyqt5 works well now!

No, XAML, QML, JavaFX, Android, Cocoa are much better, with guaranteed hardware acceleration, and offer RAD GUI designers that are much more powerful than hand-editing HTML/CSS.

As funny anecdote, CSS Grid was originally proposed by XAML team.

Google apparently is pushing for the low level rendering control that native UI APIs enjoy on their Houdini project. Right now, it is yet again a Chrome only feature.

The big problem is that out of the 5 technologies you mentioned,only two are cross-platform, and only one builds an exe (yet).

Oh, and that one is practically designed around a hybrid C++, so if you don't like C++ (last time I tried C++ with mingw on Windows I had a horrible time installing libraries), you're out of choices.

>last time I tried C++ with mingw on Windows I had a horrible time installing libraries

msys2 (http://www.msys2.org/) solves package management quite nicely, at least for the more popular libraries and tools.

XAML, QML, JavaFX, Android (since version 5), Cocoa all build exes, so I don't know which single one you mean.

QML and JavaFX are cross-platform, XAML is cross platform via Avalonia or Xamarin.Forms.

Anyone using C++ on Windows for GUI development should use Visual C++, C++ Builder or the gcc toolchain integrated in the Qt installer.

JavaFX doesn't run on iOS. While your Electron app will be tweaked to make a Cordova app that runs on iOS.

Avalonia is at beta level at best, would you bet your startup on it? Xamarin.Forms ok, but XAML is not 100% the same everywhere, anyway. WPF is not Xamarin.Forms.

JavaFX surely runs on iOS, just not for the "I want everything for free" crowd.

http://gluonhq.com/products/mobile/

> XAML is not 100% the same everywhere, anyway.

Hence XAML Standard,

https://github.com/Microsoft/xaml-standard

"While your Electron app will be tweaked to make a Cordova app that runs on iOS."

And be incredibly shitty.

If you care about your users and their experience, you won't write apps in JS to begin with.

My point of view is that if it is to be done with the Web stack, then by all means it should be delivered to whatever browser the user likes to use on their platform.

Anything else should take advantage of the native UI/UX tooling.

If they were "much better", devs wouldn't be flocking to Electron. If there's something amiss, claiming there isn't with hand-waves brushes whatever issues there are under the carpet.

I bet the majority of those devs are web devs without any experience in native frameworks.

You also have to consider where the users are coming from. If you only have experience in web dev, obviously you are going to choose the framework that lets you do what you always did and get a desktop app in the end.

If you have been building GUIs in Visual Studio or VBA, you're probably not going to suddenly switch to Electron.

And if you have mostly been writing Python scripts for the terminal, you might use something like Gooey [1] to build a basic GUI with almost no additional effort.

[1] https://github.com/chriskiehl/Gooey

Devs aren't flocking to Electron. JS developers are.

Having done a lot of React development (in TypeScript), and recently dealing more with Android, I disagree.

Having to manually mutate the UI instead of describing it with a `render` function feels like a huge step back. Even data binding is often too limited.

Trying to get a screen in Android to have the correct layout and style is also way clunkier - even with ConstraintLayout.

Really, I agree that there are probably better markup options, but still, there's a reason people choose Electron over the alternatives. For me, personally, that reason is the ease of prototyping - the time it takes for me to have something in front of me that looks good and works easily is so much less using something like Electron.

They don't know better.

Web stack doesn't have any mature option, besides maybe avril, that matches what something like Blend or QML designer offers.

Ok, but from an engineering standpoint I see this as a bit shortsighted.

I mean, shouldn't you care more about shipping a good product (i.e. developing something that doesn't thrash your users' resources) than ease of development?

I get that if it's too hard to develop there's no product to speak of, but still, aren't we going too far off the equilibrium point?

Web technologies have some unique non-technical qualities which trump the technical arguments:

* Standards based with no single entity or company "owning" it.

* Multiple mature competing implementations.

* Massive support across the industry and a huge ecosystem.

You mean like those "Works in IE/Chrome" standards?

I am yet to see the huge ecosystem for Web components that matches component libraries like those from DevExpress or ComponentOne.

You have to actively ignore the web's landscape in the past 5-6 years to state something like this.

Lately, major vendors (with Edge, that includes Microsoft) are agreeing on standards, developing them FAST, and the web moves forward faster than it has ever moved. Long gone are the days where your standards can get stopped for multiple years. And vendor prefixes are less prevalent now as features get implemented properly sooner.

Really?

https://ishoudinireadyyet.com/

https://www.webcomponents.org/

https://hangouts.google.com/

Also, to use those standards, one needs to have access to latest browser versions, which never happens beyond controlled environments.

So typical web development always needs Modernizr, Babel, Polyfills (when possible) around.

The vast majority of current web development project don't need to go anywhere near the bleeding edge "still in development" browser APIs.

Your argument makes no sense in the year 2018.

Depends, if they are trying to compete with native apps or not.

Of course if they just stick with the ideal model of hypertext documents, with a little bit of JS, it doesn't make sense.

As for web apps, I am ok with them, provided they run on the browser I have already installed, instead of faking native apps.

Hey, some of us are still out here having to support IE 7... Glaciers move faster these days than some corporate clients.

And yet, I still frequently run into web applications that only run in Chrome. Mostly COTS enterprise products.

You have extra word in your second point. There is norhing mature. If anything webtech rushes implementation of some feature just so the checkbox “we can do it too” is ticked and that’s it.

Do you know of a Qt app that looks and feels fully native on macOS and Windows and maybe iOS and Android?

I'm genuinely curious. Years ago, I used several Qt apps, and they never felt native. They felt like Java Swing or Delphi apps. Clunky and not pretty. Slack, to me, doesn't _look_ quite native, but it still doesn't feel like an outsider on the platform.

I imagine that using native Apple kits are easy from C++ thanks to ObjC interop, no idea about Android.

Or maybe the other way around: what if a browser was modular down to the feature level? Don't use CSS/JS/HTML feature X/Y/Z? It's removed from the engine at compile time. That way you're only shipping what you're using, not a mini-OS.

Or maybe the JVM approach, where there's one electron process on the system, and all the electron apps on the system are run in the same process. That way at least the rendering/JS engine can be shared. It'd be like Firefox before electrolysis. Though, having your chat client crash and also take down your music player and code editor seems like a terrible user experience.

One big problem with Electron apps today IMO is that different apps cannot share memory, even though 90% of them is the same (Chrome/V8 etc).

That would be solved if you had one Electron binary that started each app, much like a JVM. They would still be different processes so one app couldn't bring down another, but at least they would share memory pages and copy on write which would make the multi-electron-app world better. (IMO)

It would also have the benefit that you could update once and not run an old chat app with old Chrome security issues, until each developer decides to update Electron. But I guess the argument against that is that it's no longer "truly cross platform" since an Electron app may have to support multiple Electron versions. This is how things always have been though, developers just seem a lot more lazy about it nowadays.

I'm not sure you would save that much memory. It would be a similar situation to having Chrome open with a bunch of tabs (those are separate processes as well) - it's the tabs themselves that consume most of the memory, compared to "bare" Chrome.

On my computer, "bare" Chrome with 0 tabs open still uses ~100MB of memory. If Electron would just use 100MB for the base compared to 100 * number of open Electron apps, that's still a pretty big win in my book.

I am sorry, but I honestly do not think that PYTHON of all the things would be the solution to a "UI-problem".

To have a good UI system, you need extensibility, you need testing, you need strong types (this one is debatable, but I truly believe this to be true after working with Typescript-based HTML UI-s for the past 6+ months now), and you need performance.

I can understand that a lot of programmers got into the mindset of "no, I wont deal with HTML", and I frequently see devs mentioning that they prefer that apps look "native", which is something that has not been a standard in the mainstream dev world for quite a few years now, but the reality is that that "native" dream is gone. People all around the world interact with mobile apps MORE than their dessktop/mobile system'S native ui, so there is no baseline to go back to, there is no good old days to retrieve.

We can only move forward with what we have learned, imho. And that might be or might not be HTML, but if something comes along, it better learn all the lessons that we collectively are learning with working through HTML-CSS-JS SPA's.

Are the options the best they could be? Heck no, not even close. Html is semantic enough to be tedious but not enough yo be useful. Css makes the easy things hard and people have entire philosophies around minimizing the "cascading" part. Js is at best stuck with warts to try and maintain backwards compatibility.

Meanwhile the tooling to deal with missing pieces or complications that are not missing is complex enough that both new and experienced devs complain.

The less said about the security complexity the better.

And I'm saying all of that as someone that uses these daily and enjoys it.

BUT...is it the best that is practical for the time? Probably. There have been efforts to replace these options...theyve failed. Perhaps wasm will change things, but perhaps not.

Until then though, I think it is interesting to ask "Why?" Why, if these other options are superior, do they not catch on? Linux, git, nginx, these are just a few examples of dramatic tech switches that had to overcome an existing base.

It isnt just backwards compatibility either - Babel exists for es6+, but I've not seen a non js-like language that can compile to js achieve much success. I suspect there are one or two areas that the current offerings handle well that aren't being credited or understood.

Computer UI is a young field, computer interactions with business and marketing over time are all poorly understood. We spend much of our time reinventing our spinning wheels and relearning lessons. Html in js is bad. No, it is good. Inline css is bad. No, it is good.

This isn't all wasted time, there is a lot of learning time. So I doubt we even understand yet what would make a better toolset.

I very much hope Red finally takes off. Currently the GUI frontend works only on Windows and macOS, not on Linux yet. But once it does, we'll finally have a truly multiplatform tool for creating simple apps (such as the ones Electron is used for). As for more complex apps, this might well be possible as well, but I haven't seen anything really complex created in Red yet.

It sounds like you're just describing React Native (which, for example, has a UWP target, although it's still janky). React Native doesn't have a "web stack".

But is HTML/CSS/JS really the best we can do for desktop and mobile applications? [...] I frequently imagine something that takes the best ideas from react/redux and from other ui and layout frameworks and lets you build something that has consistent, cross platform (desktop and mobile, maybe even web with some kind of compilation pathway to js or webasm), responsive ui, without the huge web stack.

QML?

Or if you want native applications, what is wrong with Cocoa, Qt, and XAML? A cross-platform toolkit will either be the lowest-common denominator between the platforms (this has been tried before, see e.g. AWT, SWT, wxWidgets) or something that is alien to each platform (Electron). Small independent development companies have done applications across multiple platforms by using their native toolkits for decades. And now suddenly, it is too expensive for GitHub, Slack, and others to develop applications with platform UI toolkits? They are just transferring the cost to the users. We get inconsistent shortcuts, widgets, etc. between programs. No automator support, etc.

There is only a benefit to people who use multiple platforms and want to applications to look the same on every platform. But the vast majority of users just uses one platform, or two if we include tablets/phones (which have different input methods anyway).

>Small independent development companies have done applications across multiple platforms by using their native toolkits for decades

Really? How many programs supported Linux before electron?

Usually these companies supported macOS and Windows. I am sure they would have also supported Linux if it had a desktop penetration of more than 1% and if the Linux community was less hostile to closed-source applications.

Don’t take this the wrong way (I was a full time Linux/BSD desktop user from 1994 to 2007 and still have one Linux desktop machine at home), but do we really want to significantly degrade the experience of 99% of the users for 1% of the market?

You will most likely come up with a sub-par rendering engine that is better implemented by Mozilla and Google. My hope is in Servo.

It is amazing that React and friends work as well as they do, and for certain applications they make a lot of sense. But there is a fundamental disconnect using web technologies for native apps.

The solution I am pursuing right now is Microsoft's Xamarin. The C#\XAML stack supports iOS, Android, MacOS and Android. The only thing it is missing is web. But with a couple serious projects working on compiling C# to WebAssembly perhaps that will happen.

I thought it was just a poor winforms clone on macOS.

Correct me if I'm wrong, but I think Xamarin just wraps Cocoa.

Like the rest of Xamarin's platforms, you can use modern XAML with MVVM patterns or you can use XCode's Interface Builder to create your views.

Xamarin.Forms has no relationship to WinForms.

Microsoft is serious on the WebAssembly part.

https://blogs.msdn.microsoft.com/webdev/2018/02/06/blazor-ex...

Sounds like what Red language http://www.red-lang.org/ is trying to achieve. It is still in Alpha, but already has cross platform GUI for Windows and OS X (with Androind arriving in next release). And without the web stack bloat, it's just single ~1 MB executable.

I feel the same way. I even tried starting a library like that (in Kotlin JVM and Native), but never got past a very early stage (https://github.com/peterholak/mogul). Hopefully one day I'll have enough time to work on it.

You just described Adobe AIR eg. "something that has consistent, cross platform (desktop and mobile [...]), responsive ui, without the huge web stack"

I've been working in UI for almost 20 years. I've done flash, native desktop, games, web, mobile, etc, and I think HTML+CSS+JS is still the best abstraction for UI IMO.

It's certainly not without it's problems though. JS sucks and native performance is way better, but no one can deny it's so much more flexible and powerful than any other thing out there.

Here is a great article on this topic: https://medium.com/missive-app/our-dirty-little-secret-cross...

> "I frequently imagine something that takes the best ideas from react/redux and from other ui and layout frameworks and lets you build something that has consistent, cross platform (desktop and mobile, maybe even web with some kind of compilation pathway to js or webasm), responsive ui, without the huge web stack."

There are a number of existing UI frameworks that fit this description. As a starting point, I'd suggest checking out QML:

https://en.wikipedia.org/wiki/QML

Flutter has the potential once it ported to desktop and even web(with WASM).

I think it'll only be ported to desktop once Fuchsia comes closer to release (which could be several years). They really seem focused on mobile only at the moment. Agree it could be a great solution.

Looks like it has started (MacOS for now) https://github.com/google/flutter-desktop-embedding

I really don't mind the HTML / CSS part with new developments such as CSS grid. If you're running it in a controlled environment (embedded browser), you could cut out a bunch of legacy crap, leaving a much leaner engine. Similar cleanup could be done on the DOM API, I guess.

There is something to be said about html being too basic for developping apps efficiently. There is no menu control, contextual menu control, if you want to handle dragging and dropping UI items or creating an overlay modal window you need to do all sorts of hacks. On a desktop UI framework these are often a single line of code and it’s hard to get it wrong. I don’t think html/css is really comparable to the major native UI frameworks in term of productivity and correctness of apps produced.

I see so many websites trying to implement their own UI behaviors and getting it wrong, not scrolling smoothly, showing a modal window partially off screen in certain scenarios, preventing you from zooming out on a smartphone while overflowing the text outside of the screen, menus that are either not touch or mouse friendly, etc.

Giving UI developpers only html and css is like telling a graphic designer: all you need is microsoft paint, you see you can change the color of each pixel to whatever you want, total freedom! Yeah... No.

Being relatively low level is a feature. HTML / CSS / JS are languages, not frameworks. One liner modals are not a feature a language should have.

If you want, you can make a framework on top of it that will behave like a desktop UI framework with standardized elements and behaviours. There are plenty of such frameworks actually. But not having to use such a framework is nice.

Besides, the current browser environment has been historically heavily optimized for websites, not desktop apps. If it became a popular choice for desktop app UI we'd have developed more appropriate features for that use case.

Why do you call html and css a language? To me it’s a UI framework very much like winform, wpf & al.

Because it's a markup language, and a style definition language respectively, so HTML / CSS lack the high level features and components found in desktop UI frameworks such as Cocoa (standard buttons, lists, file explorers, image grids and such). Building a HTML / CSS UI is done from the ground up with basically nothing more than completely unstyled boxes, in contrast to composing higher level components.

On the web the role of desktop UI frameworks is distributed between third party frameworks such as Bootstrap which is great because those are optional.

I haven't worked with the windows frameworks you mention to compare directly to them.

HTML and CSS are languages. Languages do not have one line components. Frameworks like Ant-Design and material-ui (based on react and/or Vue) have components that are nothing more than single line.

They have components, they have tables, datepickers, buttons, etc.

Have you seen a built in HTML date picker? It's horrible and is exactly the kind of built-in uncustomizeable frameworky misfeature that I don't want in HTML / CSS.

Tables are just unstyled boxes with an alignment rule. Not very high level.

Buttons are provided by the host OS, HTML and CSS have nothing to do with their default style or behaviour, and if you start styling them you basically revert to working from unstyled boxes.

Absolutely, I agree that it sucks. And that's why UI developers are building all sorts of DIY components, too many of which fail. But that's exactly my point.

> I like the electron/react/react native ecosystem - I really do, and this is coming from someone who dislikes javascript a priori. But is HTML/CSS/JS really the best we can do for desktop and mobile applications? I know responsive-cross platform saves money for a lot of startups and orgs, and I'm not saying the web stack doesn't have it's place.

React Native doesn't use HTML/CSS at all for rendering.

I'm starting a project with a strong need of build the UI in multiple targets (iOS, Android mainly).

I try first with html and the native webview. With iOS is totally fine, but Android is SUPER slow. I never imagine that android was this bad, but at least, it force me to do native :)

----

I think that is possible to do what you describe, and I'm working something like. The key is decouple some task (kinda separate "back-end" UI from "front-end" UI):

We can do "partial" cross-platform UI, if we think that some stuff can actually cross cleanly:

- Layout (the big one, IMHO) with something like https://yogalayout.com

- The ELM architecture (https://www.elm-tutorial.org/en/02-elm-arch/01-introduction....) because a big chunk of the logic is totally cross-platform and "only" need to adapt the render of controls.

- Dispatching, events and similar stuff, that is not visual.

Then finally, the rest can be fully native:

- Controls

- Drawing

- Animations

- Call to native libs

----

The big question is what to use for coding this. I'm using .net but wish to have something more low-level. I know swift and it could work for other targets (Java, .NET, native) with http://elementscompiler.com

Wish to have a coding partner to do this :)

TCL/TK runs on literally everything except the iPhone.

Yes. I'd like to see a stripped down embeddable browser engine - https://news.ycombinator.com/item?id=9914925

Also there are existing projects like https://github.com/ptmt/react-native-macos

Like Sciter? https://sciter.com/

I think WPF/XAML could have worked also but there were not much work to port it to anything but Windows.

That's almost exactly what I was thinking of. There does look to be a big caveat with it though - instead of JS, it has an ECMAScript variant called TIScript. I'm sure this was a good choice when it was made, but javascript libraries and tooling are a lot to miss out on now.

Look up QML (Qt Quick) on Qt, its the easiest UI building experience I've ever had

Funny that QML looks alot like the JavaFX script that was abandoned

https://www.youtube.com/watch?v=yOiuJ_Gll_E&feature=youtu.be...

I wouldn't get my hopes up. Javascript is the only runtime allowed on ios. Desktop is no longer worth innovating for. Meanwhile web ui frameworks are going gangbusters with innovation. That leaves a fairly slim line for any real ui innovation outside of the HTML css js triumvirate.

Reply on news.ycombinator.com