4 ms·

Our app is much better written in RN than the one i built in native code. RN doesn't have native bugs - they are worked around unlike pure native development wh

by ex3ndr 6y ago

Our app is much better written in RN than the one i built in native code. RN doesn't have native bugs - they are worked around unlike pure native development when you have to live with them. Have you tried to customize UINavigationController to run on every version of iOS? Almost all projects i have seen eventually replaced it altogether with a custom implementation. Typescript IS better programming language and much more powerful than, say swift. I can't see whats so special about swift comparing to typescript. I was coding for 5 years on swift and know what it is. Tests are much easier, typesystem is much more powerful and flexible. Compilation times are instant comparing to native. Please, don't rant on JS ecosystem and "dependencies". To build native app you download 30GB xcode, clang and god know how many different libraries and runtimes. JS just not install them globally and 90% of deps are for development only. Our app have 700kb of compiled JS. I have NEVER ever able to fit my kotlin/swift app to 700kb of compiled binary (excluding libraries).

dep_b 6y ago
Can’t remember the last time I had problems with UINavigationController besides the introduction of large titles but I can imagine you need to roll your own sometimes. > Typescript IS better programming language and much more powerful than, say swift. Nobody would use Typescript if it wasn’t the least bad way to deal with Javascript. > Tests are much easier Good because you’re going to need to write a shit ton just to verify everything that is verified for free by the compiler in Swift. > typesystem is much more powerful In what way? > and flexible. ...because it’s not that strongly typed > Compilation times are instant comparing to native. Objective-C was much faster too, because it moved a whole class of bugs to runtime instead of compile time > don't rant on JS ecosystem and "dependencies" We could just as well shut down HN if you’re not even legally allowed to rant on the bat shit crazy JS dependency trees anymore. > To build native app you download 30GB xcode, clang and god know how many different libraries and runtimes. Actually it’s a relatively small application with a shit ton of simulators shipped with it. So apart from the dramatically inflated download size (like that was even needed given it’s real size) you probably already knew this yourself. But nothing better than a whataboutism to cover up an inconvenient truth. —————— I actually got suckered into a point by point rebuttal where I already know where RN shines compared to native dev: Reactive as it’s basic pattern and hot UI reloads. Nobody would use Typescript if it wasn’t for JS compatibility. Python and Erlang are similarly weak typed, easy to write tests for and way more mature than JavaScript based language will ever be.
- ex3ndr 6y ago
  This is so sad that i wasted time explaining something while you don't even know that typescript is statically typed language. That's the whole reasoning behind typescript. It is more powerful because it flexible because it's typesystem is turing complete and you can describe literally anything in it. Everything is strongly typed. It is powerful because you can express anything unlike swift/java/kotlin where you are forced for some subset of what can do in typescript. For example, good luck enforcing string variable to specific values only. Good luck working with two classes that have same fields but don't have common interface with them. It is the fact - you can do much less in this languages than in TS. Test also is the easiest thing to do in ts: i am coding for 20+ years and jest is simplest solution for tests ever. You just can't compare this to a shitshow of native testing (one is xcode because of xcode, another is android well because it is android). I don't understand how python or erlang relate to discussion of ts on rn. You advising to write ios apps in erlang? While you wasn't rational, i still tried to calculate how much i need to install to build anything with plain clang. I got docker with ubuntu 20.20, base image is 78MB. Executed: 'run apt-get update && apt-get install -y clang python3' now image is 700MB. And i still don't have llvm, debuggers and anything i need. The docker image of golang alpine is 350MB after downloading. Alpine itself is 5MB. So how small is small?
  - dep_b 6y ago
    Typescript is a strongly typed language built on top of one that isn't, just like Objective-C gets all of the run-time problems that C has if you wanted them or not. There is no such thing as a free lunch. And if you didn't understand my argument about the fact that Typescript only exists and is used because people are forced to deploy to Javascript-only targets and are desperate to use something that is a bit more sane to work with I don't know what else to say. I've used Typescript, it has some great ideas I would love to see in Swift but at the end of the day the only thing it is is an extension of Javascript, which includes all of Javascript's failings. If you like languages that have the properties of Javascript, there are better languages out there. Nobody would use Javascript if given an equal choice between all alternatives. Javascript is used because you have no other choice if you want to be compatible with browser-only targets.
sandGorgon 6y ago
Wanted to get your thoughts on tuning for performance on RN. We are native platform specialists..but have been seriously looking at RN and Typescript. App sizes is a definite concern since we build for Indian markets. What about assets? Do they bloat up more than on native.
- ex3ndr 6y ago
  I stopped measuring sizes unfortunatelly, since nowadays you can cut heavy native part to pieces and deliver them separately and native part is out of my concern. We use webrtc anyway, so it won't be super light. I could recommend RN if you can tolerate slightly lower performance (because of the stuff i mentioned earlier) and beware that infinite lists are absolute shitshow (we built our own). If you are native specialists you can write bindings by your own and replace only parts of the app with RN. Assets are stored the same way as in native, not sure how you can do something with them.
  - sandGorgon 6y ago
    About infinite lists...did you try Flipkart's RecyclerListView ? https://github.com/Flipkart/recyclerlistview https://github.com/Flipkart/recyclerlistview But most importantly this question - do you envision that building React Native apps requires one to write wrappers for native at some point ? Or is it all abstracted away by now.
    - ex3ndr 6y ago
      It depends, for us we write some wrappers in Kotlin and Swift, but this is irrelevant to team performance - this could take time, but 90% of the time work is done in typescript. You want to have some folks that can do hacking on native level. We built our own since there are much better frameworks on native side - asyncdisplaykit on iOS and Litho on Android. This library claims 60fps without actually measuring it or using very simple layout. We are doing messenger and layouts are really heavy for rendering and rn have it’s limitations, more importantly we reuse lists between screens, we have our own micro react inside that renders mostly static content to json and send it to native side. This is overkill for some, but not for us. We would have done the same without RN anyway.

by ex3ndr 6y ago

dep_b 6y ago

Can’t remember the last time I had problems with UINavigationController besides the introduction of large titles but I can imagine you need to roll your own sometimes. > Typescript IS better programming language and much more powerful than, say swift. Nobody would use Typescript if it wasn’t the least bad way to deal with Javascript. > Tests are much easier Good because you’re going to need to write a shit ton just to verify everything that is verified for free by the compiler in Swift. > typesystem is much more powerful In what way? > and flexible. ...because it’s not that strongly typed > Compilation times are instant comparing to native. Objective-C was much faster too, because it moved a whole class of bugs to runtime instead of compile time > don't rant on JS ecosystem and "dependencies" We could just as well shut down HN if you’re not even legally allowed to rant on the bat shit crazy JS dependency trees anymore. > To build native app you download 30GB xcode, clang and god know how many different libraries and runtimes. Actually it’s a relatively small application with a shit ton of simulators shipped with it. So apart from the dramatically inflated download size (like that was even needed given it’s real size) you probably already knew this yourself. But nothing better than a whataboutism to cover up an inconvenient truth. —————— I actually got suckered into a point by point rebuttal where I already know where RN shines compared to native dev: Reactive as it’s basic pattern and hot UI reloads. Nobody would use Typescript if it wasn’t for JS compatibility. Python and Erlang are similarly weak typed, easy to write tests for and way more mature than JavaScript based language will ever be.

ex3ndr 6y ago
This is so sad that i wasted time explaining something while you don't even know that typescript is statically typed language. That's the whole reasoning behind typescript. It is more powerful because it flexible because it's typesystem is turing complete and you can describe literally anything in it. Everything is strongly typed. It is powerful because you can express anything unlike swift/java/kotlin where you are forced for some subset of what can do in typescript. For example, good luck enforcing string variable to specific values only. Good luck working with two classes that have same fields but don't have common interface with them. It is the fact - you can do much less in this languages than in TS. Test also is the easiest thing to do in ts: i am coding for 20+ years and jest is simplest solution for tests ever. You just can't compare this to a shitshow of native testing (one is xcode because of xcode, another is android well because it is android). I don't understand how python or erlang relate to discussion of ts on rn. You advising to write ios apps in erlang? While you wasn't rational, i still tried to calculate how much i need to install to build anything with plain clang. I got docker with ubuntu 20.20, base image is 78MB. Executed: 'run apt-get update && apt-get install -y clang python3' now image is 700MB. And i still don't have llvm, debuggers and anything i need. The docker image of golang alpine is 350MB after downloading. Alpine itself is 5MB. So how small is small?
- dep_b 6y ago
  Typescript is a strongly typed language built on top of one that isn't, just like Objective-C gets all of the run-time problems that C has if you wanted them or not. There is no such thing as a free lunch. And if you didn't understand my argument about the fact that Typescript only exists and is used because people are forced to deploy to Javascript-only targets and are desperate to use something that is a bit more sane to work with I don't know what else to say. I've used Typescript, it has some great ideas I would love to see in Swift but at the end of the day the only thing it is is an extension of Javascript, which includes all of Javascript's failings. If you like languages that have the properties of Javascript, there are better languages out there. Nobody would use Javascript if given an equal choice between all alternatives. Javascript is used because you have no other choice if you want to be compatible with browser-only targets.

sandGorgon 6y ago

Wanted to get your thoughts on tuning for performance on RN. We are native platform specialists..but have been seriously looking at RN and Typescript. App sizes is a definite concern since we build for Indian markets. What about assets? Do they bloat up more than on native.

ex3ndr 6y ago
I stopped measuring sizes unfortunatelly, since nowadays you can cut heavy native part to pieces and deliver them separately and native part is out of my concern. We use webrtc anyway, so it won't be super light. I could recommend RN if you can tolerate slightly lower performance (because of the stuff i mentioned earlier) and beware that infinite lists are absolute shitshow (we built our own). If you are native specialists you can write bindings by your own and replace only parts of the app with RN. Assets are stored the same way as in native, not sure how you can do something with them.
- sandGorgon 6y ago
  About infinite lists...did you try Flipkart's RecyclerListView ? https://github.com/Flipkart/recyclerlistview https://github.com/Flipkart/recyclerlistview But most importantly this question - do you envision that building React Native apps requires one to write wrappers for native at some point ? Or is it all abstracted away by now.
  - ex3ndr 6y ago
    It depends, for us we write some wrappers in Kotlin and Swift, but this is irrelevant to team performance - this could take time, but 90% of the time work is done in typescript. You want to have some folks that can do hacking on native level. We built our own since there are much better frameworks on native side - asyncdisplaykit on iOS and Litho on Android. This library claims 60fps without actually measuring it or using very simple layout. We are doing messenger and layouts are really heavy for rendering and rn have it’s limitations, more importantly we reuse lists between screens, we have our own micro react inside that renders mostly static content to json and send it to native side. This is overkill for some, but not for us. We would have done the same without RN anyway.