If anything, several C++ threads indicate those devs are tired of getting paid less.
If anything, several C++ threads indicate those devs are tired of getting paid less.
Sure, my code will be 2-10x slower than the C++ stuff, but modern companies move really fast. A given user-facing project often gets thrown out every 4-5 years for yet another iteration. I will have been in maintenance mode and adding little features for 2-3 years. The C++ devs would barely be done with the MVP before it would be time to start over.
This means my total value to the company is higher than the C++ dev (even though they're a talented and amazing developer)
This is all before mentioning the supply and demand issue. Look at stackoverflow's surveys.
2013 5.1%
2015 6.0%
2017 8.5% (11.9% of the 72.6% that identified as doing web development)
2020 37.1% (peak)
2022 25.9% (current)
That's a 5-7x increase in demand since React was first released in 2013 (despite all the framework wars of prior years, the number of dedicated frontend devs was relatively small).Everyone wants senior devs, but the number of devs with just 10 years of full-time experience is going to be 5% or less (despite the rhetoric, it takes more than 5 years to learn the frontend and that's only if we disregard the seriously niche things like WebGL). Instead, we see lots of "senior" JS devs that don't even know JS let alone the DOM. In contrast, you can easily find C++ devs with 15-20 years of experience (in fact, they may be easier to find than a C++ dev with only a handful of years of experience because people aren't learning C++ and C++ eats it's young).
The combination of productivity and lack off seniors drives up the salaries of middle and top end frontend talent.
Well, I agree it will have fewer memory bugs. But fewer issues altogether… you're just bragging now.
Your application will have awful keyboard navigation, will not support normal well established shortcuts, will contain vulnerable js that you will never bother to replace…
...what?
These are all things that any developer - C++, JS based or otherwise - needs to implement and/or be mindful of. This has nothing to do with the language/runtime/platform and everything to do with the team implementing it and their level of attention to the platforms themselves.
Hell I cannot tell you the number of QT-based applications I've opened on macOS that violate established shortcuts. This isn't an Electron-only problem. ;P
You rag on them for "bragging" but your entire comment is basically one big attempt at kicking down on another development platform.
There are many other reasons though. JS has only two number types (double and BigInt). As such, we can also essentially get rid of overflow errors that C++ does nothing to prevent. JS has an event loop baked into the core, so another class of C++ bugs go away. That same event loop bakes in its own thread pool to safely manage IO eliminating another class of bugs. Web workers (system processes) limit data sharing to slower, but more safe methods and eliminate yet another class of bugs. I'd note that these are some of the biggest possible sources of the hardest to find bugs and eliminates essentially all of the security nightmares found in C++ code.
Adding to this, JS code is more dense which tends to correlate with lower bug counts (until you reach super-high density like APL at which point you get maintenance issues). JS first-class functions with automatic closures adds a very powerful tool that is all-pervasive in real-world JS code, but isn't even present in C++ code (yes, closures exist, but in an extremely limited and manual way). Since ES2015, JS has powerful features like destructuring that make all the little data manipulations (so common in UI code) much easier and less prone to subtle bugs. If bugs do happen, JS makes it much easier to continue gracefully without everything crashing to the ground.
None of this should be surprising. C++ is an amazing language in its low-level area of expertise where all the features that can create more bugs are necessary and lead to amazing performance.
It also shouldn't be surprising that a very high-level language tailor-made for UI would be better at creating and maintaining a UI with fewer bugs.
As to keyboard navigation, that is entirely up to the devs to implement (whether C++ or JS). That said, web standards take A11y very seriously. Electron has `globalShortcut` and easy handling of shortcuts is baked right into the system if devs care to use it.
https://www.electronjs.org/docs/latest/tutorial/keyboard-sho...
On the other hand the C++ developer can use boost and Qt libraries to have a wide range of well tested, well implemented components that implement a wide range of things, without having to sift in npm for hundreds of low quality abandoned modules.
So IN TOTAL, your point is far from proven.
> As to keyboard navigation, that is entirely up to the devs to implement
No. Toolkits for example implement decent tabbing. The qt designer offers a GUI to decide the tab order. And assigning shortcuts is even easier.
If you go and use kdelibs you get support to completely customize every single shortcut from the control panel, or from your own application.
Oh by the way with Qt you also get support to find in which directory to save settings, data, and so on. Which is not so trivial because all the defaults can be overridden by specific env vars.
You can either use C++ and a toolkit that does all this stuff, or JS and reimplement everything every time.
Now you're arguing that reimplementing every time is faster. It's an opinion but I don't think it's as obvious as you think it is.