2 ms·

Regarding gotchas, it's bearable. I only have a couple on my short list: == vs === and xs.includes(x) vs x in xs, and only the latter is not reducible to a triv

Regarding gotchas, it's bearable. I only have a couple on my short list: == vs === and xs.includes(x) vs x in xs, and only the latter is not reducible to a trivial rule of thumb. TS is helpful in this regard, possibly there are more in plain JS. Regarding performance, modern JS is plenty fast, but it's not in the 'terrible' category. It's memory usage, perhaps ;) https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/node-gpp.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/.... For performance critical code JS is not the answer, but good enough for most uses, including UIs. Regarding UI paradigms, I'm not sure what the problem is, or what significantly better alternatives are. I did MFC/C++ in '90s and C++/Qt in the '00s, and both were vastly inferior to modern browser development. React+StyledComponents is a wonderful way to build UIs. There are some warts on the CSS side, but mostly because Stackoverflow is full of outdated advice.

jpcooper 6y ago
Why are MFC and QT inferior to the Javascript way? I don’t know much about either.
- alquemist 6y ago
  On top of my head: * Apps eventually degenerate in a mess of interconnected components triggering events on each other. Building UIs felt more like writing Verilog than writing functions. Nothing like chasing event ordering bugs through library components. With React I never saw 'enqueue a new event for component X' anti-pattern. All callbacks flow from children to parents in a fairly regular manner. * Related, there is no need to manually manage repaint events in React. Visual updates happen automagically. See, for example, https://stackoverflow.com/questions/952906/how-do-i-call-paint-event https://stackoverflow.com/questions/952906/how-do-i-call-pai... for a hair pulling session related to manual repainting. * On the ergonomics side, having a markup language allows for terse but readable definitions of component trees. I see 2020 Qt has introduced a markup language, this was not the case circa 2005. * Hooks give an extra layer of niceness. Declaring a component is as easy as declaring a function. Local state becomes almost as simple as declaring a local variable. * The inspector capabilities of modern browsers are very handy when debugging layout and styling issues.
  - jpcooper 6y ago
    Thanks for the detailed explanation.
StillBored 6y ago
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.

jpcooper 6y ago

Why are MFC and QT inferior to the Javascript way? I don’t know much about either.

alquemist 6y ago
On top of my head: * Apps eventually degenerate in a mess of interconnected components triggering events on each other. Building UIs felt more like writing Verilog than writing functions. Nothing like chasing event ordering bugs through library components. With React I never saw 'enqueue a new event for component X' anti-pattern. All callbacks flow from children to parents in a fairly regular manner. * Related, there is no need to manually manage repaint events in React. Visual updates happen automagically. See, for example, https://stackoverflow.com/questions/952906/how-do-i-call-paint-event https://stackoverflow.com/questions/952906/how-do-i-call-pai... for a hair pulling session related to manual repainting. * On the ergonomics side, having a markup language allows for terse but readable definitions of component trees. I see 2020 Qt has introduced a markup language, this was not the case circa 2005. * Hooks give an extra layer of niceness. Declaring a component is as easy as declaring a function. Local state becomes almost as simple as declaring a local variable. * The inspector capabilities of modern browsers are very handy when debugging layout and styling issues.
- jpcooper 6y ago
  Thanks for the detailed explanation.

StillBored 6y ago

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.