4 ms·

For those who are looking for an alternative to Flutter/React Native, please check out Nativescript @ https://docs.nativescript.org https://docs.nativescript.or

For those who are looking for an alternative to Flutter/React Native, please check out Nativescript @ https://docs.nativescript.org https://docs.nativescript.org! It's different in a few key ways: - Draws native components (Flutter draws every pixel) - Pure JS native (i.e. JNI powered) shim layer (you can write stuff like `const intent = new Intent()`) - Typescript as first-class (not quite so with React Native, and IMO Typescript > Dart as far as type systems and ergonomics are concerned) - Ability to use both Angular and Vue to structure your app (there's also projects out there like Svelte-Native, which is extremely promising from the performance perspective) - More community driven project (with Progress standing behind, following the open-source & extra features business model)

deanclatworthy 7y ago
Looks interesting, but from the homepage I had absolutely no idea this had anything to do with apps. What would be a good place to start?
- hardwaresofton 7y ago
  Sorry maybe the homepage is better to start on (I linked to the docs page): https://www.nativescript.org/ https://www.nativescript.org/ Here's a talk from 2 years ago: https://www.youtube.com/watch?v=ELemwZXJZVg https://www.youtube.com/watch?v=ELemwZXJZVg I personally prefer Nativescript-Vue and I find their docs to be very good: https://nativescript-vue.org/en/docs/introduction https://nativescript-vue.org/en/docs/introduction Some more video resources: https://www.youtube.com/watch?v=DcCSq2Y9bow https://www.youtube.com/watch?v=DcCSq2Y9bow https://www.youtube.com/watch?v=qR1ESQTALI0 https://www.youtube.com/watch?v=qR1ESQTALI0 I personally think the best way to learn it is to get your hands dirty and use it to build something, so I'd recommend that, but there are certainly resources out there as well.
  - codetrotter 7y ago
    > NativeScript Installed the Playground app. When I try to open any of the examples from https://market.nativescript.org/?tab=samples&framework=all_frameworks&category=all_samples https://market.nativescript.org/?tab=samples&framework=all_f..., Safari says “Safari cannot open the page because the address is invalid”. For example, https://play.nativescript.org/?template=play-js&id=h9CNcL&v=3542 https://play.nativescript.org/?template=play-js&id=h9CNcL&v=... tries to open nsplay://boot?pKey=pub-c-a303d41e-5c6b-4030-8151-c056278a7944&sKey=sub-c-2d2f1312-4f78-11e7-ab90-02ee2ddab7fe&template=play-js&sessionId=h9CNcL_3542 Running iOS 12.3.1 on an iPhone X. Is anyone else having this issue?
    - hardwaresofton 7y ago
      This sounds like an excellent bug report for their playground feedback[0] repository, I'll make a ticket for you[1], please feel free to go in and fill out more information to help them help you. [0]: https://github.com/NativeScript/playground-feedback/issues https://github.com/NativeScript/playground-feedback/issues [1]: https://github.com/NativeScript/playground-feedback/issues/153 https://github.com/NativeScript/playground-feedback/issues/1...
      - codetrotter 7y ago
        Good idea, thanks. Please note that the links in the issue you submitted need to be changed because you copied the link text, which are only partial, rather than copying the link target URLs.
        hardwaresofton 7y ago
        Thanks for pointing that out, just fixed it in the issue (thanks also for letting them know how to reach you if they have questions).
rishav_sharan 7y ago
Pity. It seems to be mobile only.
ex3ndr 7y ago
They are running JS code on Main thread. Thank's but no.
- iainmerrick 7y ago
  I wouldn’t necessarily write this off. Doing UI-related work directly in the main thread has a lot of benefits -- your click listeners can take effect immediately and make all the necessary UI updates before the next event is processed. With event handling in a separate thread, it can be harder to make things robust (filtering out double taps, preventing flashes of unfinished/unstyled content, etc). Of course you do need to make sure that everything that could be even slightly expensive is shipped out to a background thread. JS is weak in that respect. Moving everything to a background thread does fix that problem, but I think it’s overkill. A lot of mobile apps would be faster and more responsive if they used the main thread more. You just have to use it right.
- hardwaresofton 7y ago
  Nativescript has supported the web worker paradigm for multi-threading for a while now[0]. Also, I'd like to point that for a lot of applications (especially the ones that are basically informational without much interaction or client-side work, this actually isn't an issue early in the development process. I've used Nativescript on client projects, and it is fantastic for prototyping, with well demarcated paths to performance optimization. Since you can easily use native screens/controllers/etc with it, at the very least you can use it for fast prototyping then drop all your custom code in. Do you know of any hybrid frameworks that are not running JS code on the main thread by default? And by JS code I assume you mean display-related code, because Flutter suffers from this same issue, do too much hard work on the main thread and it stalls (as anything would). Even on android itself[1] you need to do some extra work to make sure your UI-related heavy lifting happens off the main thread: > However, when the main thread’s messaging queue contains tasks that are either too numerous or too long for the main thread to complete the update fast enough, the app should move this work to a worker thread [0]: https://docs.nativescript.org/core-concepts/multithreading-model https://docs.nativescript.org/core-concepts/multithreading-m... [1]: https://developer.android.com/topic/performance/threads https://developer.android.com/topic/performance/threads

deanclatworthy 7y ago

Looks interesting, but from the homepage I had absolutely no idea this had anything to do with apps. What would be a good place to start?

hardwaresofton 7y ago
Sorry maybe the homepage is better to start on (I linked to the docs page): https://www.nativescript.org/ https://www.nativescript.org/ Here's a talk from 2 years ago: https://www.youtube.com/watch?v=ELemwZXJZVg https://www.youtube.com/watch?v=ELemwZXJZVg I personally prefer Nativescript-Vue and I find their docs to be very good: https://nativescript-vue.org/en/docs/introduction https://nativescript-vue.org/en/docs/introduction Some more video resources: https://www.youtube.com/watch?v=DcCSq2Y9bow https://www.youtube.com/watch?v=DcCSq2Y9bow https://www.youtube.com/watch?v=qR1ESQTALI0 https://www.youtube.com/watch?v=qR1ESQTALI0 I personally think the best way to learn it is to get your hands dirty and use it to build something, so I'd recommend that, but there are certainly resources out there as well.
- codetrotter 7y ago
  > NativeScript Installed the Playground app. When I try to open any of the examples from https://market.nativescript.org/?tab=samples&framework=all_frameworks&category=all_samples https://market.nativescript.org/?tab=samples&framework=all_f..., Safari says “Safari cannot open the page because the address is invalid”. For example, https://play.nativescript.org/?template=play-js&id=h9CNcL&v=3542 https://play.nativescript.org/?template=play-js&id=h9CNcL&v=... tries to open nsplay://boot?pKey=pub-c-a303d41e-5c6b-4030-8151-c056278a7944&sKey=sub-c-2d2f1312-4f78-11e7-ab90-02ee2ddab7fe&template=play-js&sessionId=h9CNcL_3542 Running iOS 12.3.1 on an iPhone X. Is anyone else having this issue?
  - hardwaresofton 7y ago
    This sounds like an excellent bug report for their playground feedback[0] repository, I'll make a ticket for you[1], please feel free to go in and fill out more information to help them help you. [0]: https://github.com/NativeScript/playground-feedback/issues https://github.com/NativeScript/playground-feedback/issues [1]: https://github.com/NativeScript/playground-feedback/issues/153 https://github.com/NativeScript/playground-feedback/issues/1...
    - codetrotter 7y ago
      Good idea, thanks. Please note that the links in the issue you submitted need to be changed because you copied the link text, which are only partial, rather than copying the link target URLs.
      - hardwaresofton 7y ago
        Thanks for pointing that out, just fixed it in the issue (thanks also for letting them know how to reach you if they have questions).

rishav_sharan 7y ago

Pity. It seems to be mobile only.

ex3ndr 7y ago

They are running JS code on Main thread. Thank's but no.

iainmerrick 7y ago
I wouldn’t necessarily write this off. Doing UI-related work directly in the main thread has a lot of benefits -- your click listeners can take effect immediately and make all the necessary UI updates before the next event is processed. With event handling in a separate thread, it can be harder to make things robust (filtering out double taps, preventing flashes of unfinished/unstyled content, etc). Of course you do need to make sure that everything that could be even slightly expensive is shipped out to a background thread. JS is weak in that respect. Moving everything to a background thread does fix that problem, but I think it’s overkill. A lot of mobile apps would be faster and more responsive if they used the main thread more. You just have to use it right.
hardwaresofton 7y ago
Nativescript has supported the web worker paradigm for multi-threading for a while now[0]. Also, I'd like to point that for a lot of applications (especially the ones that are basically informational without much interaction or client-side work, this actually isn't an issue early in the development process. I've used Nativescript on client projects, and it is fantastic for prototyping, with well demarcated paths to performance optimization. Since you can easily use native screens/controllers/etc with it, at the very least you can use it for fast prototyping then drop all your custom code in. Do you know of any hybrid frameworks that are not running JS code on the main thread by default? And by JS code I assume you mean display-related code, because Flutter suffers from this same issue, do too much hard work on the main thread and it stalls (as anything would). Even on android itself[1] you need to do some extra work to make sure your UI-related heavy lifting happens off the main thread: > However, when the main thread’s messaging queue contains tasks that are either too numerous or too long for the main thread to complete the update fast enough, the app should move this work to a worker thread [0]: https://docs.nativescript.org/core-concepts/multithreading-model https://docs.nativescript.org/core-concepts/multithreading-m... [1]: https://developer.android.com/topic/performance/threads https://developer.android.com/topic/performance/threads