Hacker News Reader

Comment by emodendroket | Hacker News Reader

As much as anything else the growth of hybrid apps is a symptom of a couple of things:

1) people now expect apps to run on a million different devices and nobody has the time or resources to develop four or five native apps with feature parity between them

2) progress on UI frameworks is pretty much stalled. Just looking at .NET, because I'm familiar with it and traditionally desktop software has been a big area of concern for it, Windows Forms will work for forever but hasn't been touched in a long time, WPF has some sharp edges that make it feel unfinished but isn't being touched, and WinRT was basically stillborn because of their attempts to tie it in with the whole "new" Windows 8 ecosystem. Meanwhile, browsers are getting new capabilities constantly. It's hard to blame anyone who looks at that mess and says to hell with it and goes with a Web browser-based solution.

View on HN

Indeed, my prediction is that native apps will make a comeback when the UI toolkits catch up. Flutter is in this vein. And some of the Rust UI ecosystem looks promising (although very early stage).

Agreed, I think the web was simply first in being a highly versatile, capable, and relatively cheap to develop with cross platform UI toolkit.

I’m much more optimistic about the future of native apps, the best ideas from the web are already making their way into Rust and the recently announced .NET MAUI, and with WebAssembly I think we’ll start to see native performance on the web instead of the other way around.

> with WebAssembly I think we’ll start to see native performance on the web instead of the other way around.

I wouldn't be so sure about that. WebAssembly doesn't do anything to help the rendering bottleneck. To do that you really have to replace (or innovate in some way) the DOM.

I think the approach many is taking is just put a canvas and draw on top. Internally, you may end up creating another DOM like structure to store all your objects. The worst thing about this approach is that you lose all browser's native support like accessibility. I think Flutter is using a combination of DOM, CSS and canvas.

Sure, but at that point it's not really "web" anymore. You're just writing to a WebGl or WGPU canvas, which you could do just as well from a "native" app.

So we've basically reinvented Java applets - 25 years later.

> And some of the Rust UI ecosystem looks promising (although very early stage).

Can you recommend any projects to check out?

Iced https://github.com/hecrj/iced and Druid https://github.com/linebender/druid

Iced is taking the "get something working now" approach, whereas Druid is taking the longer term "build it right" approach. I wouldn't recommend either of them for serious projects yet though.

I would also recommend Raph Levien's blog https://raphlinus.github.io/.

https://www.areweguiyet.com/

Can they catch up? I feel the reason why web apps took off is because so much money has been spent on the underlying technologies (HTML, CSS, etc.) that makes them extremely powerful.

I’ve used a lot of UI frameworks and getting to do anything complex is always much harder than doing the equivalent in HTML/CSS/etc.

I think so. Web has the advantage of already catering to literally every layout & style use case (grid, multiple columns, floats, inline elements, etc. etc. etc.). But Flutter has the advantage of being designed from scratch so it can avoid all the idiotic mistakes the CSS made (e.g. box-sizing, the insane difficulty of centering things, etc.).

I don't think it will take too long for the niceness of a sane design to outweigh the lack of features.

The only thing I'm not convinced about is that Flutter-web will ever be viable for most web pages (i.e. non-app ones). It kind of works but it's big and slow. Probably eventually people will do a native website, and then use Flutter for mobile and desktop.

Something that one can easily do even with Motif and Windows Forms, just learn the layout APIs to start with.

Check out elm-ui.

https://korban.net/posts/elm/2019-11-17-elm-ui-introduction/

> Windows Forms will work for forever but hasn't been touched in a long time

WinForms very recently got HiDPI support, better accessibility features, and was ported to .NET Core where they also fixed bugs in some controls.

WPF in the meantime has been arbitrarily declared stable and Microsoft refuses to fix anything. Everybody is supposed to switch to UWP which they already deprecated or WinUI which hasn't been released yet.

Windows Forms remains supported, yeah, but there are no marquee feature to make it easier to develop for really. That seems like it's more focused on getting people to bring their existing WinForms work to .NET Core.

The "marquee feature" of Windows Forms to my mind is the staggeringly large number of commercial component packs available. To this day, getting something working quickly that works as it should for the target operating system (provided that is Windows) is vastly easier than any other alternative.

Of all the Windows GUI frameworks WinForm has to be the easiest to develop for, for the majority of developers.

Sure writing large apps is not going to be straight forward, but WinForms is super simple to get started with.

I agree and it's still pretty much the one I'll use but it's in a weird limbo where it doesn't seem like they really want you to use it

They complete revamped the WinForms designer for .NET 5 in Visual Studio 2019. It's buggy as hell (as is the rest von VS2019) but they tried to make it better and are definitely not doing nothing.

UWP and WinUI are marketing terms for the same technology stack that keeps being developed.

Agreed. As the developer of an Electron app, I would jump ship in a heartbeat if a viable alternative emerges. Until then, I'd rather use my time to add new features rather than wrangle multiple implementations of the same app. The core app logic is the same on every operating system, so why on earth should I have to rewrite it three or more times?

I know of people doing C++ backend as an Electron extension. The C++ can be compiled on almost any OS does the non GUI stuff.

then why still use Electron? why not just c++-backend with an embedded http server for frontend that uses the browser

For many users that can be an alien experience. For most non-technical people, browser is still primarily for accessing contents on the web and switching them to a user experience where you have to start a backend server locally and then access it via the web browser can just feel hacky and even a bit off-putting.

You can do that perfectly transparent, the executable just starts the user standard browser.

It was a standard practice for some applications in the .com days.

Electron is just another example of the disease making Web == ChromeOS.

I would assume for the same reason that they don't just use a normal web app. They want the packaging of a native app.

Package as native app, it starts the user browser pointing it to localhost into its builtin server, plenty of examples during the 90's, e.g. CUPS printer management tools.

I'm not sure the app ESR famously blew up for having a horrible UX is the example I'd point to to say it's not confusing.

Theres a lot of people proficient in Electron. It also handles IO I assume

AKA Chrome APIs.

Thanks, I haven't worked with it but assumed.

Security? Seems like any webpage could make calls to your program, no?

That's just standard CSRF stuff isn't it

That is the proper way of doing, but then some lazy devs rather code with Chrome APIs instead of Webs standards.

If you take a look at the GTK+ ecosystem...it's kinda broken, too.

Simple use case: Make a sidebar fade in and fade out, while changing the dimensions of the right box. Pretty close to impossible to implement in a clean manner, even within glade.

And then, try to support a mobile device in a responsive way with libhandy.

Now you throw the towel and just get on with 20 lines of CSS and literally two HTML elements.

CSS should not be underrated when it comes to layouting. It is super flexible, and UI frameworks always will lack behind due to their architectural patterns.

I never coded GTK apps, but isn't the theming done with CSS since GTK 3?

Yes, with global css, which is literally one file for every single application, extension, gnome shell, terminal and ui windows on your whole system.

That is why so many apps don't work bug free with other themes. There's no way to predict how your app will behave on another system with another theme.

So personally I think the mess of overused dummy css classes in the GTK ecosystem is really a bad design. They could've gone with custom, namespaced, ui elements instead of that box.something.something shit.

They reinvented divitis. Quite literally.

As a Linux user, I love this though. Brings me a lot more.

Reply on news.ycombinator.com