by SuaveSteve on 4/12/21, 5:29 PM with 80 comments
by stewx on 4/12/21, 6:03 PM
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/...
by natenthe on 4/12/21, 6:28 PM
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.
by yuchi on 4/12/21, 8:16 PM
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)
by reggieband on 4/12/21, 6:43 PM
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.
by mouldysammich on 4/12/21, 5:45 PM
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.
by kevinmgranger on 4/12/21, 5:47 PM
by bkm on 4/12/21, 8:07 PM
- 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.
by robocat on 4/12/21, 8:07 PM
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.
by dnndev on 4/12/21, 8:06 PM
by codeptualize on 4/12/21, 9:57 PM
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.
by gwbas1c on 4/12/21, 8:28 PM
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.
by starik36 on 4/12/21, 7:53 PM
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.
by segmondy on 4/12/21, 7:30 PM
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.
by filleduchaos on 4/12/21, 8:03 PM
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.
by CyberRabbi on 4/12/21, 8:10 PM
by yagizdegirmenci on 4/12/21, 8:18 PM
> 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.
by aaronbrethorst on 4/12/21, 7:20 PM
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…
by mkrishnan on 4/12/21, 6:44 PM
Probably you should go with java/kotlin instead of flutter/dart.
by Zelphyr on 4/12/21, 8:01 PM
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.