To demonstrate that the same story has been ashtray posted another 2 times within a span of roughly a week. It has little value to repost it a 3rd time again.
Edit: interestingly, the most recent re-post did gain some traction this time!
I tried Nativescript, React Native and Ionic. I've had previous experience with both React and Angular. I found Ionic to have the most enjoyable and cogent end-to-end experience amongst the three.
Interopt with Nativescript and other libs was hard, React Native didn't support Typescript as a first-class citizen (which as a prereq of mine) and the developer tooling wasn't as mature as the Ionic/Cordova/Angular cli(s) were.
A lot of noise around Flutter but haven't given it a try yet, but I'm weary because of defining views-as-code rather then a flavor of JSX/Angular Templates.
For a stupid guy like me who needs the compiler, flutter is the most sane experience I have ever had in the UI ecosystem (except Qt and JavaFX). The view as code is really really better (for me).
Desktop and web versions are in the making. So we will be able to make all of them from a single codebase.
I am really dependent on static types so take my take on this with a grain of salt :)
Flutter is more mature right from the Dev tools to the overall ecosystem. The types are first class and make it a joy to use. Not to mention the libraries are better quality and stuff works even when you upgrade. I could never work on any RN project for more than 1-2 weeks without something or the other breaking and me cursing out aloud for the really shitty (again subjective) state of things. I am used to having codebases just keep on working almost forever.
> I found Ionic to have the most enjoyable and cogent end-to-end experience amongst the three.
Agreed, though I'd love to use Ionic with Scala.js in place of TypeScript (which is great, but doesn't give me the same if-it-compiles-it-works confidence as Scala does, not to mention batteries-included standard library).
Hopefully technology will emerge that allows one to write once/run everywhere in preferred-language on all major platforms. Compromises seem to abound with currently available options.
Scala.js sounds really interesting. There's no reason you shouldn't be able to use it with Ionic as of Ionic 4, since we generally now support whatever framework you want to use (not just Angular anymore)
I don't think that's true. TypeScript's type system is very advanced, and has most of the features you need for type-safe development if you use strict mode (which is the default for projects created with `tsc --init`). It has ADTs, null safety, exhaustiveness checking and the LSP tooling is better than any other language I've tried. The biggest feature that's missing from Scala is HKTs, and even those can be faked in TS.
This is by design, and rather well explained in the typescript documentation: the type system is based on structural subtyping, which seems like a good tradeoff to me (but of course, as any design choice, not everyone should agree, and it's fine).
I'd be hard pressed to say ADTs are first class citizens in Typescript. If anything, seems more like a hack over some interface primitives to me.
I miss having a solid advanced type system like in Haskell when using something like Typescript or Dart. Typescript feels mostly like Microsoft's attempt on converting Javascript to align more with C# to me.
(Ionic co-founder here) glad you're enjoying Ionic, we're working on a ton of stuff to improve it even more right now. Have you tried Capacitor yet, our Cordova alternative?
Not necessarily. Cordova plugin compatibility was designed in from the start. Unfortunately, some plugins relied on more obscure aspect s of Cordova and don’t work. We keep an updated list of incompatible plugins here: https://capacitor.ionicframework.com/docs/cordova/known-inco...
Capacitor 2.0 should fix the XSS issue that Cordova has always had, and split the code between privileged code (backendish) and UI code.
Capacitor 1.1 turned off Electron security protections to make things work as they always have. As a new project, I was hoping for more.
In Capacitor 2 you have the opportunity to have the business logic run in a separate thread than the UI, and add the privileged code there. And such logic would not need to hold up the UI allowing for a smoother app.
One XSS in an iPhone app and maybe they own that app. One XSS in an Electron app and they wipe out your whole PC and life. There is a reason why Electron changed the defaults.
Should have made the distinction clearer but I was just saying JSX _and_ Angular specific templates. The fact of JSX being an abstraction over the React API that equates to what the DOM _should_ look like is must easier to grep then defining them as literal code, imo.
When I used React Native with Typescript (this was about a year ago) the initial setup to get all of the types playing well together either wasn't clear from the documentation or I ended up debugging/writing custom definitions to get things to work. It just felt sidelined or treated as a second class citizen, but I feel like this has been a common theme throughout the life of React generally.
> equates to what the DOM _should_ look like is must easier to grep then defining them as literal code, imo
It's a common view but really quite a funny form of path dependence / mental fixedness. The fact that html elements have been defined with angle brackets is essentially historical accident. It's just a simple hierarchical structure that can be in any notation and any given programming language can happily support this already without new syntax. Yet because of the history, we feel more comfortable with some angle brackets and so we have all this redundant syntactic complexity in jsx/tsx which we would never design without the history.
I'd encourage you to be open minded for going to all code because although there will be an acclimatisation period as you break the historical connection, those familiar angle brackets are totally superfluous.
I've worked with frameworks like GWT and Vaadin enough to know I prefer the DOM way of doing things over visualizing the view through code. Hell, I've used the React programmatic API before I used JSX...never going back.
I much prefer React Native's (React) paradigm over Flutter's, but as a platform Flutter is just a lot more robust in my experience. Everything just works on it while RN has all kinds of weird quirks and issues, particularly when using libraries that have native code.
I chose to give up on RN at 0.59 and focus my efforts on getting really fluent at Flutter instead.
Still a few bugs to iron out (esp. with React Native Maps) - but good work to the team on this one. The autolinking is a game changer. Also looking forward to giving Hermes a spin!
in real ionic is mainly about Angular while Quasar is mainly about Vue, so React Native must be mainly about React, which happens to be the largest framework comparing to Angular and Vue these days.
I just really can't see RN gaining much traction outside of experimental/small apps. You very much still need experienced mobile devs to debug the multitude of Java/kotlin/XCode/Android issues that come up because of how fragile the entire workflow is. Running a business on that is non-starter.
I have to agree with you. Moreover, you also go through plenty of pain to make the app work well on both platforms, with surprisingly much platform specific code.
While I am not necessarily an advocate of React Native, I don't think your point is fair. React Native never promises that its users can "write once and run anywhere".
Chuckled at this. But honestly I find debugging the “native” side of RN apps much more painful than any type of web development I’ve had experience with. Then again perhaps I’ve never worked with a 100% pure native app so would love to hear some more perspectives on this.
IDK what you mean but there so many things much easier and straightforward with web-based tech, eg sane layout systems like flexbox are way superior than anything native frameworks have to offer.
Yep, I just upgraded my RN app and their official upgrade strategy is to go line by line and update your project with the changes they made between versions.
The Discord devs use RN and their app is anything but experimental or small. And there are by far not the only one (Skype, Instagram, Wix, UberEats, Tesla, Baidu, Salesforce).
Native devs don’t like RN because the mobile dev supply gets bigger which hurts their market value. That’s the real reason of your post, spreading FUD.
RN has its limitations but for 80% of apps it’s absolutely fine.
Please stop with the market value/FUD attacks, they are nonsense and childish. You clearly have an axe to grind.
I don't like RN because I have had to sunset multiple large projects in RN. Javascript is a mess for mobile development. The interaction between the native layer is a mess. Hell, it's still not even a 1.0 release yet - smart CTOs would be insane to suggest it as a tool. Just look at the upgrade guides they post - a mess.
62 comments
[ 3.9 ms ] story [ 118 ms ] thread- https://news.ycombinator.com/item?id=20344705 - https://news.ycombinator.com/item?id=20360060
Edit: interestingly, the most recent re-post did gain some traction this time!
Interopt with Nativescript and other libs was hard, React Native didn't support Typescript as a first-class citizen (which as a prereq of mine) and the developer tooling wasn't as mature as the Ionic/Cordova/Angular cli(s) were.
A lot of noise around Flutter but haven't given it a try yet, but I'm weary because of defining views-as-code rather then a flavor of JSX/Angular Templates.
JSX is just syntactic sugar, it's not a templating language. You could write yourself a JSX syntax extension for Dart, it'd be the same thing really.
Edit: More succinctly, JSX desugars to method calls
I am really dependent on static types so take my take on this with a grain of salt :)
Flutter is more mature right from the Dev tools to the overall ecosystem. The types are first class and make it a joy to use. Not to mention the libraries are better quality and stuff works even when you upgrade. I could never work on any RN project for more than 1-2 weeks without something or the other breaking and me cursing out aloud for the really shitty (again subjective) state of things. I am used to having codebases just keep on working almost forever.
Agreed, though I'd love to use Ionic with Scala.js in place of TypeScript (which is great, but doesn't give me the same if-it-compiles-it-works confidence as Scala does, not to mention batteries-included standard library).
Hopefully technology will emerge that allows one to write once/run everywhere in preferred-language on all major platforms. Compromises seem to abound with currently available options.
I miss having a solid advanced type system like in Haskell when using something like Typescript or Dart. Typescript feels mostly like Microsoft's attempt on converting Javascript to align more with C# to me.
Also see some past blog posts with more: https://ionicframework.com/blog/announcing-capacitor-1-0/
Capacitor 1.1 turned off Electron security protections to make things work as they always have. As a new project, I was hoping for more.
In Capacitor 2 you have the opportunity to have the business logic run in a separate thread than the UI, and add the privileged code there. And such logic would not need to hold up the UI allowing for a smoother app.
One XSS in an iPhone app and maybe they own that app. One XSS in an Electron app and they wipe out your whole PC and life. There is a reason why Electron changed the defaults.
As someone that uses TypeScript to death and works on react native as my job pretty happily, please explain this?
Also JSX is absolutely not a templating language, it's an extremely thin layer over JS.
When I used React Native with Typescript (this was about a year ago) the initial setup to get all of the types playing well together either wasn't clear from the documentation or I ended up debugging/writing custom definitions to get things to work. It just felt sidelined or treated as a second class citizen, but I feel like this has been a common theme throughout the life of React generally.
It's a common view but really quite a funny form of path dependence / mental fixedness. The fact that html elements have been defined with angle brackets is essentially historical accident. It's just a simple hierarchical structure that can be in any notation and any given programming language can happily support this already without new syntax. Yet because of the history, we feel more comfortable with some angle brackets and so we have all this redundant syntactic complexity in jsx/tsx which we would never design without the history.
I'd encourage you to be open minded for going to all code because although there will be an acclimatisation period as you break the historical connection, those familiar angle brackets are totally superfluous.
I chose to give up on RN at 0.59 and focus my efforts on getting really fluent at Flutter instead.
Stopped reading there.
in real ionic is mainly about Angular while Quasar is mainly about Vue, so React Native must be mainly about React, which happens to be the largest framework comparing to Angular and Vue these days.
Not discrediting RN, just calling out that the number of downloads is a terrible proxy metric for quality.
I understand this is not a trivial problem, just comparing my experiences with RN with Flutter.
but so are a bunch of other things that are easier to use
https://react-native-community.github.io/upgrade-helper/?fro...
Native devs don’t like RN because the mobile dev supply gets bigger which hurts their market value. That’s the real reason of your post, spreading FUD.
RN has its limitations but for 80% of apps it’s absolutely fine.
https://medium.com/airbnb-engineering/sunsetting-react-nativ...
Please stop with the market value/FUD attacks, they are nonsense and childish. You clearly have an axe to grind.
I don't like RN because I have had to sunset multiple large projects in RN. Javascript is a mess for mobile development. The interaction between the native layer is a mess. Hell, it's still not even a 1.0 release yet - smart CTOs would be insane to suggest it as a tool. Just look at the upgrade guides they post - a mess.