Why you should NOT use NativeScript(csimpi.medium.com)
csimpi.medium.com
Why you should NOT use NativeScript
https://csimpi.medium.com/why-you-should-not-use-nativescript-76e1348a7cb4
80 comments
I have been maintaining a fork of Titanium (because Appcelerator did not want to merge any of my PRs) and writing tens of apps in Titanium for 7 years.
It is indeed a really strong framework.
However 3 years ago i decided to switch to Nativescript for multiple reasons:
* performances in Nativescript were way better when you were talking about listview and such components. The proxy system of Titanium makes it pretty heavy and REALLY hard to maintain
* developing plugins or maintaining Titanium is a thousand times harder. You have to write all in Objc/Java and it is really hard to do live dev/debugging for the native side.
* (3 years ago at least) gradle support was really weak and it was really hard to integrate native libs
It is only after that i discover the fact that i could use Vue and now Svelte
It is only after that i discover the fact that i could use Vue and now Svelte
"The latest addition to the platform in 2016 has been Hyperloop, a technology to access native API's on iOS, Android and Windows with JavaScript."
https://en.wikipedia.org/wiki/Appcelerator_Titanium#History
Work on NativeScript began in 2014 with first public release in March 2015.
https://en.wikipedia.org/wiki/NativeScript
https://en.wikipedia.org/wiki/Appcelerator_Titanium#History
Work on NativeScript began in 2014 with first public release in March 2015.
https://en.wikipedia.org/wiki/NativeScript
Not correct. Work started way earlier. See [this commit][1] from the Appcelerator CEO which creates the first hyperloop examples repo. And that repo was created because the community wanted to try hyperloop, which was already available but very alpha.
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...
[2]: https://github.com/yuchi/hyperloop-macros
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...
[2]: https://github.com/yuchi/hyperloop-macros
Very interesting. I maintain several Titanium projects and I have to agree it seems to have chosen the best paths for basic to intermediate cross platform App development and the recent release to full open source has me excited for its future.
> We are about to rebuild our Android app in Flutter from scratch now…
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.
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.
It's still in Beta, but Jetpack Compose is really nice to work with IMO. If you have a real excuse for a greenfield rewrite, I'd give it a good look, especially if you can afford to wait at least a year before releasing for stuff like a11y to improve.
The message I'm getting from Google is that flutter is the future and will get more support eventually. You can also see it in their fuchsia os which is heavily focused on the ecosystem.
I'd be surprised if this actually materializes. Most likely google will abandon the project (whether by killing it or just moving all the talent to something else.
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.
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.
What do you mean by "and that's if somehow Android moves to it as a first class citizen."?
Google always has two projects that cover “the future” - one is undocumented and the other was just deprecated.
There is absolutely no way flutter unseats java/kotlin unless it abandons dart and adopts kotlin as its language. Its much more likely that flutter gets absorbed in some way by the android ecosystem.
Jetpack Compose was definitely a counter attack from Android team, with Ads being a big Flutter sponsor and the only reason Dart did not die when Chrome withdraw their support.
So if Ads, Pay and Search keep their support, Dart and Flutter are here to stay.
So if Ads, Pay and Search keep their support, Dart and Flutter are here to stay.
Just to understand this correctly, are you talking about internal debates at google? Like the different teams embracing different technologies for building apps?
Yes, Flutter is “sponsored” by other money making teams inside Google. It is why resources have been spent on Flutter for Web, which no one asked for - the Ads team essentially bought the feature for their usage. This was also how React Native got its start in Facebook.
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.
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.
> It is why resources have been spent on Flutter for Web, which no one asked for - the Ads team essentially bought the feature for their usage.
“the Ads team at Google” is a very strange thing to treat as equivalent to “no one”.
“the Ads team at Google” is a very strange thing to treat as equivalent to “no one”.
I don't see how it would make any sense whatsoever for Flutter to be "absorbed" by Android, it is entirely independent.
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.
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.
From the FAQ “the LICENSE file is 54.3 KB (compressed)” - that is pretty large amount of uncompressed text! I couldn’t find the full licence file (presumably containing all the licences of library dependencies).
+1 to the dart part.
Flutter does away with all the idiosyncrasies of the many Android APIs that differences between Dart and Kotlin seem relatively superficial.
>The message I'm getting from Google is that flutter is the future and will get more support eventually.
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.
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.
Right. Google has a long history of scrapping major projects the moment it becomes convenient, even products that have millions of active users (Reader, Wave, Plus....).
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.
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.
Ubuntu is doing work on desktop flutter, I recall hearing that they are working on hooking up flutter to accessibility bit of ubuntu.
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.
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.
I still miss Google Inbox, such a great product. They just killed it for no good reason. Really sad.
I do wish the technical criticisms and the social criticisms were separated out a bit more. The social aspects of this article heavily imply there's another side to the story.
I added my lot in as a response.
Having spent a few months at work attempting to build an application in NativeScript, my advice to others is don't touch it with a ten-foot pole.
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/...
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/...
This were exactly my points when I considered using it a few months ago. Much less mature than the alternatives yet offering no selling point that would make it up for me for using alpha-quality software. If they announced it 10 years ago, I would have used it for toy projects just for fun, but these days I just want to build stuff that works, and if it has bugs, I prefer them to be mine.
This post is on point. I spent a good amount of time working on multiple NativeScript apps (NS with Angular and NS with Vue) and can attest that the documentation is not good enough and that there are serious bugs that are pointed out and never fixed or addressed.
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 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.
> marketing their software as production ready, easy-to-use, and working out of the box while it being the exact opposite
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.
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.
Totally agree.
I can't comment on NativeScript as a technology. However, I would like to comment on the issue of his treatment in support channels.
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.
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.
IMHO the most important thing that a framework can have is complete documentation and SLOW, deliberate release cycles, while this sounds like it's the opposite on both counts. Anyone can make a framework, the real value is in the documentation and release cycle.
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
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
I agree with you, but this sword cuts both ways -
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.
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.
biggest advantage of flutter is the amount of time/energy spent in marketing flutter itself. dart is given up by google engineers long time ago. There were time where small amount of ads front end written in angular dart (like 10 pages across 4 applications) and those pages replaced with angular/typescript.
Probably you should go with java/kotlin instead of flutter/dart.
Probably you should go with java/kotlin instead of flutter/dart.
This is simply false. Dart/Flutter is very actively being used at Google by dozens of teams.
> dart is given up by google engineers long time ago
2013 called. It wants it's opinion back.
2013 called. It wants it's opinion back.
Let's see. They don't approve for other platform because "they want dartvm to be cross-platform and not hold too much platform dependent code"
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.
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.
If Microsoft's interest in Flutter becomes more substantial, it might diminish the perception it's one of those projects Google could abandon on a whim.
https://devblogs.microsoft.com/surface-duo/flutter-dual-scre...
Shipping phones with Fuchsia (which as I understand will support Flutter apps) would also help.
https://devblogs.microsoft.com/surface-duo/flutter-dual-scre...
Shipping phones with Fuchsia (which as I understand will support Flutter apps) would also help.
I have my hesitations and critiques about Dart and Flutter, but this is flat out wrong.
Dart has evolved significantly over the last few years, and Google is very serious about Flutter.
Dart has evolved significantly over the last few years, and Google is very serious about Flutter.
2021: Why you should NOT use NativeScript
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 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…
Now do 2025 :D
2025: Why you should NOT use Kotlin
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…
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…
Well, as the ancient legend goes: Over 3 Billion devices do run Java
The kicker is that all the different iterations of the code ran just fine, the problem was that the product was shit all along.
“We didn’t touch the app for a year and after we upgraded to Gradle 13, everything went to hell”?
The hip, shiny framework/project that everyone is going to jump to in 2025 has yet to be written.
Don't know much about nativescript, but picked up flutter 3 weeks back and am almost finished writing my first flutter app just coding during my free time. Feels great coding in it and seems well thought out. Just my 2 cents
I've heard great things about Flutter, and Flutter 2 sounds very interesting. However, I don't trust Google not to get bored and change directions, and so I won't invest my time until Flutter is strategically important to their business.
I had this conversation with a support engineer for Google Cloud one time. I mentioned that Google has a long history of dumping products that people rely on and he got really annoyed, as if that wasn't true. I don't know if they fully appreciate that they have a reputation for this.
Hard to want to believe something if it means nobody will care about your work no matter how good it is for reasons out of your control.
That's a good call, although if it becomes widely used outside of google, won't it be possible for a community to just fork it when google loses interest?
You mean like AngularJS (which is an entirely different framework then modern angular)
Hahaha, that was before my time, so no idea. But I was just guessing based on flutter being open source. Guess taking over a huge codebase from an entirely different team who was being paid for it full time isn't feasible even in the slightest?
After been bitten by Google’s “graveware” one time to many I don’t invest heavily into their ecosystems anymore. And in my experience the projects are either abandoned or fizzling into obscurity once Google pulls the plug even if an open source community could technically fork it and take over. But in reality usually people rather go on the next shiny thing instead.
I don't know enough about NativeScript to comment but Flutter is a great platform, I'd pick it up over native any day.
The proof is in the pudding and the Flutter pudding is pretty tasty from everything I've been reading. Not just for toys but for a vast number of launched applications written using that platform.
If you want to use javascript/typescript angular for hybrid development use ionicframework. It has it's warts too like all things, but it's much more mature than NativeScript.
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.
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.
> get to mark
Freudian slip? /s
Freudian slip? /s
This was the biggest mistake
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.
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.
You don't even need to do that! 6 years ago, I was exploring cross-platform mobile options (RN wasn't available for Android yet, also it was brand new and not to be trusted. It turned out OK in the end though.) and Native Script was one of the options I looked at. A couple things instantly made me reject it.
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.
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 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
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).
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).
Thank you, you're right. That's an important detail. I haven't tried any Flutter mobile apps, afaik.
That was probably the right call on your part. Though if someone was insisting on a single code base to save money, I'd probably go with Xamarin because if the framework doesn't supply what you want, you can always drop down and code against the native toolkit.
In my experience, projects like NativeScript are ideal for prototyping but they start to show their warts pretty quickly once you build anything more than that or a basic CRUD app.
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.
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.
Actually i think RN would be better for that, NS has a lot of small quirks.
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.
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.
A bit orthogonal to the post but I find it somewhat funny that in trying to create the ultimate cross-platform UI SDK, Google ended up accidentally creating a rather decent (2D) game proto-framework/engine.
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.
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.
ReactNative... amazing community and works as advertised. Been using it for 4+ years.
The real problem they have is that they fail to ditch an obviously bad solution: “You’ll have to learn how to use their barely working undocumented UI elements and API if you want to create more than a blue button on a white screen. Learning and understanding take months, since the docs are like 60% done, everything else takes days to find out on your own.”.
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.
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.
NativeScript surely has its struggles (like all the other hybrid frameworks), but the concept is strong:
- 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.
- 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.
NativeScript is way better than flutter/dart. NS embraces open web technologies.
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.
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.
I’ve never heard of “NativeScript,” so I can’t understand why a company would risk something as high-stakes as their android app on that. I’m sure it has a lot of benefits but the reality is that it’s still immature. Save the experimental technology for the low-stakes stuff. That’s just disciplined engineering practice.
My guess is it's a Microsoft shop where the most used technology was ASP.NET Webforms and then later Angular. They saw that Telerik (a favorite of enterprisey MS shops) had a cross-platform app framework based on Angular, and they decided to stick with what they knew. I've worked at a couple of these places.
OP having a lesson about flip-side of open source software. I have never written JavaScript or NativeScript but it is very uncomfortable to read a aggressive commentary about an OSS.
> 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.
> 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.
Jesus, dude, OSS is not some kind of holy grail that renders it immune from all criticism, much less valid criticism.
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.
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.
> And telling someone to "help them" when they themselves are looking for documentation to get help? That's just laughable
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.
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.
There's a lot that I don't understand in this post:
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.
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.
Haven't used NativeScript, also see no reason to try it. How is that even going to work? Have docs/examples/q&a for idk how many frameworks?
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.
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.
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)