There's a moment every developer eventually hits: you're staring at a platform API you know you need, but your codebase is JavaScript/TypeScript.
Maybe it's iOS notifications. Maybe it's Android permissions. Maybe it's "just" getting a list to scroll smoothly, or a camera preview to behave, or an animation to not hitch on older devices. And suddenly you're knee-deep in a different language, a different UI framework, a different build system, and a different set of "gotchas" you didn't sign up for when you just wanted to ship a feature.
And so the cycle repeats across decades, across platforms, across generations of frameworks: We build abstractions.
Not because we're lazy. Because we're trying to optimize what matters.
This is the "JavaScript insanity" people love to dunk on: the idea that instead of writing "real" native code, we invent layers (APIs, runtimes, interop layers, declarative UIs, build tooling, packaging systems), just to write the same app in the language we already know.
But if you've ever shipped a product, you know exactly why this keeps happening.
The market doesn't reward "purity." It rewards outcomes:
- shipping fast,
- hiring from a broader talent pool,
- keeping teams productive,
- reusing code and business logic,
- iterating weekly instead of quarterly,
- delivering consistent experiences across platforms
So yes, there is insanity here. But not in the way the critics often mean.
The "insanity" is that we keep pretending native complexity is a rite of passage, when the real goal is delivering value to users and businesses. In that light, abstractions aren't an escape hatch, they're a strategy.
And nowhere is this story clearer than in the parallel arcs of React Native and NativeScript.
They exist today because of one simple truth: platform APIs are powerful and JavaScript, for better or worse, has become the world's default interface language for developers.
JavaScript and native platforms
Most of us know JavaScript didn't set out to be a systems language. It set out to be a scripting language for documents. Then it turned into the lingua franca of the web. Then the web turned into an application platform. Then businesses asked a predictable question:
If we can build and ship products with JavaScript on the web... why can't we do the same everywhere else?
The first wave of answers were pragmatic and browser-shaped:
- "What if we put your app in a WebView?"
- "What if we expose a few device APIs and call it mobile?"
- "What if you could ship cross-platform without requiring language context switching?"
This wasn't a bad idea. It was an economically honest idea. The web was already the largest developer ecosystem in history, and JavaScript was already the language those developers spoke.
But the web-shaped solution had a web-shaped ceiling:
- performance,
- native UI fidelity,
- deep platform API access,
- complicated edge cases where "almost native" stopped being enough.
So the next wave emerged: don't emulate native-use native.
That's the crucial philosophical pivot that React Native and NativeScript share:
- not "draw everything yourself in a canvas,"
- not "wrap it in a web browser,"
- but "speak to the platform directly, while letting developers stay in JavaScript."
Same destination. Different routes.
React Native and NativeScript: complementary paths to native from JavaScript
If you zoom out, React Native and NativeScript may seem like competing ideas to the same question:
How do we get native capabilities and native UX from JavaScript developers?
The truth is they're complementary answers. Scream! 😱 I know but please put the ego aside goodness gracious; it slows down a lot of practical advancement and development joy. Yes one is only specific to React and the other works with any framework or mental model you prefer. But NativeScript can be taken advantage of in React Native and NativeScript is already taking advantage of React Native today with Open Native in addition to cross pollinating with View/Text markup parallels to make using either powerful to bottom line business.
React Native: a declarative UI that targets native
- You already know React.
- You already know components.
- You already know a declarative mental model.
- So write React.. and we'll render it as native UI.
You don't have to understand the entire native ecosystem on day one. You could become productive quickly, and learn deeper native concepts only when the app demanded it.
That's a pattern worth underlining:
Abstractions aren't meant to eliminate native knowledge. They're meant to delay it until it's actually needed.
And for many teams, that's the difference between shipping and stalling.
NativeScript: direct access to native APIs, from JavaScript
- What if JavaScript could call native APIs directly?
- What if "learning the platform" didn't require switching languages?
- What if you could remain in one codebase and still use the full surface area of iOS and Android?
The platform is the framework. We'll give you the keys.
That has huge implications:
- You can use native UI controls without re-implementing them.
- You can reach deep platform APIs without waiting for wrapper libraries.
- You can keep JavaScript/TypeScript as the developer "interface," while still having first-class access to Swift/Obj-C and Kotlin/Java worlds.
- You don't need to look for a "NativeScript integration" in SDKs. The platform is the framework, yes it will work...always.
It also leads to a different kind of developer experience:
- It rewards developers who want power and escape hatches.
- It reduces the "framework ceiling" because the ceiling is... the platform.
React Native tends to give you a strong paved road. NativeScript tends to give you a paved road and a map of every back road.
What makes sense to you is purely:
- team composition,
- app requirements,
- how often you need custom native work,
- how much you value direct platform access vs. framework conventions.
Abstraction isn't a betrayal of native
One of the easiest critiques to lob at JavaScript cross-platform frameworks is: "you're just avoiding doing it the real way."
But that assumes the "real way" is inherently virtuous.
In reality, the "real way" is just a cost structure to the economic minded:
- a cost in hiring,
- a cost in time,
- a cost in duplicated effort,
- a cost in coordination between teams,
- a cost in bugs that appear only when two separate implementations drift apart.
And in using React Native and NativeScript, you're doing something deeply rational:
You're aligning your technical choices with the reality that software is built under constraints.
Conclusion: rethinking "insanity" in software choices
When people call it insane to avoid writing native code, they're usually imagining an ideological battle. But this isn't ideology; it's economics. If a JavaScript approach lets you hire talent, ship sooner, reuse more, and adapt to new platforms without rebuilding the company every time a new device category appears... then maybe the insanity isn't the abstraction.