Live data from Hacker News

Why you should NOT use NativeScript

csimpi.medium.com

71–80 of 81 posts

Re: Why you should NOT use NativeScript

#71
post #19

Earlier quoted context omitted.

> 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.

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…

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.

Re: Why you should NOT use NativeScript

#72
post #13

Earlier quoted context omitted.

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.

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.

Re: Why you should NOT use NativeScript

#73

Earlier quoted context omitted.

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…

> 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”.

Re: Why you should NOT use NativeScript

#74
post #49

History time! 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…

"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

Re: Why you should NOT use NativeScript

#75

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…

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…

> 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.

Re: Why you should NOT use NativeScript

#76
post #7

Earlier quoted context omitted.

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 w…

What do you mean by "and that's if somehow Android moves to it as a first class citizen."?

Re: Why you should NOT use NativeScript

#77
post #60

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.

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 m…

> 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).

Re: Why you should NOT use NativeScript

#78
post #74
post #49

History time! 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…

"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

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

Re: Why you should NOT use NativeScript

#79
post #49

History time! 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…

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.

Re: Why you should NOT use NativeScript

#80
post #49

History time! 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…

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

Post reply on HN