Hacker News Reader

Comment by Multicomp | Hacker News Reader

I have no experience with either of these. I read this as "that framework which makes native applications for most major platforms now targets the web browser".

If the above is even 2/3rds what happens, what stops QT from taking over all multi-platform targeted applications "one <toolkit> to rule them all" style?

View on HN

People who think that just because it's in C++ it's harder than the average web app to write, and lack of ability to deploy e.g. on macos without owning a mac or windows without having a windows partition (though there are solutions, but nothing as easy as what electron proposes).

I also noticed that a lot of people tend to choose electron arguing that unlike Qt (which is under LGPL), Electron is under MIT, but it seems that they are not aware that it's only the electron scaffolding part which is MIT, not the whole electron framework which includes chromium, ffmpeg which are also LGPL.

Though overall I'd wager that there's an order magnitude more cross-platform single-toolkit apps built with Qt than with other frameworks.

Do most people choose Electron for the licensing or because of the cross platform benefits of a JavaScript codebase?

Probably neither -- I'd wager that Electron's popularity among web-centric companies is due to the prevalence of JavaScript programmers in these shops. With Electron there is no need to hire anyone new (or eat the cost of programmers retooling) to roll out a desktop app.

It's the design culture JS is embedded in, more creative people, or full stack devs who can make it work but also pretty.

I have no idea about other platforms, but on Linux it's extremely easy to set up a cross-compilling environment for building macOS, Windows and Android applications. I'm not exactly sure if I want to have the applications I use be written by people who can't even bother to do one-time setup of their compiler toolchains if there's no ready-made script on GitHub that does it automatically, like there are for Electron.

cross-compiling isn't the major issue. It's the toolkit. Yeah a cross-compiling C/C++ environment is fairly straightforward to do especially if you just want to do a commandline utility that can be done with the C or C++ standard library. But having any sort of GUI toolkit (such as Qt).

how would it work on macos ? If you have graphical apps you have to link against the various Cocoa frameworks, and those are (legally) only available on mac machines

I have a Qt app and don't have a mac. Can you point me to where I can create the self-contained dmg or app file w/ all the icons and such on Linux that works on mac? I am familiar w/ Qt's mac tooling that is only shipped with the mac install, but if "it's extremely easy" on Linux, I'd really like to know.

https://github.com/tpoechtrager/osxcross for the compiler and libraries. You might be even able to simply install Qt there using MacPorts, so no manual compiling or unpacking the SDKs into osxcross's rootfs should be needed. A properly configured CMake project will make an .app file for you automatically (although if you'll want to bundle dependencies as dynamic libraries instead of using frameworks, you might have to fix linking paths with a script like https://gist.github.com/artm/3668431 - that was the hardest thing to figure out for me)

macOS icon file can be created with png2icns, Windows one with icotool.

Overall, the whole process is easily scriptable. I'm making small games in C with Allegro 5 and I'm using only GNU/Linux. It wasn't hard to make scripts to automate the whole process of making builds for Windows, Linux and macOS. Android was a bit more tough, but manageable - I wanted to have it all done with CMake instead of Android Studio though, so that probably made it harder. The hardest was "HTML5" build with Emscripten, but it works now. It's a pity that iOS is off limits for that though...

> https://github.com/tpoechtrager/osxcross for the compiler and libraries.

yes, I know osxcrooss but it is not legal to use if you aren't developing on apple hardware which makes it a bit cumbersome. Grep for "Authorized Test Units" in the xcode license linked in the repo.

It literally says (section 2.2, Permitted Uses and Restrictions):

"Install a reasonable number of copies of the Apple Software on Apple-branded computers"

It's likely enough that such a statement will be considered void when tested in EU court (as you can safely reverse engineer software for interoperability purposes) that I don't care.

> (as you can safely reverse engineer software for interoperability purposes)

but here you're not reverse engineering, you're copying proprietary software for which you don't have a license. Reverse engineering is allowed if you have the right to use the original software ; you certainly don't have the right to reverse-engineer e.g. a software that you would find on a CD somewhere in a park without a license attached.

Well, when it comes to me, I have a Mac for iOS builds anyway. It's far easier to build on Linux though, so I do it that way.

I probably wouldn't care anyway, sorry Apple.

I'm afraid this doesn't replicate macdeployqt. There are many quirks that are not being taken into account here. My Qt app does not use cmake, it uses qmake. I have certain static compilation needs. Also, I said I didn't have a mac, so how do I get the OSX SDK? Your original statement about "extremely easy" is clearly false (you even mentioned a "hardest thing" which is custom per-OS scripting). I hope it's clear that this is why Electron is popular. I don't see how this can be seen as extremely easy from anyone's perspective and it's the mindset that drives people towards Electron.

That's exactly what I mentioned in my first comment. There are some hops to take, but nothing that could actually stop any competent developer.

Sure, you can use Electron right away, you don't even need to understand what you're doing. That has probably a great value for people who want to learn or for scrappy hobby projects, but shouldn't matter for anything serious.

C++ is arguably one of the most complex popular programming languages out there. With Qt you get a lot of conveniences and built-in magic, but I'd say at that point it's not really regular C++. A good comparison could be writing plain Ruby vs writing a Rails app.

I'll admit my experiences with Qt have been fairly limited relative to my web work, but picking up QtWidget seemed like it had a much higher barrier of entry than a web tech stack. Although I'll also recognize that QtQuick and QML greatly seemed to streamline the whole thing, especially for getting started. Based on my experiences performance with QtQuick still left a bit to be desired, but it was still an improvement over most Electron equivalents.

It's also worth noting that these comments mostly apply for people going for a mostly-native look and feel. If you want to completely customize the look and feel of widgets, as many modern apps have recently begun to do, I think it might be easier to get started doing that with the web stack. Then again, I recognize that this just might be my inexperience talking.

It also depends on the kind of app you're trying to build. I've written lots of personal apps using server-side rendering and a tiny bit of JS and I love how easily I can deploy and access it from all devices. That's a kind of versatility you just don't get with native.

IMO, most web developers could probably learn a lot from giving Qt and other native toolkits a try.

> With Qt you get a lot of conveniences and built-in magic, but I'd say at that point it's not really regular C++.

This is a common misconception of beginner Qt users or people who just looked at Qt superficially and decided not to use it, because it's not "regular C++".

You use Qt with 100% pure C++. Qt itself is written in 100% pure C++. The part that confuses people is the metaobject compiler (or MOC). This is a simple code generator tool that provides additional features like runtime type information and reflection. It does not modify your source code, only generates some additiona, 100% legal C++. Granted, this requires an extra build step before invoking the C++ compiler. But Qt's build system handles this automatically, and it's not really difficult to integrate into any other build system.

Starting with Qt 5, you don't even need to invoke the MOC compiler, because in many cases, the features provided with generated code were replaced by new C++11 functionality.

If/when C++ gets proper metaclasses and programmable compile-time code generation, there will be no more need for MOC, because all of its functions can then run in a single compilation step.

There's a great blog post debunking the myths about the QT metaobject compiler - https://woboq.com/blog/moc-myths.html

How fundamentally different would that be from what Flash or Java were doing? You lose HTML/CSS as your universal, open GUI on the web with all it's built-in advantages (SEO, hyperlinking, accessibility) in favor of some byte-compiled GUI using canvas to draw itself.

In theory it is more secure than Flash and "more open". Flash was bad because it was a security nightmare even "sandboxed" and the player was closed source. Nothing prevents either ActionScript or Java from compiling to web assembly though. Flash API are close to Web API so Flash could absolutely export to WASM. Now is Adobe interested in this is the question.

Nothing, but now since WebAssembly is open bytecode format everyone is happy.

The browser is destined to become a general purpose VM, only if our benevolent overloads don't want to fully pursuit this road.

Webasm is not limited to a contained program that only draws to the canvas. It is meant to be able to do computations at near native speeds and be called from javascript.

Flash and Java were not the same thing, they weren't meant to augment slow parts of java script.

There is nothing you are seeing here that could not be done with javascript already, it would just run slower.

> There is nothing you are seeing here that could not be done with javascript already, it would just run slower.

Yeah, but there isn't much temptation to make QT-like widgets on Canvas with JS, since JS is fully integrated with the DOM. While the temptation for web assembly is to do exactly that, and thus the parent question.

The parent question was about how webasm is different from Flash and Java. The answer is that it is fully integrated with javascript and only does what javascript already does, but with faster execution, faster parsing, and smaller file sizes.

'Temptation' has nothing to do with the lack of java and flash similarities, and the lack of being contained to a single component within the page that doesn't interact with the rest of it.

> what stops QT from taking over all multi-platform targeted applications

The fact that Electron is much better. I know this in a highly unpopular opinion here. I've programmed in them all (MFC/wxWidgets/QT/WinForms/WPF) and HTML/CSS/JS is just so much easier.

CSS3 hackary better than native frameworks?! Not really.

Maybe when I get to see Blend implemented with WebComponents.

Hackery*, and I'm not sure why the hate towards CSS3. With a few lines of code I can build a pretty good looking responsive UI that doesn't take hours to polish.

Yeah, when running on a specific browser version targeting a single OS.

That's hardly true when it comes to CSS3 stuff that's been around for a decade.

Moreover, it's unfair to insist on portability when comparing native vs. Web without doing the same on the native side.

Only if the only browsers one cares about are latest version of Chrome and Safari.

There plenty of deployment scenarios with other kinds of browsers.

Of course it is fair, using something like Qt, wxWidgets, or even roll our own was never as complicated to get pixel perfect UI across OSes.

Is pixel perfect UI really what you even want these days? With high-DPI screens and screen scaling being a thing, not everyone's pixels are the same. And that's not even talking about accessibility for people with low vision who want text to be big and readable.

I'd give my left toe to learn to do this in a few lines of code in HTML/CSS3.

Desktop centric UI toolkits provide a set of widgets which lets me build up a UI in a predictable way that respects my sanity.

Windows Forms, WPF, Qt, vxWidgets, tkinter, Java AWT, SWT etc they all have warts but ALL of them feel faster than building UI for the web.

The problem with web is that there are no consistent set of widgets.

Let's take a stupid date picker. A year ago for a project I thought I'd use the HTML5 <input type="date"/> way no Javascript needed!

Sadly I couldn't figure out a way to keep the calendar in an always on state so had to resort to jQuery datepicker. So jQuery widgets was an attempt to do what desktop UI does but now that is no longer in vogue.

Today on the web there is no consistency, there is no agreed upon toolkit. How many different approaches to widgets does React have?

Ideally you would be able to import a web component into your project and use it without worrying about any abstractions leaking.

...and what do you think is used to style webcomponents?

Lots of CSS hacks to make them work properly across all browser versions and OSes.

What year do you live in? 2010? The most wanted features from CSS3 have been supported everywhere for years!

Look at the support for (flexbox)[https://caniuse.com/#search=flexbox] for instance.

In the year where not all deployment targets are using the latest Chrome and Safari.

Where there are devices beyond computers and smart phones with browsers on them, the majority of them without any kind of update system in place and based in some kind of browser implementation.

You are not familiar with web are you?

Doing web projects since 1997, coding across multiple platforms since 1986.

So not familiar with modern development? Since you don't need much CSS hacks now.

So not familiar with the fact that not everyone runs the very latest Chrome or Safari on their desktop computers, and there are other kind of devices on the field?

That's too generous. Even the things that work properly on every browser are usually hacks because HTML and CSS were made for documents rather than applications.

«native frameworks» => if you want a true native framework, you need one specific development per platform. Or more realistically, you end up developing for Windows only, unless you target a specific niche where MacOS is somewhat relevant, and never Linux.

Or you use a cross-plateform (not so native then) UI toolkit, like Qt. You have a sub-part UI experience and you still need to write C++. Why would you do that ? (And that's why the vast majority of software isn't developed this way).

CSS and JavaScript have quirks, but I mean, we're talking about C++ as an alternative …

Qt has bindings for many languages, including JavaScript. It's capable of delivering experiences much closer to native than any Electron app I've ever seen. The catch is that a minimum-effort Electron app feels like a web page but a minimum-effort Qt app feels like a bad native app. There are also frameworks like wxWidgets that use actual native controls.

No, you develop like we did on the 16 bit days.

Either do a new one for platform, which was the case when Assembly ruled.

Or make a proper application architecture suited to the applications being done in-house, that wraps the native APIs into general ones.

C++ is strongly typed and compiles to native code, a much saner alternative than "anything goes JS".

And CSS + JS are miles away what something like VB, Delphi or Smalltalk allowed in the early 90's.

Yes I know they weren't responsive and whatever.

There were layout managers already available, it was just a matter of actually using them.

Vast majority isn't developed that way, because it is cheaper to pay to young inexperience JS developers that are re-inventing the idioms of the 90's desktop UIs[0], than experienced C++ developers aware of what actually takes to make a good UI/UX.

[0] - https://bitquabit.com/post/the-more-things-change/

> Vast majority isn't developed that way, because it is cheaper to pay to young inexperience JS developers […], than experienced C++ developers

I think you just nailed the essential point: in 2010+, the young and cheap developers are JavaScript ones, and not C++ ones. Maybe that tells something about which one is the most accessible, don't you think?

I can also go to craigslist and get someone that does repairs on the side, or pay for someone that costs twice as much but actually does the job only once.

I think, this goes way beyond just companies preferring to hire cheaper developers and beyond software engineering as such. There is a larger, universal force at play here. Examples of poorly designed, engineered and built things are everywhere in the world. It is seemingly cheaper to do it this way. But what may be saved upfront on production quality, is usually spent many times over on usage, maintenance and subsequent rebuilding, making the total cost higher.

For example, a road built with cheaper materials will break and need to be patched more often. A poorly engineered application will be slower, consume more CPU power, more data bandwidth and require more storage space, will be buggier and waste more users' time.

With only a very basic understanding of economic theory, I would imagine that market forces at scale would optimize these inefficiencies and ultimately work to reduce total costs. Perhaps this unconscious, natural process would even work, were we not consciously optimizing against it on the wrong variables, such as the next quarter's profits.

> C++ is strongly typed and compiles to native code, a much saner alternative than "anything goes JS".

C++ (though statically typed) is weakly typed.

C++ is not C, if that is what you are getting at.

C++ is not C, but is still weakly typed. I think even Rust is weakly typed in unsafe mode (I'm open to correction about that). This makes sense when you think about the CPU which is weakly typed and dynamically typed (it's also dynamically scoped unlike all the modern lexically scoped languages running on top of it).

"weakly typed" is not well-defined, however, I don't think that Rust is, even in unsafe. If you can provide a C or C++ example, I can tell you what that looks like in Rust.

Having recently made a website with a non-trivial layout that required lots of ugly JS to implement adequate scaling and bevavior, boy, I can't disagree more. I do UI in QML in $dayJob and gained a whole new appreciation for how much simpler and faster it is to achieve similar results in a more consciously crafted language.

Unfortunately it was our wedding website and I didn't think "let's hold off until I can use Qt/WASM" would go over too well ... :-)

> QML > consciously crafted

LOL

Now QML has its warts for sure, but it benefits from being designed with well-known use cases in mind, so it has lots of features suitable to them.

HTML was designed for structured, flowing text documents and everything else got bolted on top with only partial awareness of where the journey was headed (reading up on the origins of stylesheets and the relevant discussions is interesting in this respect). As a result it's just a mess for what it's used for now, pain-alleviating salves like flexbox notwithstanding.

When I do any non-trivial UI in the web stack, I can feel I am in continuous workaround territory. I'm trying to bend something ill-suited to my will. I don't get that feeling with QML.

> When I do any non-trivial UI in the web stack, I can feel I am in continuous workaround territory. I'm trying to bend something ill-suited to my will. I don't get that feeling with QML.

That has been my experience as well.

I think the web dev crowd advocating HTML/CSS originates in a) limited knowledge beyond the web tech field, and/or b) thinking that web is the state-of-the-art of computing.

The trouble with modern web is, that it was not so much designed as it evolved. But evolution in general is doggone slow and produces mistakes and mutations. I think the evolution of the web platform is still in a very early phase.

Are you really comparing your professional expertise with something you've just started to learn for your wedding website?

If all you know is C, writing an “Hello world” in C will be easier than doing the same in Python, but is that really a good insight of which language is easier to write ?

I see your point, but no. I've made websites semi-regularly since the late 90s and have contributed to a browser engine, so it's not lack of familiarity. This was just the first site in a few years. I think my argument takes rustyness/routine into account.

Try writing something as simple as a dialog in Qt. It all makes sense, you subclass a QDialog, instantiate it and show it.

Try doing that in pure HTML/CSS/JS, you're basically left with a clusterfuck. There's piles and piles of libraries built to workaround this clusterfuck from Bootstrap to react-modal and even the best of them have worse APIs for this than Qt does.

Ultimately, drawing widgets just makes more sense for desktop applications than trying to hack document-oriented HTML to be a usable UI framework.

Don't get me started on layouts...

if you're having a hard time doing modals and layouts with html and css you should perhaps start over and try grasping the core concepts. this system, unlike qt, is about separation of concerns, so structure and presentation are defined separately. far from a clusterfuck, it's actually a very good idea. if you are having a hard time finding non-crap libraries, then build your own pile of shit library. at least there are plenty of choices to pick from. it's called an ecosystem and it, unfortunately, is what you people don't have.

    <dialog>
        <p>Hello world</p>
        <button>OK</button>
    </dialog>

    <script>
        let dialog = document.querySelector('dialog');
        dialog.querySelector('button').addEventListener('click', () => dialog.close());
        dialog.showModal();
    </script>

Yeah, it would be great when it'll work for more than just 60% of the internet users. Maybe then we can actually use it!

I'm so sorry that a little bit of HTML and JavaScript reminds you and other commenters under my post of web developer's Old Browser nightmares and brave endeavors of satisfying 100% of Web users at any the cost, but we're talking about Electron which ships a quite recent version of Chromium :-)

cool... then now make it work for ie. and mobiles. and... everything else other than the betas of chrome and firefox

here you go: https://github.com/GoogleChrome/dialog-polyfill

TypeError: dialog.showModal is not a function

Your Electron version is old; if you're shipping it, you're probably putting your users at risk due to security issues in them. Check the latest versions here: https://electronjs.org/releases

https://caniuse.com/#search=dialog ? NO! <script> confirm("No dialog needed") </script>

Nice table, which shows that you are free to use <dialog> and many other modern features to write your Electron app:

  Electron v2.0.2
  Chromium v61.0.3163.100
  Node v8.9.3v8 v6.1.534.41

Electron… fair point! Except we were comparing new web GUIs.

On the flip side Electron explicitly does not impliment confirm() and prompt() which made me furious.

So there is definitely truth in the general js=cluster-fuck sentiment.

`confirm()`, `alert()`, `prompt()` and similar are widely regarded as mistakes. Including them on your new Electron app isn't something you should be doing in the first place.

Indeed: https://developers.google.com/web/updates/2017/03/dialogs-po...

Electron has native dialog APIs: https://electronjs.org/docs/api/dialog

You forgot a few part of the experience :

- learn C++

- install a C++ compiler

- learn Qt

- install Qt

For the web, you just need a browser, and JavaScript & CSS is way simpler and with way more documentation (especially for beginners). And for a simple modal dialog, you'll end up with 20 lines of code with no need for any framework …

for the web you need to

- learn html

- learn css

- learn javascript

- learn ui framework whatever

- learn what a transpiler is

- install node.js just to process your files

- learn how a client-server architecture works

- learn how to setup a web server

...

dude, you just don't know how deep this rabbit hole is

Lol, this is ridiculous.

You need to learn HTML, CSS and JS, but that are orders of magnitude easier than C++. Many people using it doesn't even have any computer science training.

Everything else you said (transpiling, framework, webserver) is totally optional and context dependent. And absolutely not needed to write a modal … I wrote a personal website this year, and I didn't need a single of this. Of course they are useful if you want to write a professional web app, but so is unit testing, a CI server, or a build system. But this isn't necessary to do simple stuff on the web.

Writing a website has a incredibly low barrier to entry, that why so many people complain about web developers not being real devs.

If you think the web is harder to grasp that the C++ ecosystem, you're being delusional to say the least.

Orders of magnitude easier than C++? Please. C++ at least done Qt style really isn't that bad, it took me a few hours to get up and running with a reasonable Qt setup at work and start a project, when I had to do the same for electron I spent nearly a week mucking with gulp, babel, react and reading about which packing solution I should use, if I want to use TypeScript or Flow and if I can integrate them with the libraries I need to work with...

Learning Qt is much easier than the JS ecosystem. It's one intergrated package with no messing around and a very clear suggested structure to applications.

My coworkers still seem to want to hack everything in to main.js, can't understand react and one of the main libraries we are required to work with just doesn't integrate well with it at all. On the Qt side of things everything flows smoothly, the class architecture makes sense.

A computing course that doesn't teach C++ is a quite poor one.

What year is it again? Many (if not most?) computer science classes don't teach C++ anymore. They still teach C or Java, but not C++.

You need to realize the world you live in: while still useful for some specific applications, C++ is not a mainstream language anymore.

My university never teached C, first year students were perfectly able to understand C++ in early 90's.

It still does nowadays, in 2018, and like any good CS degree it teaches lots of other programming languages and paradigms as well.

There is lot of room for learning during 5 years.

If a computer science class in 2018 only does language X or Y, it is indeed quite poor.

Oh, but there's plenty of language to teach : Java, Python, JavaScript, etc. and guess what. None of those were invented «early 90's» ;).

If a university wants to teach object-oriented programming, they can teach Java or C++. Guess which wins the decision in the majority of cases …

C++ isn't mainstream anymore, get used to it.

Java: 1995

Python: 1991

JavaScript: 1995

> If a university wants to teach object-oriented programming, they can teach Java or C++

Or Python. Or Smalltalk. Or Ruby. Or...

IMHO you both go off the opposite ends: No, a generic "developer" isn't badly educated if they don't know C++, but that doesn't mean C++ is some irrelevant language. It's critical for some domains of computing, and widely used.

> IMHO you both go off the opposite ends: No, a generic "developer" isn't badly educated if they don't know C++, but that doesn't mean C++ is some irrelevant language. It's critical for some domains of computing, and widely used.

I never said it was irrelevant, I said it wasn't the mainstream it was in the early 90s. See my post above:

> while still useful for some specific applications, C++ is not a mainstream language anymore.

So are on the same line you and I :

> a generic "developer" isn't badly educated if they don't know C++

An university teaches much more than just object-oriented programming.

In 2018 C++ is the programming language driving Machine Learning, VR/AR, HPC, Fintech, GPGPU, WebAssembly, compiler research, OS research.

Which are all CS degree relevant subjects.

If you want to learn a specific language for whatever is currently cool on the job market there are vocational schools for that.

C++ is used by most games and widely used in embedded computing, often with Qt. All major HTML engines are written in C++, too. You seem to be confusing your immediate environment with the world.

No... Leaving aside your opinion that Electron is easier, Electron forces an unsolvable problem on you - the performance of the app is horrible. A bare bones nothing Electron app idles using 150mb ram and has a huge binary size, all 25 million lines of chromium and nodejs. And Javascript is slow and not designed for application programming.

Sounds like the argument C++ programmers use against Python.

You're not responding to my point though? I have a slow laptop, and I cant run Electron apps. If I run a Qt app, it runs beautifully. Would people use VLC if it was made in Electron? No.

I like Python too.

Not everybody has a slow laptop. And while people wax how computers from 80s were booting in 2 seconds and everything was lightning fast compared to the bloated software of today, there doesn't seem to be much of a movement towards ditching todays computers and going back to Windows 95 and Mac OS 9.

https://insights.stackoverflow.com/survey/2018/#development-...

  > Not everybody has a slow laptop

No shit, my point was, and still is, Electron has extremely poor performance, and theres no reason to use it over Qt..

You still havent responded to my point..

It's more DOM vs. whatever framework.

DOM is very good for laying out webpages, but seriously falls over when trying to do layout for applications. The layout of the frameworks you mention are all designed around making application layout as efficient as possible.

Although WPF stands out, it's layout is for more DOM like than the others, and suffers for it.

Well, there's nothing stopping other frameworks from being ported to wasm as well. Then they'd be back on a more even playing field.

> Well, there's nothing stopping other frameworks from being ported to wasm as well.

I for one am excited to see Electron to get ported to wasm so we can complete the circle

The ultimate irony of course being that Electron was originally a Qt app. KHTML written against Qt by the KDE folks (some of whom turned into Qt folks) -> forked into WebKit by Apple when they needed a browser, using a shim layer to work on Cocoa, which grew into a platform abstraction framework -> forked into Blink, used in Electron. Qt begat its own competitor.

Because on each platform it has to compete for mindshare with the platform that the platform owner promotes.

Reply on news.ycombinator.com