What's involved with NativeScript open source?

As someone who has been lucky to enjoy NativeScript open source for several years and an active contributing member to it's Technical Steering Committee (TSC), I feel it my duty to share what is actually involved since the technology exists purely for the benefit of the tech community at large.

If you'd like to be involved, the TSC is excited to talk with you. Feel free to comment or connect on Discord anytime. If you have never heard of NativeScript before, you may find this presentation fun and informative from OpenJS World 2022.

• The ABCs of NativeScript
  • A. Platform runtimes
  • B. Conveniences
  • C. Documentation
• NativeScript aims "to not create anything new"
• Does anything really need to be maintained?
• What do I mean by "Conveniences"?
  • Conveniences are where Community falls in love or hates your guts
  • Maintaining NativeScript core
  • Maintaining Flavor Integrations?
  • Project Templates
  • Plugins
  • The Hidden Benefit of NativeScript regarding Plugins
• Documentation
• An open source detour...who the hell am I?
  • Economics and Jobs
  • But there are no NativeScript jobs?
  • Why NativeScript when React Native dominates?
• Market Trends, Uncertainty and AI
  • Always understand before using. Help is always near.
  • Is NativeScript Anti-Web Development?
• What real advantages does NativeScript enable and what does it mean long term?
• Enjoy open source
  • Credits

The ABCs of NativeScript

NativeScript open source can be reduced to three primary facets, A, B and C.

A. Platform runtimes

Embedded v8 engine built for various platforms. v8 is a high-performance JavaScript and WebAssembly engine, written in C++, enriched by the NativeScript TSC with natural target platform API capabilities. This is the exact same engine found in Chrome and Node, among others.

Packaged and distributed on npm as:

• @nativescript/android
• @nativescript/ios

B. Conveniences

Optional packages which represent one (of many) ways to work with the runtimes:

• @nativescript/core (a JavaScript library)
• nativescript ("ns" for short: a node command-line interface, aka CLI)
• flavor integrations (Angular, Vue, React, Svelte, Solid)
• project templates
• plugins

C. Documentation

Clearly and diligently documenting everything. This is also a convenience (like B) but documentation is it's own kind of animal within any technical space so it deserves it's own category.

NativeScript aims "to not create anything new"

One of the fundamental tenants of NativeScript is that by nature, it aims "to not create anything new". This has been commonly misunderstood.

Because NativeScript empowers platform development "as-is", it actually doesn't create anything new. It just gives you the platform in JavaScript.

This simple premise is implied in everything you do with NativeScript and it's where the extreme versatility and power comes from. The "Less is More" mantra is prevalent in everything NativeScript does.

Does anything really need to be maintained?

Perhaps the most surprising is only A needs to be maintained, technically speaking, for the technology to simply exist. However even the frequency or attentiveness to that maintenance can be somewhat endlessly debated since maintaining the runtimes is more about evolving alongside JavaScript standards at any moment in time. Objectively speaking the NativeScript runtimes could never be maintained and be operational for likely several years (depending on what level of JavaScript language features you need or expect from them).

Historically this is already the case. The NativeScript runtime can be (and has been) implemented in more than one way. In fact, it was originally implemented on iOS using JavaScriptCore and is still in use today among applications. It's published on npm as @nativescript/ios@JSC. This hasn’t been maintained in 4+ years, yet it still works from NativeScript 5 all the way up to 8.3. We’ve had several special requests to add things here/there to it in the past 4 years for older projects which we are happy to help with but we don’t actively think about it nor do we need to.

Around the end of 2019, it was decided that focusing solely on v8 as the runtime implementation would be the best to "maintain" since it would align the iOS and Android runtimes with the same v8 implementation and technically, is easier to maintain than it's JavaScriptCore implementation.

What do I mean by "Conveniences"?

A convenience is something which is not necessarily needed for something to work. NativeScript works without core, the CLI or any plugins.

Core, CLI and plugins (B) are purely conveniences which allow you to use the runtimes (A) in a generally expected JavaScript ecosystem way.

Fundamentally, A is NativeScript.

TSC member Eduardo Speroni gave a talk on this at OpenJS World in 2022 where he discusses using NativeScript without @nativescript/core altogether, effectively using just the runtimes to do pure platform development: https://www.youtube.com/watch?v=iweVLGNzx1A

Conveniences are where Community falls in love or hates your guts

I'll be the first to tell you I have had a love/hate relationship with NativeScript going back to 2014. I loved it for what it is, I disliked it for what it wasn't.

If there's anything "New" NativeScript creates, it's from what Core provides.

Most rants I have heard over the years (including mine) around NativeScript revolve around the purported "conveniences" (B) provided. NativeScript core (historically tns-core-modules and now simply @nativescript/core) is one interpretation of how to work with the runtimes and it's had a colorful existence.

Conveniences are often the territory of developer experience (DX). For every complaint you may have about any open source, there's either a formalized process to help or it's just a matter of discussion with the right people. NativeScript now has a standard process to change it through RFCs (Request for Comments) and here's an example of a long community complaint where I am following the same process anyone can to help ensure it's addressed appropriately:

• RFC to scope platform API types: https://github.com/NativeScript/rfcs/blob/6b59047eea32928d5f2d5e327e7093a5814d5215/active-rfcs/0000-scope-platform-apis.md

Maintaining NativeScript core

Maintaining NativeScript core is like maintaining any TypeScript library. In particular, it's maintenance revolves largely around:

• TypeScript/JavaScript evolution
• Platform runtime (A) implementations of NativeScript
• Bundlers, such as webpack
• Jest unit tests and some e2e automated tests

Maintaining TypeScript/JavaScript evolution is easy frankly, thanks to Nx which provides helpful migrations to various config settings to alleviate a lot of manual maintenance. TypeScript makes for easy and powerful refactoring so it's quite a joy in this department.

Platform runtime implementations are pretty good and our team certainly knows how to work with it professionally to achieve ideal results. However, @nativescript/core is where the most interesting things are likely to occur over the next 3-5 years. There's simply a lot of ways to do what core is doing in scope of what the NativeScript runtimes (A) provide.

Bundlers, which currently webpack v5 is used, are now easier than ever, thanks to TSC contributing member, Igor Randjelovic. He pioneered an absolutely brilliant webpack v5 setup for all of NativeScript which had historically been a huge pain point. It will serve to simplify bundling approaches for years around NativeScript.

NativeScript core is also where a lot of the historical "cross-platform" messaging comes from. The mere implication of "cross-platform" often implies a general expectation of how to deal with many platforms from a singular point of view. Core does this by providing singular view primitives which represent all the common iOS and Android view constructs most applications need while also providing enumerable utilities. This is also where a lot of direct comparisons to other cross platform approaches arise.

Publishing updates across all NativeScript packages within the organization is streamlined to be executed by any active TSC member or automated via Github Action Workflows in a consistent and efficient way:

npx nx run core:build
cd dist/packages/core
npm publish

Maintaining Flavor Integrations?

This is a tasty one where a lot of lively discussions have emerged on Discord in 2022 in particular.

We're talking of course of the colorful JavaScript ecosystem where Angular, Qwik, React, Solid, Svelte and Vue, et al., dominate the air waves.

Flavor integrations are often driven by real business needs and community involvement. Very simply, if you are a JavaScript framework vendor and want to use a NativeScript implementation, just ask and we will help provide pointers if not become involved directly. See @nativescript-community/solidjs as an example.

Simply put, the more DOM-like NativeScript core becomes, the simpler maintaining of flavor integrations become, potentially removing a maintenance point altogether.

Core's DOM escapades are akin to server side rendering in the sense that several SSR solutions like domino, which aims to provide a DOM in Node, help to simplify the ability to do server side rendering easier amid varied conditions.

Historically, NativeScript core somewhat naturally diverged into it's own path of innovation and currently the TSC is actively involved in pairing that down to align it back closer to JavaScript API standards. In particular a goal of 2023 is to align with WinterCG goals.

Just like with core, any flavor integration update can be executed by any active TSC member or automated via Github Action Workflows in a consistent and efficient way, eg. for Angular:

npx nx run angular:build
cd dist/packages/angular
npm publish

Project Templates

We maintain a few helpful project templates as a convenience which can be invoked via the NativeScript CLI as follows:

ns create myCoolApp --angular // or --ng for short
ns create myCoolApp --vue
ns create myCoolApp --vue --ts // for vue with typescript
ns create myCoolApp --react
ns create myCoolApp --js
ns create myCoolApp --svelte

The maintenance of such were also vastly simplified with the introduction of Nx to manage them: https://github.com/NativeScript/nativescript-app-templates

These are easy to maintain. Largely package.json version bumps and consistent tsconfig setup updates.

Plugins

Historically in the JavaScript cross platform space at least, plugins have often provided a drop in to a platform feature or SDK which often must be implemented by a platform engineer and then a layer exposed for you to use in your JavaScript project.

NativeScript does the same with plugins however since it gives you the platform in JavaScript, the likelihood you could create a plugin yourself without having to enter the fine art of Xcode or Android Studio is higher...right?

Yes. In fact I am a prime example of this myself. Here's the Ionic Portals Android SDK I implemented in NativeScript without ever writing a line of Java, Kotlin or opening Android Studio:

• Ionic Portals for Android with NativeScript

And here's the Ionic Portals iOS SDK I implemented in NativeScript without ever stepping one foot into Xcode:

• Ionic Portals for iOS with NativeScript

I have become a better platform engineer by using NativeScript.

Plugins are always a revolving discussion in software, particularly around frontend implementations.

• The NativeScript TSC maintains several commonly needed plugins here: https://github.com/NativeScript/plugins/tree/main/packages
• The NativeScript Community provides a wide array of plugins here: https://github.com/orgs/nativescript-community/repositories
• You can use React Native plugins with NativeScript by using Open Native: https://github.com/OpenNative/open-native#introducing-open-native-native-modules-for-all

For me personally, I create plugins as needed by professional clients.

Maintaining plugins are made efficient by plugin workspaces powered by tooling the TSC manages which auto migrates them.

The Hidden Benefit of NativeScript regarding Plugins

1. Install a plugin
2. Find it solves 90% of your case
3. How to handle the other 10%?

Ordinarily this can become quite troublesome in practice. With NativeScript, because the natural platform is provided to you in JavaScript, you can often resolve the final 10% with a wide array of options at your disposal which ordinarily might involve a lot more time to resolve.

Documentation

Without question it’s hard to do right. It’s even harder to do when you didn’t write it originally.

Right now, the NativeScript docs are undergoing a major overhauling in this repo: https://github.com/NativeScript/docs/pulls which contains over 70 pull requests already.

An open source detour...who the hell am I?

I am purely a fan of NativeScript and one of many around open source whom have witnessed first hand the many misunderstandings that come with open source in general.

1. We are lucky to have open source at all.
2. If you are using open source, it is within the natural good natured human spirit to be involved if you are able.
3. To attack open source of any form, is to scream at an imaginary wall.
4. Open source can exist in many forms, be it corporate sponsored, community driven, or simply exist for the fun of it.

For an open source project to be community driven at all means it can be, there's many that are willing to do so, and a community that wants it (no matter the size). When the project is large enough, as is the case with NativeScript, this fact alone is astounding and stands out within the scope of any market conditions.

I have a lovely family, demanding wife, and 2 children (one is 4 and the other is 23). I want to help with NativeScript anytime because:

• I enjoy it
• Have seen first hand it's effectiveness for large enterprise, small business and startup environments as well as experience wonderful results with it daily
• It follows the 'less is more' mantra which benefits the broader community well into the future
• The level of innovation and creativity around NativeScript is at an all time high right now with a ton of exciting areas still yet to be explored

I have also seen it be misused, misunderstood and abused many times as all open source can be subject to.

Economics and Jobs

My father received an undergraduate degree in Economics from Middle Tennessee State University and a Masters in Business from the University of Tennessee. He's a diversified chicken, hog, and cattle rancher today. I was raised in a family that was centered around practical economics, a special care for jobs, entrepreneurship and why it matters on a very human level.

I went on to study Business Marketing at Valdosta State University in Southern Georgia while minoring in Art. I began a career in programming while interning during my undergraduate studies.

JavaScript has provided the tech industry a breathtaking amount of jobs, resulting in rewarding careers, happy families, and inspiring creative innovation.

I am attracted to NativeScript in part because of it's potential to help support a diversified job market where more ideas are given life to support different perspectives. What NativeScript encourages is a fundamental understanding to language and through that understanding an appreciation and enjoyment of those perspectives.

But there are no NativeScript jobs?

A JavaScript job is actually a NativeScript job.

At the same time, a SwiftUI, Jetpack Compose or purely web job is a NativeScript job.

Detailing how to effectively apply NativeScript to enhance your codebase while helping to strengthen a diversified and healthy job market is a topic that needs more work. It's a topic myself and colleagues at nStudio are keenly focused on and we'll continue to help share real world case studies to educate how your teams can get the most from it.

For me personally, I would prefer a job market where NativeScript doesn't need to be mentioned. If it achieves what it's sole purpose is, which is to lift up and expand the versatility of JavaScript, it doesn't even need to be mentioned. There are many viewpoints on this but that's mine.

Why NativeScript when React Native dominates?

NativeScript and React Native aren't competing approaches, contrary to much misinformation.

Simply put, NativeScript is here for the entire JavaScript ecosystem including React Native.

You can now use React Native plugins within NativeScript projects through the Open Native effort and it's only a matter of time before NativeScript can be used where the React Native community sees fit.

In reality they don't compete but it's easy to think they do because of some surface level appearances. Dig deeper and you'll find they are mutually beneficial to one another.

We could implement NativeScript with Hermes for example.

Market Trends, Uncertainty and AI

If we all went where the wind blew we would all end up in the same place right?

Market trends have a tendency to follow...well...marketing.

If you have found NativeScript to be useful, you are using it correctly.
If you have found NativeScript to not be useful, you are using it correctly.

The existence of NativeScript is not one which is dependent on numbers. It depends on how much the industry wants JavaScript to be versatile and useful in broadly diverse use cases.

JavaScript is not going anywhere, thus NativeScript is not either.

Regarding AI, particularly in 2022 it has given the industry a wake up call. AI will always be as good as it's trained inputs. If everyone goes where the wind blows, you will certainly help AI get unified input and thus eradicate your job quicker.

The more diversified the job market, the better AI can help work alongside teams with more granular input to be productive without creating a single artificial mind.

If you wanna outsmart the machine, do the one thing it cannot -> Be human, with compassion for other perspectives that may not always make sense on the surface. What works for the machine may not work for the human.

"Avoid the hive mind." ~spoken through a retro 60s Echoplex

Always understand before using. Help is always near.

Grabbing the hottest thing off the shelf and going it alone, albeit exciting, like with anything is not recommended in a time sensitive or mission critical situation.

NativeScript has been around for getting close to 10 years now. It drives large enterprise developments along with small businesses and it's evolved. We've been working around it professionally for the better part of 6 of those years and have seen teams go it alone without even reaching out to the community. Please don't do that to yourself or your company.

The NativeScript community is a thoughtful, diligent and compassionate group. If you need help, there are also professional partners to assist.

Is NativeScript Anti-Web Development?

This is a surface level thought that makes sense. NativeScript can be used to create purely native platform projects which are not the web so doesn't it hurt the web?

In practice, what NativeScript enables is "best of web with best of native" meaning it encourages first class web experiences via it's JavaScript versatility while being able to enrich that approach with best practices from native platform developments.

How you go about using it for that purpose is left to the innovators, developers and creators out there — remember that job thing I mentioned? Go create, go innovate, inspire us all!.

We will certainly share more of our own practices which champion best of both in the future to illustrate this often obscured reality.

What real advantages does NativeScript enable and what does it mean long term?

NativeScript is a celebration of platforms in the language you love, JavaScript. This means you can use anything on that platform, for example:

• Opt in SwiftUI? You can
• Opt in Flutter UI? You can
• Opt in Jetpack Compose? You can
• Use React Native plugin ecosystem? You can
• Opt in Web microfrontends? You can
• Opt in some future innovation? If it runs on a supported platform, absolutely.

Yes, you can use Vue with SwiftUI.
Yes, you can use Angular (TypeScript) to drive Flutter UI.
Yes, you can use Svelte with Jetpack Compose.
Yes, you can use Solid with React Native plugins.
Yes, because of NativeScript.

Never before could you write an Objective C, Swift, Java or Kotlin API within the scope of a JavaScript project, in a web browser, and have that code executed on a real remote device instantaneously but yet NativeScript enables this.

Supporting tech diversity, championing different perspectives, and celebrating a wide array of background qualifications rather than demanding only one is what this technology is all about and in the long run we hope will encourage a more colorful job market with broader opportunities.

The versatility and possibilities of NativeScript are in one word...inspiring.

Enjoy open source

Cheers to your open source journey 🍻

Credits

• The lively NativeScript Community
• The continued brilliance, heart, and humble insight of the entire TSC representing nationalities across the globe such as France, Hungary, Bulgaria, Japan, Indonesia, Ireland, Greece, Brazil, New Zealand, Trinidad & Tobago, Canada, and numerous states across the United States.
• Cover art generated by DALL·E. ~ "An excitable frequency existing between a mountainous void, digital art."