I’m not really that into the idea of JS-as-a-platform, but it obviously emerged because it fulfilled certain requirements that weren’t covered elsewhere.
The “way back” from this is for people like yourself to stop dismissing others’ work as “idiocy” and start building better solutions to these problems as you see them.
>I’m not really that into the idea of JS-as-a-platform, but it obviously emerged because it fulfilled certain requirements that weren’t covered elsewhere.
Maybe they weren't covered for a reason?
The ability to have your web team churn out lowest common denominator bloated JS based mobile/desktop apps was not a real requirement, more like a wish of some.
> These products will be dominated by superior options eventually.
Would love that to happen, but all the other market sectors suggest otherwise. "Cheapest to produce and worst quality" seems to be all that's available to majority of the population.
Yes. It's the most cost-effective solution, because:
- we haven't figured out how to make companies care about "delivering value" part of the "delivering value in exchange for money" work, and
- we allow them to dump externalities on users without consequences or compensation.
So the most cost-effective solution in this scheme will be a half-assed product that's barely good enough to be sellable, and which makes my computer use more electricity while being less capable of running software simultaneously.
And the whole point of native components in Vue/react is to reduce those negative externalities, but the first thread I see in this post is criticizing Vue for sharing from react's ecosystem instead of inventing an indentical solution from scratch?
At the current rate we will soon have phones with 8GB RAM and who knows how many cores not having to rewrite same code 3 times in 3 lang. will def. be catching on more.
If by soon you mean in 2 years on flagships (looking at current specs, I don't buy it), then for regular users buying regular smartphones it'll be ~7 years from now.
I don't feel like this is a valid justification for being wasteful, though.
> The ability to have your web team churn out lowest common denominator bloated JS based mobile/desktop apps was not a real requirement, more like a wish of some.
Come on, the requirement has always been there. It is "Shit out that underbudgeted project in half the promised time". Those small frameworks where you can hire a cheap front-end guy and have him manage the entire project alone or in a small team are perfect to fill that niche.
Maybe "idiocy" is unnecessarily strong, but I certainly don't have to praise all emerging experiments just to sound polite, do I? The emerging of all these stacks is because of approachability. Everyone has a browser. Anyone who wants to create their first website can do so, by opening up e.g. notepad. By this approach you get low-quality, self-taught JS "experts" who are much cheaper to hire than a proper software engineer with fundamentals of computer science. After a few years these developers feel so confident, they decide to launch their own perfect new framework/library to solve all the problems they experienced!
There is a better solution. It's called native app development, without a hyphen of any sorts in front of "native". Different platforms have different quirks and there is no way to have the exact same UI/UX on all platforms.
The true challenge is to explain the executives, that hiring 2 developers will be much better in the long run, than 1 underpaid JS developer for all platforms.
I used to agree with you. But over the last few years, in their own ways, Apple and Microsoft have dropped the ball on their native desktop UI toolkits. So, whereas the argument for native used to be "rewrite your client once per platform, and you get a better language, better performance, better usability, and a better development experience", now it's "rewrite your client once per platform and you may get a better language, depending on your taste, probably better performance, an aging closed-source toolchain, an outdated development paradigm, outdated APIs covered in legacy-barnacles, debugging-resistant performance pitfalls, and decent usability if you're ok with a generic one-size-fits-all look (and you're on your own if you're not.)" In other words, the argument for native, and native development itself, is not aging well.
> but I certainly don't have to praise all emerging experiments just to sound polite, do I?
Speaking from personal experience, I have found it vastly more productive to focus on the good than the bad. Yes, even in situations where the other person is literally [1] too dumb to put their underwear on correctly without assistance.
I don’t know how or why it works to do that, but it does, and the improvement from doing so is immense.
I’m not really that into the idea of JS-as-a-platform, but it obviously emerged because it fulfilled certain requirements that weren’t covered elsewhere.
The “way back” from this is for people like yourself to stop dismissing others’ work as “idiocy” and start building better solutions to these problems as you see them.