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
NativeScript open source can be reduced to three primary facets, A, B and C.
A. Platform runtimes
Packaged and distributed on npm as:
Optional packages which represent one (of many) ways to work with the runtimes:
- nativescript (“ns” for short: a node command-line interface, aka CLI)
- flavor integrations (Angular, Vue, React, Svelte, Solid)
- project templates
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.
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?
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.
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:
Maintaining NativeScript core
Maintaining NativeScript core is like maintaining any TypeScript library. In particular, it’s maintenance revolves largely around:
- Platform runtime (A) implementations of NativeScript
- Bundlers, such as webpack
- Jest unit tests and some e2e automated tests
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
Maintaining Flavor Integrations?
This is a tasty one where a lot of lively discussions have emerged on Discord in 2022 in particular.
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.
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
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.
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:
And here’s the Ionic Portals iOS SDK I implemented in NativeScript without ever stepping one foot into Xcode:
I have become a better platform engineer by using NativeScript.
Plugins are always a revolving discussion in software, particularly around frontend implementations.
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
- Install a plugin
- Find it solves 90% of your case
- How to handle the other 10%?
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.
- We are lucky to have open source at all.
- If you are using open source, it is within the natural good natured human spirit to be involved if you are able.
- To attack open source of any form, is to scream at an imaginary wall.
- 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.
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?
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.
Why NativeScript when React Native dominates?
NativeScript and React Native aren’t competing approaches, contrary to much misinformation.
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.
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?
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?
- 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.
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 🍻
- 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.”