Nativescript: The most frustrating coding experience I've ever took

Created on 30 Nov 2016  路  7Comments  路  Source: NativeScript/NativeScript

I've been coding for at least 20 years, I've coded on low level assembler, do-your-own memory management in C, walking memory pointers directly, Pascal, many scripting languages, but never Java, thank god.

The time I've been wasting trying to figure out the errors that NativeScript spits out is frustrating beyond recognition, I just wasted 2 weeks debugging not my code! You change one thing, be it in your js code or XML, and your application won't start anymore, and you don't know why. And you keep trying for the next 20 minutes, until you decide to uninstall the application, and reinstall it from scratch. Wow working again. Then broken again.

Errors like this:
screenshot_1480478103

lol
lol2

Superb. Really easy to debug, so plain and simple. Then later you mistype one attribute to change one StackLayout inside your partial view, and BOOM. nothing works anymore. I've posted more issues in NativeScript repos than any other open source project, in less than a month

screenshot_1480482155

I'm regretting taking NativeScript for Android development. The errors are cryptic, the logcat helps nothing. The stacktrace is equally useless, pointing inward NativeScript, rarely on your own source code. The livesync corrupts XML views from time to time, even got a nice Cannot read property 'UTF_8' of undefined at startup on a view I didn't touch like forever.

Not to mention the really fragile "node modules" compatibility, it was touted as a strength of NativeScript, but it only works with plain javascript files (neither DOM related, nor Node related)

I wish I went with something like React Native, I'm pretty sure it's much easier to get things done in a proper way there, but you got me in the "Typescript as first-class citizen". Oh well, live and learn.

done

Most helpful comment

[object Object] is an error we should have had integration tests for. The error message should appear as something like the messages in these unit tests: https://github.com/NativeScript/NativeScript/blob/master/tests/app/xml-declaration/xml-declaration-tests.ts#L784
We will address this shortly. Error treating has changed from version to version in V8 so we are updating the errors in this PR: https://github.com/NativeScript/NativeScript/pull/3217

The ECONNREFUSED occurred in few places where the CLI tries to communicate page reload with the app but the app is dead. This is already address in the @next versions of the CLI by @tzraikov here: https://github.com/NativeScript/nativescript-cli/pull/2273

To QA: @dtopuzov @vchimev We need some tests for the error messages

All 7 comments

@pocesar - I don't work for Telerik, and I'm just another independent contractor. Probably won't make you feel any better; and I have been developing for also well over 20 years. 馃榾

I hear your frustration. I started coding NativeScript in v0.90; and the tools are far better now than before. 馃榾 You should have seen the crash logs at that point... Don't get me wrong, NS still has many flaws, but when you program in a number of languages, you quickly discover flaws in everything. Don't get me started on 馃棥 clarion 馃棥 which I still have to develop for a couple clients, you want to talk crappy (crashing) debugging tools...

The debugging tools are still pretty poor in NS! In fact most the time I just avoid them, and when I have to use them, I normally regret it and wish I just console.dump'd the stuff I needed. But the AWESOME news is that the team has recognized this and my understanding the primary focus for 2.5 is to get debugging tools to be close to first class; and in 2.6 round out the pieces with even more features. This is very welcome news for a lot of people!

NativeScript can be a love/hate relationship sometimes. There are days I get totally frustrated with it; and others where it is just so dang awesome. (Like something CRAZY works the first time!).

I evaluated both React, NS, Fuse, Titanium, etc before I choose NS, and I do NOT regret my choice and if I had one major complaint it is the occasionally head butting with the actual NS-Team when we disagree on direction, as I have no say in the final outcome as they can reject any patch they want. 馃槥

But since it is 100% open source, including all the tooling -- it does allow me to go in directions that they haven't supported or endorsed. For example my NativeScript-LiveEdit plugin I developed; if you go way back to very very early in the pull database you will see a pull request for a feature I need for it. They rejected it; and so far they have been playing catch up in their livesync process on Android since that point in time. 馃榾 There rejection didn't stop me from continuing my awesome LiveEdit plugin because NS is 100% open source, and so right now imho, my LiveEdit plugin is still (way) better than their LiveSync on Android. 馃榾

Now as to your actual errors; the first screen, you need to scroll down a bit; the actual error is probably lower in the call stack. Understanding the call stack can be hard until you understand the framework...

Second error is pointless; TNS does like 99% of the time mess up errors, use "adb logcat" in another terminal window to see the real error. (Or the new logcat option in the emulator error box).

Third error that is LiveSync. I tend to avoid the LiveSync "issues", as I always use my LiveEdit on Android. I just get to see others complain about them... :grinning:

Forth error, is most PROBABLY caused by LiveSync. Like I said above -- I avoid LiveSync; it well, lets say leaves a lot to be desired in my book. There is a reason why I have my own LiveEdit plugin. :grinning:
The easiest way to fix that error is to do a tns run android DO NOT add a --watch or livesync to it, you must allow TNS to do a full rebuild and resync to the device. You need to rebuild the app fully and have it deploy it. Then after that; you can use LiveSync or my LiveEdit.

If you follow the React Native bug reports; they also have growing pains frequently. But yes there debug tools actually are way better than NativeScript currently (NS 2.5 might fix this!); but imho the NativeScript foundation/technology is light years ahead of React currently, and there is no easy way to fix RN core foundation.

Oh and as for the node compatibility; quite a few are compatible; but you are correct the majority aren't. You are in the same shape on React. They don't tout any Node compatibility. It doesn't have a true DOM either, nor a node foundation.

If I could show you a cool thing I did recently; I think you would be suitably impressed; realizing how well I was able to make a webview "DOM" based product work fully in NativeScript, by remapping Window, Document, getElement*, etc... :grinning: -- Unfortunately it is currently under lock and key, but has something that rhymes with a type of PhoneCrap app running in a pure NativeScript view, no webview...)

Oh on TS, I prefer just doing ES6 JS, much saner(imo) and both Android and iOS runtimes support ES6. :grinning:

@NathanaelA I did a smaller project in ionic when it was even worse (like angular 1.0 and no debugger), in "no time", using angular. I couldn't get ANYTHING done in 2 weeks on NativeScript. Nothing, even the plain views with no functionality. Either I'm pretty biased towards web and node development, and used to the easiness of programming (compared to the older languages I've mentioned), but I'm at a loss, literally.

The stacktraces I put here is as-is. There's no mention of my code, even at the bottom. If you have a deep nested custom component somewhere, and it's crashing, NS won't show you. It'll crash the view onload after an event handler has fired. I think I'll either try to port most of the TS code to React Native or go full retard on Xamarin, at least C# is a pleasant language to work with, and Visual Studio is top notch in every way.

@pocesar Thank for this report. We are constantly improving the framework and our focus in the next several months is exactly on how to improve the developer experience which includes:

  • improved Livesync in terms of predictable behavior, speed and error reporting,
  • improved exception handling and error reporting. In Angular projects, this is really a problem right now and it is a hot topic in the team how to approach it. Angular 2 itself is still under active development and the experience can be bumpy at times.
  • improved tooling. We are actively working to enable Chrome DevTools to debug and inspect the apps.

I believe we are in the right direction and the fruits if these efforts will start to be seen in the next weeks/months.

The error you experience with the LiveSync (ECONNRESET) not working after an error is already resolved and our QA team is testing it. We plan to release public official 2.4.1 this week. See https://github.com/NativeScript/nativescript-cli/pull/2273

We encourage everyone to report exceptions that are not informative and do not help you much. This is the only way to improve the product. Community folks like @NathanaelA can definitely help not only to find but also to patch such issues in the framework.

Once again thank you for your report, we are committed to stay on top of such issues and treat them with the highest priority, please keep reporting them.

I would agree web technology is way way easier, I frequently use Chrome DevTools to try some piece of generic code I'm going to use in NS. ;-) I'm sorry you have had a bad experience with NativeScript; I have been mostly impressed with it (you can probably tell that with my 20+ plugins I've released for it. :grinning: ) -- I love to program node and NativeScript.

NativeScript is where I'm hoping to pick up more clients even though the majority of my clients are in other industries and languages... So if you are a contractor; then please please by all means go use some other technology, leave me in to my really really horrible language, that only a imbecile (i.e. me) would use. :grinning: But if not, NS is really an awesome system once you understand the quirks that haven't been ironed out yet...

The first stack trace, you actually have to scroll down in, because it was dealing with the builder. The builder stack traces the most important part is typically towards the bottom. (Crazy I know). Because I use my LiveEdit system, I rarely see Builder issues myself. My open-source LiveEdit plugin actually does a full XML verification check before it syncs it to the phone. It is amazing how much more productive it is when my editor tells me my XML is broken and on what line, rather than the phone crashing with an broken xml file.

Now as for missing stack traces; I bet you were in a promise somewhere. Don't know how many times that got me. I really hate promises frequently -- they eat the call stack when you forget to put a catch, so they then silently eat all issues. I really wish a promise would throw an error if there was no catch. This is a problem with both RN and NS and any Promise based system. ;-(

Xamarin actually is not a bad choice, it does have some of the best Dev tools (VS is awesome). But when I played with it, it felt very wrong for a .net app. Too much weird crap to make things work. You can get it to work; but I personally rated it way way lower than RN when I evaluated it about 2 years ago when I choose which framework I was going to use. If MS actually puts some money into it since purchasing it, it could be a really good competitor; but I honestly haven't heard anything "new" from the Xamarin camp. Where like with NS we just got really awesome threads; and next version we should get mucho better Dev Tools.

I wish you luck in your pursuits, and again as one of the fairly happy developers on NativeScript; I'm sorry that your time has been so frustrating.

[object Object] is an error we should have had integration tests for. The error message should appear as something like the messages in these unit tests: https://github.com/NativeScript/NativeScript/blob/master/tests/app/xml-declaration/xml-declaration-tests.ts#L784
We will address this shortly. Error treating has changed from version to version in V8 so we are updating the errors in this PR: https://github.com/NativeScript/NativeScript/pull/3217

The ECONNREFUSED occurred in few places where the CLI tries to communicate page reload with the app but the app is dead. This is already address in the @next versions of the CLI by @tzraikov here: https://github.com/NativeScript/nativescript-cli/pull/2273

To QA: @dtopuzov @vchimev We need some tests for the error messages

The three issues here:

have been addressed in {N} CLI and tns-core-modules packages version 2.4.1.

Let us know if you continue experiencing these or other issues.

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

Was this page helpful?
0 / 5 - 0 ratings