I agree with you, as ultimately an employer will have to raise wages to get/keep employees.
But it's not really enough to explain it because the engineers who do Vx could always just switch to a better paying platform.
I wonder if the low salary indicates that the Vx Devs at that low price aren't able to switch out. Either due to location, lack of ability, or some other capture.
It's not always trivial to change technologies job-wise. You may be perfectly confident in a technology you haven't used before professionally, but people doing hiring may think different. I have been screened out for "only" having hobby/extracurricular experience with tech I'm fully qualified to use.
As anecdotal evidence I know many developers (including myself) who refuse to touch frontend. It still stands, supply and demand rules apply. Does not matter why the supply is low or the demand is high.
I am an embedded developer using primarily C++, but I've done a ton with Javascript. I don't know why an embedded developer would refuse to touch frontend, other than a suspicion it would fit the stereotypes of database applications (CRUD, tables). The embedded UI's I've worked with the most were not in HTML but we have done demos using WebKit and Angular or GWT. Given the asynchronous constructs it takes to keep our product running properly, the asynch in Angular was not an issue. We also had an in-house test tool that we ran for over a decade that used Javascript for the tests themselves. This was not asynchronous but we ended up with several engineers who knew Javascript's scope peculiarities and unit test requirements because of it.
Yeah, frontend dev is it's own beast. I've seen competent C++ devs at a complete loss when facing JavaScript. Especially if they've never done any asynchronous programming before.
I am not entirely sure what qualifies for being "competent C++ devs". My thinking goes that it is kinda hard to imagine competent developer in general (never mind C++) not having knowledge about async patterns.
I have done async in Clojure, Erlang (Elixir) and Rust but never touched Javascript (wat?). Not sure you can attribute async to frontend development. Erlang predates Javascript by almost 10 years.
Unlike Erlang/Go/certain Clojure libs, the JavaScript flavor of async is primarily around red-blue functions. A lot of stuff is explicit and not handled by the runtime. A single async keyword can easily taint the entire codebase.
More importantly, frontend is extremely demanding in terms of UI. While for e.g. QT, WxWidgets, native GUI toolkits, it is perfectly acceptable for things to look the same. On the modern web, every significant app is expected to have a "design language" and not look like each other. On the other hand, HTML by default isn't very stateful, sure it has some stateful components like checkboxes but in general you have to store the state in code. And every code base needs a custom UI. You end up with a state space explosion. That is also why frontend frameworks these days are trying to force things into finite state machines i.e. Redux, Elm architecture. Whatever term you prefer. Half of your UI codebase often have absolutely nothing to do with business logic and instead animations and user experience code to make things feel "slick". A ASP.NET WebForms just ain't going to cut it if you wanna build a SaaS. Sad because tons of money have been wasted on essentially marginal improvements on user experience, but good if you are the consumer of course.
> Not sure you can attribute async to frontend development.
Not trying to do that. But (unlike C++), you have to understand async to use JavaScript sensibly. If for whatever reason you haven't come across it another language, then you might struggle (esp. if you're coming from C or C++ where the skills required are very different).
But it's not really enough to explain it because the engineers who do Vx could always just switch to a better paying platform.
I wonder if the low salary indicates that the Vx Devs at that low price aren't able to switch out. Either due to location, lack of ability, or some other capture.