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.
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 ... :-)
LOL
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.
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.
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 ?
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...
<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> Electron v2.0.2
Chromium v61.0.3163.100
Node v8.9.3v8 v6.1.534.41On 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.
Electron has native dialog APIs: https://electronjs.org/docs/api/dialog
- 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 …
- 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
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.
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.
You need to realize the world you live in: while still useful for some specific applications, C++ is not a mainstream language anymore.
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.
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.
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.
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++
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.
I like Python too.
https://insights.stackoverflow.com/survey/2018/#development-...
> Not everybody has a slow laptop
You still havent responded to my point..
Maybe when I get to see Blend implemented with WebComponents.
Moreover, it's unfair to insist on portability when comparing native vs. Web without doing the same on the native side.
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.
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.
Look at the support for (flexbox)[https://caniuse.com/#search=flexbox] for instance.
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.
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 …
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.
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?
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++ (though statically typed) is weakly typed.
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.