Hacker News Reader

Hacker News

Comment by oneplane | Hacker News Reader

Parent Full thread

oneplane

So it's a local email client. Basically, what we already have but written in a less efficient language...

View on HN

A less efficient language with a much better UI toolkit, seems a reasonable trade-off to make for a lot of people.

Better how?

> with a much better UI toolkit

I just made this as a reply in another thread where the user essentially believed you couldn't have a nice GUI (his example was VS Code) with a native toolkit that's also easy to develop in:

https://i.imgur.com/RPr6VMS.png

https://gitlab.com/mixedCase/poc-qml-vscode

We've had the tools for a long time in desktop, let's not pretend we don't.

Microsoft has tremendous resources, it's definitely costlier to build a great desktop UI than a great Web UI (but the great Eat desktop UIs are always better).

Microsoft has tremendous resources, it's definitely costlier to build a great desktop UI than a great Web UI

What? Let's not rewrite history. I has been easy and cheap to create desktop UIs for decades, literally. I was using Borland Delphi 1.0 as a 13 year old and could have a basic Windows UI app up and running in ten minutes.

There have been many great cross-platform and platform-specific toolkits that are easy to use. E.g. you can teach someone with some Python knowledge how to make basic Qt desktop applications in one hour or so. It's literally as simple as dragging some widgets to a window and writing some lines of wrapper code.

I recommend anyone who thinks that developing applications using web UIs is easier/cheaper to look at some Delphi 1.0 videos. E.g.:

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

This was how we developed desktop applications 22 years ago on machines with 4 or 8 MB RAM. And it is still a whole lot easier and more efficient than a web app.

I agree, but the previous comment did say "a great desktop UI". Simple ones are definitely easier in something like QT of course, great ones are not.

Only if your measure for great is "looks and behaves in a bug-compatible manner exactly like the native toolkit". Otherwise, no, I'd very much disagree.

danieldk's response sums it up quite nicely. I will add that around the same age I found Microsoft's own Visual Basic 6 and was doing stuff with it.

Additionally, Microsoft has their own framework similar to what QML offers: WPF. The problem with it is that it doesn't have cross platform support, something they wanted to have for VSCode.

It's all exhorbitantly easy to use. Cost is not the issue, specially since they already have a lot of really talented people working on VS Code.

Calling Qt native is a stretch. It doesn't really look native. Everything is a little off in all platforms.

Native as in "not an embedded website".

Also the point of QtQuick as an alternative to Electron is not to look native beyond the menus and dialogs.

And you probably associate Qt with Qt widgets, not QtQuick. Qt widgets actually tries to resemble and behave like native widgets, and it will let you get to that point if you actually care about that.

Most people making cross plat applications don't, which is why popular Qt widgets applications like VirtualBox and VLC don't look native, and QtQuick applications like Telegram for Desktop just ignore the desktop's HIGs completely.

What would be your personal recommendation for learning Qt?

Don't bother with Qt widgets, learn QtQuick and QML.

Install QtCreator, grab the docs and play around in a new project. You can drag and drop components around in design mode and you'll be able to figure out how QML works from there. It's really intuitive.

Nice.. Though one small niggle: I wanted to bookmark this for later reference, but the git page has no screenshots, and the screenshot has no title or link to the gitpage..

In meantime, i will just bookmark your comment :)

I have been doing native GUI development starting with Turbo Vision in Turbo Pascal 6 and started with Web development in about 1997.

I have used quite a few UI toolkits since those days and am yet to agree with the opinion that the Frankenstein mixture of HTML, CSS and JavaScript is a better UI toolkit.

A lot of people think the earth is flat and landing on the moon is fake. Call me a misanthropist, but I generally have little faith in 'a lot of people' ;-)

The thing about efficient language wasn't 100% targeted at web technologies alone, but at the general waste of computing resources for something as trivial as a mail client. Just because we have SSDs, gigabytes of RAM and CPUs that do a whole lot of cycles doesn't mean wasting a good portion of it is a good idea.

I wasn't saying it was good because it was popular, not making an argument from popularity, since I also think most people are stupid.

I was saying that's the right trade-off to choose in a lot of common use cases. Because most UI toolkits are pretty limiting, and the web toolkit can be amazingly powerful and productive. Of course, if you follow the latest fads in the awful js community they are a nightmare, but lets not pretend that's the only way to use the platform when it makes sense to pay the efficiency cost.

Yea, but this enables things like e2e encryption without losing a search index.

if it's a chrome extension there's nothing stopping a court forcing Google to add a modification for a certain user

no different to having your javascript decryption routines done by a website

Sure, but presumably if you're worried about it you can sideload your own version.

Nonetheless you're absolutely correct; i would prefer firefox to chrome.

I have found Chromium to be a nice alternative to keep local browser apps working as it freezes the browser version instead of automatic upgrades, which have regularly broken web based line of business applications I have been around the past few years.

So it's a local email client. Basically, what we already have but written in a less efficient language...

Right. This is as if Outlook was written in VBA and ran inside Word.

Reply on news.ycombinator.com