In Qt (QML), I couldn't quite find something like this and I had the feeling I needed to create my own framework from scratch, which is hard when, at the same time, you need to learn a new technology. There were some random ideas in various blogs and articles but nothing major or at least no officially supported one.
...note how I’ve said nothing to refute your comment because what you wrote it in responds to none of the historical empirical problems with this approach and just asserts “let’s make this not suck” glossing over the reasons why it sucks.
Apps do the same things everywhere. Why do we still need completely different languages, codebases, etc (not to mention teams of experienced hires) to deploy any little CRUD app?
Maybe we aren’t interested in fixing this because it means there’s less engineering to be done.
“It is difficult to get a man to understand something, when his salary depends on his not understanding it.”
I think it's less about engineering costs and more about dislike of javascript. Maybe even specifically javascript tooling and electron.
A big reason people want to standardize on javascript is because it is the runtime of the Web - I can't wait for Web assembly to get even better so we can standardize on something else.
You are writing code that runs nowhere, unless you can afford to shell out $1000 a year to keep your hardware current and $50 a month for the bandwidth to keep your software current. That's totally unsustainable from a global perspective.
In my view, the big issue right now is Electron, and developers who are comfortable developing for 1 Google browser per application. There's enough wrong with the current browser ecosystem that we don't need to make up numbers.
That sounds like incredible hyperbole considering all the major browsers are evergreen now.
Unfortunately, there is an almost religious devotion to it so it ends up used for many things it is actually terrible at (large teams, integration with large existing native apps, performance critical and highly interactive apps, apps that would be better off serving one platform, etc).
Example of native modules with React Native wrappers: https://facebook.github.io/react-native/docs/components-and-...
NativeModules API: https://facebook.github.io/react-native/docs/native-modules-...
Although much as it pains me, I think that is a lost cause. And it was lost through attrition - devs kept throwing non-native (often, JS-based) apps at users, and users got conditioned to each app having its own look, much like websites.
Fortunately, it does seem like these platforms are beginning to converge on a set of common UI patterns, e.g. Android adopting the tab bar, and iOS apps beginning to adopt Android's horizontal-paging navigation. The colors, iconography, and typography shifting can disorient somewhat, but I'd argue it's the navigation model that's most disruptive when using different apps.
Also, the security and performance implications of the Javascript dependency ecosystem should not be ignored.
Small greenfield app on a shoestring budget? It's perfect for that.
My comment was that it doesn't preclude it, addressing the parent's conflation of language and view layer.
Yes, you might have to do more work in React Native. But similar frameworks[1] appear to do this out of the box, if that helps.
Good news is they have invented a better programming language called ReasonML for React.
But seriously, if you're concerned about the quality of software, build better tools that guide new developers into best practices. Remove needless abstractions, replace others, and optimize the rest.