Nativescript is fantastic -- I maintain that it's better than React Native because React Native lacks a native JS->platform translation layer and React-land is crazy sauce, and can't really be compared with Flutter (because of how Flutter works), but I still think it's better there even because I'd pick Typescript over Dart, and I don't have to commit so hard to the ecosystem.
I've used Nativescript in production and it was wonderfully productive. I think it's biggest weak point is suffering from lack of recent support/ecosystem that hype usually brings.
The ability to use your frontend framework of choice (Angular, Vue, Svelte, Vanilla JS) is awesome, and I think can be incredibly productive for businesses (turn your frontend devs into mobile devs).
We used Nativescript in production, and it is unending train wreck.
I advise everybody to avoid Nativescript for as long they self-qualify their project as anything serious.
The ecosystem, and upstream looks really much like the Wordpress plugin world, and is grossly unprofessional.
On the technical side, you will be always struggling with OOM, I/O performance, and the fact that you will be spending MORE time on native code for both Android, and Ios than if you did them separately.
Would you mind expanding on the OOM and I/O performance issues you ran into? The ecosystem being less than enterprise-grade was known to me, but I did not run into any OOM or I/O performance issues.
Also, did you try either Flutter or React Native afterwards or go straight to native? Did you find them better?
Flutter provides an amazing developer experience. Dart is a great and modern programming language and built specifically for the needs of this framework. Everything just works out of the box. It's backed by google, it's completely open source, it doesn't need any native dependencies. It's a better version of Qt,RN, NS
Typescript fits my sensibilities and desire for expressive type-systems much more than Dart.
Back when I tried it, it also had a much more incomplete ecosystem, though the google marketing machine was in full swing. I remember not being able to even use the sqlite library without actually spinning up an emulator (as in, I couldn't use it with just plain dart). Dealing with generics was actually difficult/painful (as in just something simple like printing JSON). BLoC seemed like a hack and was more complex than I was comfortable with for using at large scale. Maybe it's better these days.
I will take Typescript over Dart all day every day. I would even take JS with all it's warts over Dart.
That said, Flutter I think is amazing because it is probably going to be hands-down the easiest way to write apps that hit a large number of screens. I think Google will get there first-ish (they have a lot of money and a lot of platforms to support).
Sure, very simple react and vue apps regularly run into memory leaks upon navigating views, with most memory being leaked in UI part managed by nativescript, and not in the JS logic. NS does not do it's job freeing memory from UI.
The natural JS leakiness gets amplified if a leaked part references any JS object.
Performance suffers whenever any native API gets called from a JS loop, as exporting Java's objects into JS, and accessing them is very resource intensive. The only way around it was to move loops to Java side of the code.
> Also, did you try either Flutter or React Native afterwards or go straight to native? Did you find them better?
Flutter is not much better, though feels to be a bit more professionally done. It's too a memory hog, it's too a CPU hog, and it's still gets way more issues over a native app to warrant its use just for economic reasons.
RN also shares the same Java-JS interop issues as NS.
Thanks for explaining more, appreciate it and hopefully others will find this as useful as I did.
> Performance suffers whenever any native API gets called from a JS loop, as exporting Java's objects into JS, and accessing them is very resource intensive. The only way around it was to move loops to Java side of the code.
One of the gotchas around nativescript (and react native) was that trying to do intensive calcuations was never supposed to happen on the main thread. Nativescript was first to add support for background workers[0] which alleviate this.
I do believe of course that you found CPU intensive tasks/looping to be slower on the JS side of things though.
> Flutter is not much better, though feels to be a bit more professionally done. It's too a memory hog, it's too a CPU hog, and it's still gets way more issues over a native app to warrant its use just for economic reasons.
This I'm somewhat surprised to hear, I thought it would have been way better on the memory side of things since Flutter is essentially a rebuild-the-world approach.
> RN also shares the same Java-JS interop issues as NS.
This is inline with what I expected -- the thing about RN when I tried it was that it just didn't have the ability to access native objects from JS as if they were JS objects. Maybe that's changed since I last tried it.
Progress is no Facebook/Google/Microsoft, but it's good that there's someone actively working on the framework. Shame they haven't tried to market NativeScript as an alternative to React Native.
At least it's better known that other random enterprise cross-platform solutions that seem to exist only on SEO-optimized listicles of cross-platform solutions such as Codename One, RhoMobile, Kony, Framework7, - e.g. https://www.way2smile.ae/blog/cross-platform-mobile-app-deve... (Again, what companies are actually building apps with these things?)
So Progress actually handed over development to a company called nStudio relatively recently. The proof/PR announcement feels like it's been wiped off the internet but there are traces still[0].
They've been great stewards so far -- improving the codebase and going after long-standing pain points, but it's worth mentioning.
Hm, CodenameOne is actually something I was planning on making use of at some point in the future. I’m (solo) working on a Swing app that I want to bring to mobile, so it seemed like a good fit to convert to it or write a branch that used it. Is it actually a dumpster fire to be wary of?
Not that I know of, it just seems like one of those frameworks that exists and there is some online chatter mentioning it but I have no idea who actually uses it. If it turns out to be good you should let people about it!
Good to know, thanks! I’ll have to check out the links to the community when I get a chance too. Always good to know that a piece of tech you’d planned on using is healthy.
I develop my front ends primarily in React, and other than hooks - which a lot of people have adopted anyway, and only extended the lib - the API seems very stable. The 3rd party library ecosystem may be wild because React is superpopular and people are publishing npm packages with half-baked solutions of dubious utility, but there's always a good library or two for 95% of tasks (good: regularly maintainted, fully-featured, well-documented, tested, typed, etc.).
I don't have any experience with RN so I don't know how things are there, but your comment seems to be about the React ecosystem at large and doesn't correspond to my experience at all.
I wouldn't consider myself a React expert because I basically stopped using it or recommending it once Vue came out, but stuff like:
- Needing shouldComponentUpdate to do anything nontrivial (it's a bad sign for what should be a library if people make "X demystified"[0] posts).
- The sheer amount of times React has been basically rewritten, with
- Hooks (to be fair Vue has this too, and it's not actually a bad feature, but as usual React introduced it in a near inscrutable way).
- Every react codebase cargo-culting into Flux (normally through redux) when all you really need most of the time is a simple AJAX call.
React had the initial idea, but it just feels like the stuff that came after (Vue in particular) delivered better on the simplicity we all wanted. There are so many little gotchas all over the place that people just paper over/memorize, when Vue 2/3 basically works as advertised right out of the box, need(ed?) less hacks, and you can get reasonably productive and performant in <1 day after reading all the docs.
Also I want to point out that "react" is almost always react + redux + react-router + webpack at the end of the day. The combined complexity is not worth it when compared to Vue in my opinion. These days if I want to use something, I do vue + vue-router + parcel and call it a day, and get productive much quicker though the ecosystem isn't quite as big. For uber-simplicity I like mithril[2][3] though -- but it falls down when you start looking at advanced features like SSR/rehydration.
React has the best third party support/ecosystem because of the amount of hype and OSS friendly companies that are using and benefiting from React. It also is the best corporate choice -- react developers are more fungible, you will benefit from more of the free work done by the F/OSS crowd, etc.
These points hardly justify how one could casually that drop React land is "crazy-sauce" while recommending NativeScript... There's quite a bit to address here:
> Needing shouldComponentUpdate to do anything nontrivial
I'd need to see what "non-trivial" means, because I have barely used it in three years pushing React to production, even when I used classes... The article you post is from 2017, it shows an optimization for a very particular scenario (rendering a list of 600 items), which BTW, could be optimized in many different ways... If you're telling me Vue never needs this kind of optimization for heavy fronts, I'd have a very hard time believing you.
> The sheer amount of times React has been basically rewritten
I honestly wouldn't know or care if the library has been "rewritten", "extended" or "patched" or what they've done to the underlying code - because the core API has not really changed in years... Like I said, hooks extended the library and developers could transition at their own pace or not transition at all.
> Every react codebase cargo-culting into Flux (normally through redux) when all you really need most of the time is a simple AJAX call.
There are many React codebases that don't use Redux. But it's still a great state management library (or pattern) for moderately complex UIs. If you have your own state-management solution (including "simple AJAX calls", whatever that means in the context of Flux or state management), you can use it...
> you can get reasonably productive and performant in <1 day after reading all the docs
Ditto for React... Any semi-competent dev can be writing at least presentational components with basic network calls in a day... Moderately complex state management and asynchronous actions that affect state take longer to wrap your head around, but I doubt that Vue really simplifies this. UI programming can become naturally complex under certain requirements, and I doubt there is a framework that can completely abstract away this complexity.
> Also I want to point out that "react" is almost always react + redux + react-router + webpack at the end of the day
That's Create-React-App, which completely abstracts the need for pretty much everything except React-Router (10min to setup) and Redux (which nowadays you can substitute with plenty of alternatives). You can be writing business logic and views in 15 minutes, tops. And in a fair amount of cases, CRA stands the test of time, too: I've got code in production for very large customers using it and I know of startups that are building complex products in their second or third year of operations and haven't even ejected their app...
> the amount of hype and OSS friendly companies
Sure, there are network effects - popularity begets popularity. But surely a library or framework can't live on hype alone? Look at Angular... React also - mainly, rather - remains popular because it has seen significant improvements to its core and ecosystem.
> I'd need to see what "non-trivial" means, because I have barely used it in three years pushing React to production, even when I used classes... The article you post is from 2017, it shows an optimization for a very particular scenario (rendering a list of 600 items), which BTW, could be optimized in many different ways... If you're telling me Vue never needs this kind of optimization for heavy fronts, I'd have a very hard time believing you.
Vue2 worked a different way from inception (probably gaining from being able to see what react did and do something different), it tracks dependencies via the data property, so it does not require you to specify manually. Heavy list rendering isn't what I was referring to, it's manual dependency tracking -- there's a separate pattern for large list rendering.
It's not all sunshine and rainbows, but this is a better default.
> I honestly wouldn't know or care if the library has been "rewritten", "extended" or "patched" or what they've done to the underlying code - because the core API has not really changed in years... Like I said, hooks extended the library and developers could transition at their own pace or not transition at all.
As recently as October this year breaking changes were an issue[0].
> There are many React codebases that don't use Redux. But it's still a great state management library (or pattern) for moderately complex UIs. If you have your own state-management solution (including "simple AJAX calls", whatever that means in the context of Flux or state management), you can use it...
No it's not, and that's the thing. There are even more codebases that are doing just fine with services + views (popularized by angular, ember). The main benefit I see is the time-travel property of state stores, but that's not that hard to do with other approaches either. This is the cargo culting in action -- everyone just assumes "oh you need state-management? well redux it is then, start reading up on reducers". Redux is so obtuse that redux-toolkit[1] exists. Again, the promise was simplicity but what you got was complexity.
> Ditto for React... Any semi-competent dev can be writing at least presentational components with basic network calls in a day... Moderately complex state management and asynchronous actions that affect state take longer to wrap your head around, but I doubt that Vue really simplifies this. UI programming can become naturally complex under certain requirements, and I doubt there is a framework that can completely abstract away this complexity.
So that's the thing, all that "moderate complexity" stuff you'd have been up and running with in Vue 2 on the first day. You can read the Vue docs in a few hours, and write an app that handles state reasonably well in that same day. It's not that it's abstracted away, it's free of unnecessary abstraction which is what makes it simple.
> That's Create-React-App, which completely abstracts the need for pretty much everything except React-Router (10min to setup) and Redux (which nowadays you can substitute with plenty of alternatives). You can be writing business logic and views in 15 minutes, tops. And in a fair amount of cases, CRA stands the test of time, too: I've got code in production for very large customers using it and I know of startups that are building complex products in their second or third year of operations and haven't even ejected their app...
Here's another red flag for me -- if your library needs me to download a zipfile with everything pre-setup (because not doing so would be difficult), then your library is complex. Maybe I'm the only one that still creates new folders and puts files in myself, but I try not to allow this kind of complexity.
I want to be clear -- I don't doubt react's usefulness to enterprise. I do not doubt it's production worthiness or ecosystem -- the result of the hype and the popularity is that people have made it production ready, contributed an intense amount, and built great stuff with it. It is the premier front end component-based library, I do not doubt that. It essentially re-introduced the idea of component-based frameworks (I'd argue Backbone Views were already there, as well as Angular Directives, some MVVM stuff etc), and made is seem simple and sexy.
> Sure, there are network effects - popularity begets popularity. But surely a library or framework can't live on hype alone? Look at Angular... React also - mainly, rather - remains popular because it has seen significant improvements to its core and ecosystem.
You're right, they can't but I think it's more of a case of Angular2 being a failed migration (and maybe apply/digest being horrible there too), it was the enterprise choice before React. I think you have it backwards -- react receives significant improvements to it's core and ecosystem because it is popular, and maintained by a large FANG company. It has endured rewrites (which take significant manpower) smaller projects could not undertake because of said funding.
Funnily enough, this brings me back to Dart -- Dart1 was a trainwreck, and Dart2 is way better but in my opinion is trash in comparison to newer statically type checked languages designed around the same time (Rust, Go, Swift, D, etc). I know however, that Dart will never die, as long as it is used in Fuschia or at Google in general. People were probably saying the same kinds of things about Dart1 and they'll say nice things about Dart2, but I still prefer Typescript because it a type system more suited to my tastes.
I don't think I can convince you that react is complex and has warts that other libraries (in particular Vue) don't have. It sounds like you're productive and find it easy, that's great by all means use it -- whatever makes you the most productive.
I've used Nativescript in production and it was wonderfully productive. I think it's biggest weak point is suffering from lack of recent support/ecosystem that hype usually brings.
The ability to use your frontend framework of choice (Angular, Vue, Svelte, Vanilla JS) is awesome, and I think can be incredibly productive for businesses (turn your frontend devs into mobile devs).