MFC was a mess, In the 90's. I dabbled with MFC multiple times, mostly to support other peoples applications and it was overwhelmingly bad. For C++ I mostly just used the native win16/32 APIs because it turned out to be less kludgy for small GUI's associated with various services I was writting. OTOH, I did a _LOT_ of development with vb, and later delphi for the frontend of those services. Both of which were significantly better GUI development tools than visual studio at that point.
I've since moved on to other development areas, but have done a bit of both JS (on and off from about 2005->2015), and a bit of QT here and there too. The latter seems to have gotten better in the past few releases AFAIK. C# is at least ok too.
So in the case of MFC and early QT its not surprising that you prefer react+JS as neither of those were exactly the pinnacle of UI development in the late 1990's early 2000s.
What you describe in a later posting about MFC was never really a problem with the VCL, pretty much no one dealt with repaint messages unless you were writing a custom component. I remember showing a number of MFC programmers BC++ builder (which is also still a thing) when they were singing the MFC tune. They tended to get really quite after that.
PS/edit: Crazy, I just went and looked at the latest visual studio documentation and MFC is still an option, and at first glance seems basically the same as it was 25 years ago. Although the section on creating win32 applications is in front in the manual. I guess i'm not surprised that MFC is still a thing, but I am surprised that it doesn't have a giant depreciation warning. I frankly can't imagine creating a new MFC application in 2020.
Many of the gotchas wouldn't ever show up if only people committed to writing JS as sensibly as they write their programs in other languages when they're being forced to do things a certain way.
But when it comes to JS and even other dynamic languages, people for some reason absolutely lose their minds, like a teenager whose parents are going out of town and are leaving them home by themselves overnight for the first time. I've seen horrendous JS from Java programmers, for example, that has made me think "Just... why? Why didn't you write the program you would have written (or already did write!) were you writing it in Java?" Like, "Yes, there are working JS programmers who do these kinds of zany things and make a real mess like this, but you don't have to, you know?"
It's as if people are dead set on proving that they need the gutter bumpers and need to be sentenced to only playing rail shooters instead of the open world game, because they can't be trusted to behave responsibly otherwise.
https://users.dcc.uchile.cl/~rrobbes/p/EMSE-features.pdf https://users.dcc.uchile.cl/~rrobbes/p/EMSE-features.pdf
Honestly this is really spot-on. I think part of the problem is people have heard that javascript is bad and just expect it to be bad, so they never really try to learn it and just copy and paste something that works and maybe expand on the bad examples when they should just be learning how to use javascript.
Javascript requires some self-discipline, where other languages discipline you if you try to fuck things up yourself. It's kind of like a drunken sailor on leave going on a bender on-shore - the minute they leave the ship all bets are off. Some people just can't wrap their head around using weak/dynamic typing, because it loosens the rules. But that doesn't mean there aren't any rules.
I code in a dozen other languages and Javascript is still my favorite because it's so easy to use, no boilerplate, and it doesn't give me any "gotchas" because javascript actually does follow some very basic easy to understand rules. The people that don't bother to learn those rules invariably shit on javascript. It's not fair, it's not real criticism.
And practically all of the "examples" of bad javascript is almost always code that nobody should ever write, in any language, because it's just stupid to write code in those ways. But people think "aHa, aNoThEr 'gOtChA'" and the myth of javascript being somehow inferior continues. And to anyone who actually knows how easy javascript is to use, it just looks silly, pathetic, and obnoxious.
That is simply not true, io language is prototype based yet it is simple to reason about, fix for JavaScript:
Object = Object.prototype
Function = Function.prototype
That's how most dynamic languages work, no need for explanations, obvious assertions:
Object.__proto__ === null
Function.__proto__ === Object
object = new Object.constructor
object.__proto__ === Object
object.constructor === Object.constructor
object.toString === Object.toString
object.private = function () { return 'hello' }
Object.shared = function () { return 'world' }
Object.constructor.static = function () { return '!' }
It shows hidden complexity — what does instanceof mean?
// Object instanceof Function
Object.constructor.__proto__.constructor === Function.constructor
// Object instanceof Object
Object.constructor.__proto__.__proto__.constructor === Object.constructor
// Function instanceof Function
Function.constructor.__proto__.constructor === Function.constructor
// Function instanceof Object
Function.constructor.__proto__.__proto__.constructor === Object.constructor
Why would anyone want this? Lets get rid of .constructor on both sides:
Object.constructor.__proto__ === Function
Object.constructor.__proto__.__proto__ === Object
Function.constructor.__proto__ === Function
Function.constructor.__proto__.__proto__ === Object
Now it is obvious — constructor is a Function, Functions __proto__ is Object. JavaScript programmers jump through ".prototype" hoops which should not be exposed.
... what? This comment is incomprehensible. What does it have to do with the parent comment (besides exemplifying the "teenager left at home for the first time" and creating-a-mess stuff)?
None of this crazy reflective, meta-level programming belongs in the LOB application logic of any program. Save it for your programmer workspace/REPL environment--which is something that 90+% of JS programmers aren't using anyway. They're all editing "dead" files in Visual Studio Code and SublimeText.
> Object.constructor.__proto__.constructor === Function.constructor
// Object instanceof Object
... and that's not even what instanceof means.
Do you ever type "prototype"? Do you ever type "prototype" in any language but JavaScript? How it differs from other languages accessing [[Prototype]] / class directly, not through constructor?
I've thought that's caused by prototype inheritance, but no io language [1] prototype based yet easy to understand. The only difference — it does not hide [[Prototype]]. I've redefined Object and Function to show how it works. You would get same result in "dead" files. REPL to make it easy to reproduce.
Imagine it is another language
object.private = function () { return 'hello' }
Object.shared = function () { return 'world' }
Object.constructor.static = function () { return '!' }
vs
object.private = function() { return 'hello' }
Object.prototype.shared = function () { return 'world' }
Object.static = function () { return '!' }
Can you see the difference? Or straight from io tutorial
Contact = (class {
constructor(name, address, city) {
this.name = name
this.address = address
this.city = city
}
}).prototype
holmes = new Contact.constructor("Holmes", "221B Baker St", "London")
Contact.fullAddress = function() {
return [this.name, this.address, this.city].join('\n')
}
holmes.fullAddress()
No "prototype" (except from class but it can be redefined).
> ... and that's not even what instanceof means.
Thank you, it should check [[Prototype]] not constructor
// Object instanceof Object
Object.constructor.__proto__ === Function
// Object instanceof Object
Object.constructor.__proto__.__proto__ === Object
// Function instanceof Function
Function.constructor.__proto__ === Function
// Function instanceof Object
Function.constructor.__proto__.__proto__ === Object
[1] https://iolanguage.org/ https://iolanguage.org/
> there is underlying problem
No, you haven't ever defined _any_ problem, only abstract things that bother you.
There is only one problem that matters: writing a (correct) program. If you can do it without meta-programming, then you should.
If you start meta-programming when you don't have to, then you have already lost. If you are doing this when you shouldn't, and then you experience pain and say, "This system needs to be fixed", then make sure you fix the correct part of the system: yourself.
> JS [[Prototype]] is equivalent of class hierarchy.
Which nobody is futzing around with (because they can't, and they shouldn't futz with it anyway) on the level that you're insisting we do, in the ordinary course of writing programs. (The level where you are seeing "problems".) Once again: keep that stuff in your REPL. If you are editing a regular source file that will be committed to the repo and you are typing out "prototype" or "__proto__" or "setPrototypeOf" more than once or twice every 10k lines, then you're almost definitely doing something wrong.
> You've got burned by Java and C++, bad for you.
No, it's that the world is burning because of thousands of programmers who can't behave responsibly because they pick up a dynamic language and say, "There are no adults around to discipline me, so now is the time to go nuts."
(And the irony is that this thread exists because of your complaints about JS and how it burns you, where I started out arguing that JS is fine at the beginning. But now you're the champion for JS?)