5 ms·

I recently tried to start a react native / typescript project, but the ecosystem confused me a lot. The various different tool recommended to create a project,

by bsaul 7y ago

I recently tried to start a react native / typescript project, but the ecosystem confused me a lot. The various different tool recommended to create a project, some project templates not even compiling, the tons of different utilities required to process source files.. All that and not a single reliable source of documentation, made me feel it would be a real nightmare to maintain on the long run.

latchkey 7y ago
You are right. This is part of what made me try Flutter for a new app over RN. While it isn't perfect (no tooling is), the initial user experience is pretty good and the documentation is constantly updated as the product matures.
- paulintrognon 7y ago
  I understand they are using the Dart langugage? Was it hard to master?
  - latchkey 7y ago
    Super easy if you know JS/TS and turns out that I actually quite like it.
    - virtualwhys 7y ago
      What's missing? TS has quite a few interesting language features that I assume Dart is missing (seems Dart has the reputation of being a Java-like language, with all the boilerplate that that entails).
      - latchkey 7y ago
        Probably my largest complaint is the need to use codegen for the json stuff. Sure you can type it all out by hand, but the codegen really does automate a lot of it for you. I have intentionally kept my very specific use case mobile app very very simple and not gone deep on the magic edge cases. It is a private app and will never be on the store. It is basically used as a QR code scanner to track equipment. I'm sure that if you have a lot deeper/larger apps you'd find more to complain about, but so far I'm happy enough with going from zero to full fledged app in about a month of work. IMHO, the boilerplate argument with Java is kind of outdated (Project Lombok and modern java solve a lot of that).
- bsaul 7y ago
  I used to be into flutter (theorically), but after seeing some bugs and performance issues, i’m now thinking the best combination would be : - write once and compile all business logic (and server and fs i/o ideally) into a portable independant libray, either in something that compiles to C, or wasm (once it’s more mature) - write native UI code using native tooling, and call the business logic library from there. But i haven’t settled yet on the ideal PL to write that library and have it interface easily on both android and ios.
  - rabenblut 7y ago
    This is the approach used with Kotlin multiplatform development. I suspect it will be the best way going forward, other approaches all have serious issues. https://kotlinlang.org/docs/reference/multiplatform.html https://kotlinlang.org/docs/reference/multiplatform.html
  - izacus 7y ago
    This is the approach we took at my current and previous mobile projects and has proven to be very effective (we chose C++ due to toolchain maturity over all platforms): - It forces you to think about your business logic vs. UI structure. - It forces you to make your core logic library easily testable. - Since you can deploy the core logic library anywhere, you get native, no Electron bullshit, support for pretty much all major operating systems at a cost of running a CI on all compilers to catch non-portable parts of C++ quickly. - The users get UI that's built for their platform with it's own quirks and doesn't burn 500MB of RAM. - Using a serializable and portable message standard (we opted for Protobufs) to communicate between logic library and UI part makes deployment to server easy as well. Biggest issues? - Getting inflexible people to learn anything other than JavaScript. - Getting slow compile times under control. - Getting CI coverage to the point where it catches developers accidentally adding Apple or Linux specific headers into codebase. - Learning to be conservative enough to not trust the platform and ship our own libraries. Even basic ones like SQLite.
    - alien1993 7y ago
      How do you achieve this? Are you using some framework like Qt? Or is it custom?
dep_b 7y ago
I have the same experience trying to use it myself. And this stacked on top of the mess that the Javascript, Android and iOS worlds themselves already can be sometimes. One of the apps I maintained got rewritten in React Native but I couldn't get it to build. One of the devs stepped in and helped it. "Oh just retry it a few times it'll work eventually" and sure it did. So apparently the experience never gets really good as opposed to native iOS development where once you get to a certain level you don't spend that much time chasing weird build errors.
sergiotapia 7y ago
You are not wrong. It is a nightmare to maintain, and if you already took the leap you best keep that project updated as soon as possible or you will be fucked beyond repair. There has to be a better way to write mobile applications. Is that Ionic? I don't know.
- latchkey 7y ago
  Seriously, take a stab at building an app in Flutter.
  - verttii 7y ago
    Agreed, I switched to Flutter from React Native. Although I don't particularly like Dart lang, everything just works way better on Flutter.
  - bsaul 7y ago
    Never had performance issues on scroll ? The demo app on the ios app store has lagging scroll performance for a simple app on an iphone X
    - latchkey 7y ago
      I don't have any pages that scroll. =) It is all single pages for now. That said, who knows what the demo app was done with. If there is lagging scroll performance, it could be a lot of things. I will say that figuring out where the performance problems are would be pretty enjoyable in IDEA. The tooling there for performance is quite good.
- Razengan 7y ago
  If you’re going to remain within Apple platforms, try SwiftUi: https://developer.apple.com/tutorials/swiftui/ https://developer.apple.com/tutorials/swiftui/ There may be a chance of it being adapted for other platforms in the future.
  - bsaul 7y ago
reimertz 7y ago
Is that really true? ‘react-native init AppName’ and your ready to go? What is wrong with react natives official documentation? I think what many mess up(me included) is to look at the wrong version of the documentation. I guess that could be a little bit more obvious. edir: oh, typescript! Yeah, that is a little bit more troublesome; https://facebook.github.io/react-native/blog/2018/05/07/using-typescript-with-react-native https://facebook.github.io/react-native/blog/2018/05/07/usin...
- coldtea 7y ago
  >Is that really true? ‘react-native init AppName’ and your ready to go? If you already know React/Redux/etc, perhaps. Else "Ready to go" after reading about several concepts, libraries, and systems and getting how the work together, what performance pitfalls they have, etc...
  - reimertz 7y ago
    If you would initiate a Swift app or any other for type of app for that matter, what language/frameworks give you a complete solution with state etc done for you. I guess I’m asking; what other solution have you found that solves everything for you?
    - coldtea 7y ago
      My point wasn't from someone who expects the language/environment to "solve everything". It was from someone familiar with GUI programming, who wants to try doing it in React Native and suddenly finds tons of new concepts to keep in mind (compared to common native GUI frameworks/libs).
    - machello13 7y ago
      If you want to build an iOS app with Swift, the built-in frameworks give you everything you need. Swift as a language, Cocoa Touch (includes Foundation as a kind of standard library and UIKit or SwiftUI for the UI stuff), Xcode for the IDE and build system. There's one source of documentation, Apple, and there's years of third-party documentation all over the internet. You can bring in libraries of course, but even for a large iOS project it's unlikely (and probably unnecessary) to have more than a handful.

by bsaul 7y ago

latchkey 7y ago

You are right. This is part of what made me try Flutter for a new app over RN. While it isn't perfect (no tooling is), the initial user experience is pretty good and the documentation is constantly updated as the product matures.

paulintrognon 7y ago
I understand they are using the Dart langugage? Was it hard to master?
- latchkey 7y ago
  Super easy if you know JS/TS and turns out that I actually quite like it.
  - virtualwhys 7y ago
    What's missing? TS has quite a few interesting language features that I assume Dart is missing (seems Dart has the reputation of being a Java-like language, with all the boilerplate that that entails).
    - latchkey 7y ago
      Probably my largest complaint is the need to use codegen for the json stuff. Sure you can type it all out by hand, but the codegen really does automate a lot of it for you. I have intentionally kept my very specific use case mobile app very very simple and not gone deep on the magic edge cases. It is a private app and will never be on the store. It is basically used as a QR code scanner to track equipment. I'm sure that if you have a lot deeper/larger apps you'd find more to complain about, but so far I'm happy enough with going from zero to full fledged app in about a month of work. IMHO, the boilerplate argument with Java is kind of outdated (Project Lombok and modern java solve a lot of that).
bsaul 7y ago
I used to be into flutter (theorically), but after seeing some bugs and performance issues, i’m now thinking the best combination would be : - write once and compile all business logic (and server and fs i/o ideally) into a portable independant libray, either in something that compiles to C, or wasm (once it’s more mature) - write native UI code using native tooling, and call the business logic library from there. But i haven’t settled yet on the ideal PL to write that library and have it interface easily on both android and ios.
- rabenblut 7y ago
  This is the approach used with Kotlin multiplatform development. I suspect it will be the best way going forward, other approaches all have serious issues. https://kotlinlang.org/docs/reference/multiplatform.html https://kotlinlang.org/docs/reference/multiplatform.html
- izacus 7y ago
  This is the approach we took at my current and previous mobile projects and has proven to be very effective (we chose C++ due to toolchain maturity over all platforms): - It forces you to think about your business logic vs. UI structure. - It forces you to make your core logic library easily testable. - Since you can deploy the core logic library anywhere, you get native, no Electron bullshit, support for pretty much all major operating systems at a cost of running a CI on all compilers to catch non-portable parts of C++ quickly. - The users get UI that's built for their platform with it's own quirks and doesn't burn 500MB of RAM. - Using a serializable and portable message standard (we opted for Protobufs) to communicate between logic library and UI part makes deployment to server easy as well. Biggest issues? - Getting inflexible people to learn anything other than JavaScript. - Getting slow compile times under control. - Getting CI coverage to the point where it catches developers accidentally adding Apple or Linux specific headers into codebase. - Learning to be conservative enough to not trust the platform and ship our own libraries. Even basic ones like SQLite.
  - alien1993 7y ago
    How do you achieve this? Are you using some framework like Qt? Or is it custom?

dep_b 7y ago

I have the same experience trying to use it myself. And this stacked on top of the mess that the Javascript, Android and iOS worlds themselves already can be sometimes. One of the apps I maintained got rewritten in React Native but I couldn't get it to build. One of the devs stepped in and helped it. "Oh just retry it a few times it'll work eventually" and sure it did. So apparently the experience never gets really good as opposed to native iOS development where once you get to a certain level you don't spend that much time chasing weird build errors.

sergiotapia 7y ago

You are not wrong. It is a nightmare to maintain, and if you already took the leap you best keep that project updated as soon as possible or you will be fucked beyond repair. There has to be a better way to write mobile applications. Is that Ionic? I don't know.

latchkey 7y ago
Seriously, take a stab at building an app in Flutter.
- verttii 7y ago
  Agreed, I switched to Flutter from React Native. Although I don't particularly like Dart lang, everything just works way better on Flutter.
- bsaul 7y ago
  Never had performance issues on scroll ? The demo app on the ios app store has lagging scroll performance for a simple app on an iphone X
  - latchkey 7y ago
    I don't have any pages that scroll. =) It is all single pages for now. That said, who knows what the demo app was done with. If there is lagging scroll performance, it could be a lot of things. I will say that figuring out where the performance problems are would be pretty enjoyable in IDEA. The tooling there for performance is quite good.
Razengan 7y ago
If you’re going to remain within Apple platforms, try SwiftUi: https://developer.apple.com/tutorials/swiftui/ https://developer.apple.com/tutorials/swiftui/ There may be a chance of it being adapted for other platforms in the future.
- bsaul 7y ago

reimertz 7y ago

Is that really true? ‘react-native init AppName’ and your ready to go? What is wrong with react natives official documentation? I think what many mess up(me included) is to look at the wrong version of the documentation. I guess that could be a little bit more obvious. edir: oh, typescript! Yeah, that is a little bit more troublesome; https://facebook.github.io/react-native/blog/2018/05/07/using-typescript-with-react-native https://facebook.github.io/react-native/blog/2018/05/07/usin...

coldtea 7y ago
>Is that really true? ‘react-native init AppName’ and your ready to go? If you already know React/Redux/etc, perhaps. Else "Ready to go" after reading about several concepts, libraries, and systems and getting how the work together, what performance pitfalls they have, etc...
- reimertz 7y ago
  If you would initiate a Swift app or any other for type of app for that matter, what language/frameworks give you a complete solution with state etc done for you. I guess I’m asking; what other solution have you found that solves everything for you?
  - coldtea 7y ago
    My point wasn't from someone who expects the language/environment to "solve everything". It was from someone familiar with GUI programming, who wants to try doing it in React Native and suddenly finds tons of new concepts to keep in mind (compared to common native GUI frameworks/libs).
  - machello13 7y ago
    If you want to build an iOS app with Swift, the built-in frameworks give you everything you need. Swift as a language, Cocoa Touch (includes Foundation as a kind of standard library and UIKit or SwiftUI for the UI stuff), Xcode for the IDE and build system. There's one source of documentation, Apple, and there's years of third-party documentation all over the internet. You can bring in libraries of course, but even for a large iOS project it's unlikely (and probably unnecessary) to have more than a handful.