React Native<\/h2>\n\n\n\nReact Native Doctor<\/h3>\n\n\n\n
Each of the three tooling's has a Doctor<\/strong> command, this command checks your setup and verifies everything looks sane for doing development in that framework...<\/p>\n\n\n\n The React Native doctor seems to be mislabeled, it calls the SDK BUILD tools, \"Android SDK\". It apparently want the Android 31.0.0 BUILD tools, not the actual Android SDK 31. I had all those Build Tools, but also every SDK since 26 installed and was quite confused at what it wanted. Finally actually checked the Build tools tab in Android studio and realized what it was looking for.<\/p>\n\n\n\n The interesting thing, unlike NativeScript tooling, even though the RN Doctor complained about the missing tooling, the CLI continued to work and it built the application without any other issues. My guess is that they have \"tested\" it with 31, but it works fine with 30 or 33.<\/p>\n\n\n\n For React Native (RN) to create a project the recommended method is: And you will see something like this:<\/p>\n\n\n\n So it basically gets you up and running quickly, and gives you the (in my case broken) instructions of how to start your app. <\/p>\n\n\n\n In addition if you have never ran a RN app before it says it has to Jettify 945 files. I assume it caches the results, because the first time was very slow, each following run this step appeared to be instantaneously. <\/p>\n\n\n\n Following the instructions of changing the directory and doing a \" NativeScript requires you to manually install quite a few dependencies, by contrast I found React Native's & Flutters install a lot easier for novice users. <\/p>\n\n\n\n To run the NativeScript doctor you type Now in my case because the NativeScript team is unfortunately slow even fixing known issues (even those with a supplied fix) -- Which I personally posted several months ago (in May) -- the most recent CLI (published 2 days ago) is still failing on my machine with this error, so unless I manually apply my fix that I submitted to them (https:\/\/github.com\/NativeScript\/nativescript-cli\/issues\/5668) -- NativeScript is totally broken on Linux. You can see why I wrote the \"Goodbye NativeScript<\/a>\" article, its ridiculous now how many outstanding issues don't get any traction or fixes, let alone ignoring fixes that are supplied. <\/p>\n\n\n\n The crazy thing is NativeScript's doctor is quite wrong, and, then the NS tooling will then refuse to actually work for ANYTHING related to the platform when it detects what it considers is an \"error\". NativeScript itself doesn't actually use Javac, but it checks because Gradle uses it. But it detects the wrong version first and breaks.<\/p>\n\n\n\n I have several versions installed which Gradle is actually smart enough to use the proper version it needs to (as the Gradle version NS is using doesn't currently like v18 of Java). It is just that the NS CLI doesn't understand how to parse the version 18 number and then it doesn't bother to search for any other versions. If you are on Linux you will run into this issue if you have Java 18 installed. Other platforms you probably won't run into this specific issue, but the worst thing is that when you run into any detection issues, it will completely stops you from doing anything with NativeScript on the platform it thinks has an issue. <\/p>\n\n\n\n To create a project in NativeScript you type It will then ask you the flavor to use, which is one of the awesome and unique things in NativeScript. You can develop your application using a framework you are already familiar with. The best maintained is plain JS\/TS (which is the core flavor, so it has to be maintained), then Angular (latest version), finally Vue (only Vue 2.x). The rest of them are in varying states of work-ability of which you are liable to have some issues with. This isn't to say Angular or Vue is perfect, but those two flavors normally have the least number of issues compared to all the other flavors. Finally If you are wanting the fastest or closest to the metal flavor, JS\/TS is by far the fastest and least memory using flavor. All other flavors are using their (in some cases massive) frameworks wrapped OVER the plain core framework. So a call to do anything with a component is several more levels deep in code in say Angular than plain JS. Last time I benchmarked things, Angular was a order of a magnitude slower than plain JS for most things, not to say it was horribly slow -- but 15ms vs 10ms adds up quickly in complex screens. <\/p>\n\n\n\n So creating a project prints this out in the current version of the NativeScript tooling.<\/p>\n\n\n\n The instructions here do sorta work, for example it prints \"ns run ios\", but I'm on Linux -- guess which two commands only work on Macintosh and don't work on Linux or Windows? Kinda silly to tell me to run a command that will fail as the first command. But the other two commands for Android do work.<\/p>\n\n\n\n The Flutter doctor is ran by typing: Using the \"-v\" does even more in depth reporting, which actually is longer than an entire screen of information -- so I'm just going to show you want the normal one prints, since we don't need a two page graphic here. <\/p>\n\n\n\n The Flutter doctor is also smart enough to actually find the (older) Java 11 install which Gradle uses, rather than detect my newer default version that I use for other development work...<\/p>\n\n\n\n To create a project, if you haven't guessed it is: And you get this:<\/p>\n\n\n\n I was shocked when it finished in 2 seconds, I'm used to NativeScript taking forever and React Native actually was longer than NativeScript. So it was a pleasant surprise to hit return and be right back at the command prompt, ready to go. I also like that its required two commands are together and simple to follow and worked out of the box. So far this is the only platform that actually worked without having to figure out what was broken or work create fixes.<\/p>\n\n\n\n The first comparison I plan on testing is speed to first draw. I used one of my slower android devices to make it easier to see the actual speed of the application. This is actually pretty critical as studies show that the slower the app is the more likely users will use the faster app. So if you are competing in a market, do you want the app that starts instantly, or the one that start up a dead last?<\/p>\n\n\n\n To build what I believe is a release apps (if I made any mistakes here, please let me know), I used the following CLI options<\/p>\n\n\n\n Flutter (flutter run --release ) (*) Flutter does not ship the x86 32-bit library. However, based on the 3 platforms it does ship we can estimate that the number should be somewhere around 21.8 megs total to include the 32-bit x86 runtime if it had one.<\/p>\n\n\n\n I expected putting Flutter on old of a phone (low\/mid-range early 2018 Android 9 model) would cause it to be handicapped as its GPU is old, and has low ram availability -- Flutter tends to depend on the GPU. I was very surprised by the outcome so much so I decided to skip all the numbers for a much more modern faster device since it performed incredibly well on this device and easily lapped the other two frameworks. My initial testing on a faster device showed it was equally faster on it.<\/p>\n\n\n\n NativeScript benchmarks, as I stated above adding a framework over the core framework actually cost NativeScript a tad over a second in startup time. That is almost all initialization time from the Angular framework. It also uses twice as much memory. Now granted the Angular demo is slightly more complex than the JS demo as it uses a list view, instead of a button and some text. It is still one of the simplest list view you can imagine and it shouldn't be costing anything close to an extra second of time for first paint and twice as much memory. Also in actual complexity the React Native demo actually displays a LOT more elements on first draw than either of the NativeScript app's, yet it consistently starts up almost 2 seconds faster than either of the NativeScript app's. <\/p>\n\n\n\n In the next article I plan on comparing the same information on iOS and see how well everything does. <\/p>\n\n\n\n So far, Flutter is easily the winner in all three aspects: App size, memory usage and speed on Android.<\/p>\n\n\n\n If anyone has any pointers to a simple TODO app using SQLite on NativeScript, React Native and Flutter, I would love to compare a more \"like vs like\" app test, not that the examples don't give us a good idea of memory, size and startup time. It just \"appears\" more fair if everything is \"like\". <\/p>\n","protected":false},"excerpt":{"rendered":" Setup - All Engines Assuming you have all your dependencies installed according to there respective pages: React Native: https:\/\/reactnative.dev\/docs\/0.60\/enviroment-setup NativeScript: https:\/\/docs.nativescript.org\/environment-setup.html Flutter: https:\/\/docs.flutter.dev\/get-started\/install React Native React Native Doctor Each of the three tooling's has a Doctor command, this command checks your setup and verifies everything looks sane for doing development in that framework... The React… Continue reading React Native vs Flutter vs NativeScript (Part 1)<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_crdt_document":"","footnotes":""},"categories":[154,168,15,169],"tags":[159,16,170],"class_list":["post-1482","post","type-post","status-publish","format-standard","hentry","category-cross-platform","category-flutter","category-nativescript","category-react-native","tag-flutter","tag-nativescript","tag-react-native","entry"],"_links":{"self":[{"href":"http:\/\/fluentreports.com\/blog\/index.php?rest_route=\/wp\/v2\/posts\/1482","targetHints":{"allow":["GET"]}}],"collection":[{"href":"http:\/\/fluentreports.com\/blog\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/fluentreports.com\/blog\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/fluentreports.com\/blog\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/fluentreports.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=1482"}],"version-history":[{"count":3,"href":"http:\/\/fluentreports.com\/blog\/index.php?rest_route=\/wp\/v2\/posts\/1482\/revisions"}],"predecessor-version":[{"id":1495,"href":"http:\/\/fluentreports.com\/blog\/index.php?rest_route=\/wp\/v2\/posts\/1482\/revisions\/1495"}],"wp:attachment":[{"href":"http:\/\/fluentreports.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=1482"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/fluentreports.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=1482"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/fluentreports.com\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=1482"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}![\"\"](\"https:\/\/fluentreports.com\/blog\/wp-content\/uploads\/2022\/08\/image-2.png\")
<\/a>React Native Project<\/h3>\n\n\n\n
> npx react-native init [your project name]<\/code><\/p>\n\n\n\n<\/a>npx react-native run-android<\/code>\" gave me an BROKEN app in my emulator. Not the best on-boarding. Having the out of the box app be totally broken on first run is disheartening and can easily turn people off to the platform. At least It had a nice diagnostic screen that told me I needed to run \"npx react-native start<\/code>\" and then hit \"r-r\" on the keyboard to force the app to refresh, which then it gave me a working app. In addition using --variant release<\/strong> also gave me a working application.<\/p>\n\n\n\nNativeScript<\/h2>\n\n\n\n
NativeScript Doctor<\/h3>\n\n\n\n
> ns doctor<\/p>\n\n\n\n<\/a><\/a>NativeScript Project<\/h3>\n\n\n\n
> ns create [project name]<\/p>\n\n\n\n<\/a>Flutter<\/h2>\n\n\n\n
Flutter Doctor<\/h3>\n\n\n\n
> flutter doctor
or
> flutter doctor -v
Now of all the Doctors, this one is the most impressive. It has a lot of checks that are useful. They clearly have thought of a lot of corner cases and I was a shocked when it told me my API 33 wasn't installed properly. This was a side effect of me messing and trying to fix the React Native Doctor. I started installing the latest API's and deleting old Preview API just to make sure they weren't causing RN's detection issues. So the directory existed, but Api 33 was still being downloaded by Android Studio, and Flutter detected this and let me know there was an issue. Kudo's to the Flutter team for the very valuable checks to make sure that the API's are installed properly.<\/p>\n\n\n\n<\/a>Flutter Project<\/h3>\n\n\n\n
> flutter create [project name]<\/p>\n\n\n\n<\/a>Comparisons: Android<\/h2>\n\n\n\n
NativeScript (ns run android --env.aot --env.uglify --release --key* )
React Native (npx react-native start<\/code> --variant release)<\/p>\n\n\n\nSpeed to first draw<\/h3>\n\n\n\n
<\/td> Avg <\/td> Fastest<\/td> Slowest<\/td><\/tr> Flutter<\/td> 1.26<\/td> 1.14<\/td> 1.36<\/td><\/tr> NativeScript (JS)<\/td> 3.08<\/td> 2.84<\/td> 3.84<\/td><\/tr> NativeScript (Angular)<\/td> 4.26<\/td> 4.01<\/td> 5.10<\/td><\/tr> React Native<\/td> 1.81<\/td> 1.33<\/td> 2.37<\/td><\/tr> React Native (Hermes)<\/td> 1.53<\/td> 1.45<\/td> 1.73<\/td><\/tr><\/tbody><\/table> File sizes:<\/h3>\n\n\n\n
<\/td> All Targets<\/td> Arm 64 Target only<\/td><\/tr> Flutter<\/td> 21.8 megs (*)<\/td> 6.5 megs<\/td><\/tr> NativeScript (JS)<\/td> 23.6 megs<\/td> 8.4 megs<\/td><\/tr> NativeScript (Angular)<\/td> 23.8 megs<\/td> 8.6 megs<\/td><\/tr> React Native (Normal)<\/td> 26.1 megs<\/td> 9.4 megs<\/td><\/tr> React Native (Hermes)<\/td> 18.9 megs<\/td> 7.4 megs<\/td><\/tr><\/tbody><\/table> Memory Usage<\/h3>\n\n\n\n
Flutter<\/td> 645 KB<\/td><\/tr> NativeScript (JS)<\/td> 2.1 MB<\/td><\/tr> NativeScript (Angular)<\/td> 4.5 MB<\/td><\/tr> React Native (Hermes)<\/td> 28 MB<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n Notes...<\/h2>\n\n\n\n