Why you should NOT use NativeScript
csimpi.medium.com
csimpi.medium.com
It is marketed as a holy grail for mobile development, but it is very, very immature. It should be considered an experimental technology.
Why do I say that? It has a severe lack of features and a high bug count.
It claims to support CSS but in fact it only supports about 10% of what CSS can do in the browser.
It also has an insanely huge backlog of bugs, which you can see for yourself on GitHub. I filed a bug report for what is a fatal flaw IMO: you can't write unit tests against async code. The dev team acknowledged it is a problem and yet it has collected dust for a year. No serious business should use a tool that doesn't allow you to write unit tests. https://github.com/NativeScript/nativescript-angular/issues/...
I will say that open-source is a good thing to do and that they are not solving an easy problem - developing native mobile apps with multiple JS frameworks like Angular and Vue. Good on them for the effort. On top of that, there is definitely a market need for an Angular / Vue / JS to native app library for people that don't want to use React-Native for whatever reason.
However, with that said...marketing their software as production ready, easy-to-use, and working out of the box while it being the exact opposite is harmful to the companies and developers that sink serious time and effort into building with NS. There needs to be more awareness like this blog post about how people should stay away from NS because of the issues mentioned. That is not being negative - it is being ethical and doing the right thing for the companies and developers that would end up having broken apps and serious sunken costs into platform that doesn't live up to what it says it does.
I have many Github issues that were acknowledged as bugs but never addressed or fixed. I even offered a workaround that people are probably still using to this day because they never fixed certain bugs and docs. I haven't really interacted with the NS people too much besides on a few issues that weren't answered, so I can't comment on their attitude, but I can attest that everything else the OP is saying is true about NS not being a good solution.
NS isn't soo terrible where nothing ever works. I believe the apps I worked on are still running in production. But, I'll put it this way - everyone learned from the experience that using NS is definitely not a good idea to use for developing mobile apps.
I stuck my nose into NativeScript years ago and turned right around because of the disconcertingly large gap between the slick experience promised by the project web site and the rough edges reported by people trying to use it.
Presenting your project as a polished solution when it still has a ton of rough edges is not a social norm, an emotional necessity, a human right, a signal of scrappy ambition, or "just what people do." It's a deception that can cause harm. Normally people are not within their rights to demand solutions from open-source projects, but it's fair to ask them to live up to their marketing. They could fix this by rewriting their marketing to better reflect the state of the project, so they attract the right users for the current level of maturity.
NativeScript was born after forking Appcelerator Titanium’s Hyperloop project, which was meant to create direct bridge between native APIs and the JavaScript runtime.
At the time the fork happened just when Appcelerator made Hyperloop development private since it was facing more or less the same anger from the community that we see in this article and could not keep the promises that hyperloop was meant to fulfull. (This reminds me a lot the current situation with React Suspense)
The idea in the community was more or less “those bullies from telerik think they can fork it and finish it before us, they will never complete it” and indeed they faced a lot of the problems that was delaying the release of hyperloop itself.
At the end of the day the embraced Angular as a React Native killer (React Native more or less killed the competition for bridged native app frameworks IMHO) but never reached the quality required… wait for it… for a commoditizied framework. That’s the problem: no one will ever pay for a framework which competes with free (if proprietary and not compatible) native frameworks.
(Fun enough, Titanium SDK is actually incredibly solid right now, still following every native SDK release with only some weeks of delay)
https://en.wikipedia.org/wiki/Appcelerator_Titanium#History
Work on NativeScript began in 2014 with first public release in March 2015.
Also I made [some macros (Sweet.js) for Hyperloop][2] once the first alpha was released. Last commit is september 2014.
[1]: https://github.com/appcelerator/hyperloop-examples/commit/28...
It is only after that i discover the fact that i could use Vue and now Svelte
He surrounded in quotes: "We are working on NS for 6 years, how dare you tell something is wrong?" and that seems suspiciously like a paraphrase on his part. I doubt it is a direct quote but rather a way the author wants to describe how he felt over the course of several exchanges.
One of the other supposed quotes, "You are too negative, I can’t help", is a bit more telling.
His other criticisms aside, I actually have no problem with open source support channels (or any support channels really) excluding toxic negativity. Some people seem to assume that complaining is the same as contributing. If the only thing you bring to the table are your complaints then don't be surprised if you get excluded.
That said, I got the exact same impression from his paraphrased statements. His paraphrases did seem revealing, like he had approached this with a bad and demanding attitude, and it went about as well as you'd expect. So, maybe room for improvement on all sides lol
They are free to ignore him in support channels.
He is free to strongly recommend avoiding the product.
---
Having spent a few hours reading through their docs when I was comparing flutter to NS, I have to say I agree with most of his points. It's mostly the equivalent of autodocs, with no conceptual foundation or guiding principles about how to use the system.
I hit their site again today and I have to say, I'm pretty confused by their support page - https://nativescript.org/support
They claim to be OSS, but they offer a form that appears to be equivalent to paid support, and mention "business personnel" whatever that means...
So if I went in blind and assumed I could get support (paid - of course), and it turns out I can't, and there's little community support to boot... I'd be a little negative too.
Why not use Java/Kotlin if its just on android? Flutter has its advantages sure, but from my experience developing with flutter is the apps end up a bit slower than native, and often you end up interacting with the Java ecosystem on android anyway so the experience doesn't end up being that much better.
So if Ads, Pay and Search keep their support, Dart and Flutter are here to stay.
So my read of Flutter is it’s a way for talent to “ship and get promoted” inside Google or to support other Google product teams. Everyone else is a secondary priority.
“the Ads team at Google” is a very strange thing to treat as equivalent to “no one”.
Also, I'd be curious to hear what major advantages Kotlin would have for Flutter. The Flutter team has commented heavily on Dart's useful properties for Flutter's goals (small comment here, there are well written full articles as well: flutter.dev/docs/resources/faq#why-did-flutter-choose-to-use-dart).
The internal investment in Flutter is well beyond the average tech project at Google. I don't expect it to be abandoned any time soon.
Keeping up to date native Android/iOS functionality by basically reimplementing it bugs and all is an endless demanding work requiring strong talent that will never be good enough for all your use cases and will churn anyone who works on it both from the work itself and the constant complaints of the community.
No other programming powerhouse would be willing to partake in this or even be able to keep up - you won't see an AirBnB, Microsoft or Wix commitment like you did with React-Native, where these companies were active contributors to the core and have low-level libraries of their own.
Google is the last company I'll put my money for doing long term maintenance on an open source project, let alone one with no prospect for monetization or search market-share.
There's really only one way that Flutter survives - and that's if somehow Android moves to it as a first class citizen.
This is immensely unlikely. And probably will doom Android. And in the impossible case where it will - it means iOS will become second citizen.
Google has said the same thing for tons of things, and then stop caring for them and supporting them.
Including Dart as a JS alternative, the very same technology now relegated to Flutter backend.
I would think long and hard before betting my company on any Google product.
Are there many third-party contributors to flutter? If so, that would make me feel a little more confident. If it's all (or almost all) Google staff, yeah... no. Wouldn't go there.
https://ubuntu.com/blog/flutter-and-ubuntu-so-far
tidbit - there is early support to build linux flutter apps on the raspberry pi. Would be good if android team offered arm builds of their tools, then it would be possible to build for android on the pi.
- It's multi-framework (Vue, Angular, React or Svelte); easy to pick up for web devs
- The per-framework implementations are fairly similar to the web-variants (except it uses NS component tags vs HTML tags)
- UI abstraction layer that maps the NS components to real native UI components for iOS/Android (instead of Flutter's gimmicky pixel-by-pixel OS element duplication ala Adobe Flex)
- Use of native UI elements lead to performant UI elements (recyclerviews, tabs etc). React Native plugin devs had to tediously re-create elements like the recyclerview with custom logic (see 'RecyclerListView'). The core team adds new UI elements fairly quickly after OS releases, as they only have to create the bridging code
- Out-of-the-box code bridging; access native methods/variables on iOS/Android from JS. E.g. accessing the Android notch API can be done with a few lines of JS
- Recognizable CSS elements for styling (margin, borders, gradients, box-shadow)
- Performant; fairly quick cold-boot and no iOS shader-cache jank like with Flutter. OP likely has a web-dev background and used too many nested views leading to jank (as it would with a native app).
The struggles:
- Inconsistent maintenance of (semi-)official plugins like background uploading and toasts. Hard agree with OP.
- Overuse of outdated, third-party Cocoapods/Gradle plugins for their plugins. Some Cocaopods they use don't even have iCloud support.
- Large backlog of Core issues/bugs
- No more Sidekick (The 'Expo' equivalent for NS), as it wasn't part of the acquisition. This tool was really handy for low-barrier deployments/boilerplate code rollout
But the real problem is adaptation. No large adaptation = no big sponsors = no full-time development. Earlier it was in hands of Progress which had a highly talented team from Bulgaria working on it full-time. Progress tried to use NativeScript as an on-boarding strategy to get people to use Kinvey. When Progress pulled the plug, a small development agency took over development and is struggling to find the manpower to maintain this colossal project. I hope they will manage to make it work as NativeScript does have unique qualities.
As you mentioned, NS has all the substance it needs but like any framework has some rough edges. What NS lacks is the PR army like the one flutter has.
It appears that they should have recognised very early that LiveScript didn’t work for them, yet they persisted for 2 years. Persistence is a virtue when you are on a successful path, but it is a negative trait if you are following the wrong path.
Good developers short-circuit early on bad technology, and change tech. Great developers pick a productive technology to begin with, and usually milk it for a long time.
I'm still betting on React Native for cross platform development.
It's productive, decently stable, well documented and very good web support with React Native Web. Updating stuff can be incredibly painful, but that's just a couple of days of suffering every now and then. If Microsoft continues React Native Windows & Mac OS it will be quite cool.
Flutter is a very interesting idea and I hope it will become a decent option for the native side of things, but the web story... reminds me a bit of Flash: very easy to build "cool" stuff but with tons of issues. Also not sure about Dart and I don't really trust Google to keep supporting it. I also feel there is a gap between the marketing and the current reality. Let's see, if they manage to fix the web and other issues it could be really awesome.
First, a mantra that I see repeated on Hacker News posts, is "pick boring technology." I don't understand why they kept with NativeScript so long with all of it's problems; and I don't understand why they didn't learn their lesson and just do a boring (but reliable) Java app.
But more importantly, why did the author stay so long in that job? I've been in a situation where I was forced to work in ^$#%^ stacks, and I left for a different job. Life is too short to waste time in a job like the author describes.
Finally: It's so important to "fail fast" with technology. There are so many tools, frameworks, kits, that just don't live up to their promises.
All the issues that are brought up the article could have been avoided by doing a simple proof of concept demo.
We are about to rebuild our Android app in Flutter
Spend a week doing a proof of concept first, so we don't have to read this in six months time.
1) The official demo apps were slow and janky. (hmm, reminds me of Flutter. I don't think these guys will be much happier with Flutter, honestly)
2) It was made by Telerik, the company known for bloated and slow ASP.NET controls. Also, surprise surprise, poor documentation.
Eventually, I decided to make 2 separate iOS and Android apps.
The Flutter web demos are slow and janky on some devices and browsers due to depending on WASM, which isn't universally suppported yet. Mobile Flutter apps are sometimes slow ( e.g. the new Google Pay), but they have no obvious excuse to be ( UI in Flutter is really fast, 60fps all that).
Living with the warts is sometimes worth it, if you need to get to mark in a few months and have no mobile dev experience, it's worth using one of these frameworks.
Then start learning the native landscape and building out what needs to be done. After a few years for most app it would feel like as if it would have been easier to go native all along, but the reality is that if you did, you would be much behind.
Freudian slip? /s
I wonder if we'll see any indie titles use it in the coming years. I certainly find it pleasant enough to play around with.
> 2. Documentation is ridiculous > They are behind with the docs for years. They always promise that the next version’s documentation will be really finished and will be awesome and contain everything.
So what? That's your responsibility to start a project with an open source framework that doesn't even have a proper documentation, you're completely free to not to use or if it is bothering you, help them.
> 4. Arrogant communication > Go to their Slack channel and ask them about anything I mention above. They’ll cut you out with some trendy BS like: > "You are too negative, I can’t help”
I can clearly see the reason why.
> 5. There’s no support at all
Yeah, i'm pretty sure that's how not open source works.
1. I agree about the "you're free not to use it" line, but I frequently find that documentation can seem comprehensive when you're evaluating something, but as soon as you get deeper into the weeds, that's when the shortcomings reveal themselves. And telling someone to "help them" when they themselves are looking for documentation to get help? That's just laughable. I sure as heck wouldn't want someone who can't get my product to work to be submitting documentation PRs.
2. This is just snide. Refusing to help someone because they're expressing frustration is simply spiteful. You have no more information than the rest of us about what was actually asked, so implying that the author "had it coming" seems uncalled for.
3. Then you're not very familiar with the OSS economy, are you? There are frequently paid support plans available for major OSS projects.
I'm telling exactly the same thing, if you are not comfortable with reading the source code to understand something, then you shouldn't be starting with a project that doesn't even have a documentation.
> 3. Then you're not very familiar with the OSS economy, are you? There are frequently paid support plans available for major OSS projects.
This is not right, you are talking about mainstream projects, except from people getting paid to contribute open source (like people working on Kubernetes, Firecracker, Gvisor, Bottlerocket, Podman, Red Hat's stuff, Linux Foundation etc), they are doing "free work".
Yes, author is completely free to do whatever criticism they want, but for a project that doesn't even have 2 donators, author has a too offensive language and basically expecting too much.
It’s been two years since our company decided we’ll pick NativeScript to create and maintain our Android App. This was the biggest mistake our rapidly growing company made in the last 4 years. We are about to rebuild our Android app in Flutter from scratch now…
2023: Why you should NOT use Flutter
It’s been two years since our company decided we’ll pick Flutter to create and maintain our Android App. This was the second-biggest mistake our rapidly growing company made in the last 6 years. We are about to rebuild our Android app in Kotlin from scratch now…
It’s been two years since our company decided we’ll pick Kotlin to create and maintain our Android App. This was the third-biggest mistake our now nearly-defunct company made in the last 8 years. We are about to rebuild our Android app in Java from scratch now…
Probably you should go with java/kotlin instead of flutter/dart.
2013 called. It wants it's opinion back.
Then they proceed adding platform dependent code for their vanity projects like Fuchsia along side their other platform dependent code for not vanity projects like ChromeOS and Android.
IMO Dart is only alive because of Flutter, outside of it, it's dead.
https://devblogs.microsoft.com/surface-duo/flutter-dual-scre...
Shipping phones with Fuchsia (which as I understand will support Flutter apps) would also help.
Dart has evolved significantly over the last few years, and Google is very serious about Flutter.
I personally enjoyed NativeScript when I used it a couple of years ago but, then again, I really was only using it for building prototypes.
Tbh when you get used to those quirks NS can work pretty well.
But to be honest i think that a big part of Nativescript's future will be related to that new ionic integration. Having real web apps with native API access from JS should be awesome.