27 ms·

I regret using Ionic for app development

105 points by benatkin 4y ago

crooked-v 4y ago
For me, Flutter is a really good project that I'll never use because I'll always expect Google to suddenly kill it in a year or two.
- the_only_law 4y ago
  I’m frankly surprised Dart made a come back at all. I remember hearing a good bit about it and it’s lofty ambitions years ago, but then it seems like it kinda just fell off until Flutter.
  - resoluteteeth 4y ago
    In my opinion it was a huge mistake for them to use dart for flutter. I suspect that there would be a lot more excitement around flutter if it used javascript or kotlin (since a lot of android developers are already using kotlin). (They gave some explanation of why they picked dart at the time but it wasn't at all convincing.)
    - cutler 4y ago
      The original goal was for Dart to replace JS in Chrome.
      - dragonwriter 4y ago
        The original goal was for Dart to be generally adopted by browsers, more specifically, not for it to be Chrome-specific.
        andsoitis 4y ago
        If true, by what stretch of the imagination did Google think browser vendors would adopt Dart?
        ShadowBanThis01 4y ago
        Arrogance is no stretch for Google.
        pjmlp 4y ago
        By the same strech that they pushed PNaCL that others refused to adopt. Which is ironic, given the fizzling market share from Firefox, and how with exception of Safari, all other browsers are based on Chrome. So there is a certain irony that WASM is anyway driven by Google interests.
        SideburnsOfDoom 4y ago
        > they pushed PNaCL that others refused to adopt. Well, they all did eventually adopt WebAssembly, so this effort did get somewhere, eventually.
        pjmlp 4y ago
        A pyrrhic victory for Mozilla.
  - pjmlp 4y ago
    AdWords kept it alive until it got chosen by Flutter.
- benatkin 4y ago
  It's based on another project that it seemed like Google was going to kill, Dart. I don't think I have good enough priors for this situation but I certainly understand your concern.
  - pjmlp 4y ago
    The only reason why Dart didn't die was Ad Words team, they had just migrated from GWT into AngularDart when the whole thing imploded, so they rescued the Dart project as it was easier than yet another rewrite into something else.
- david422 4y ago
  Been playing around with Flutter the last few months. Still has some rough edges, but the ability to target every major platform with a single code base is very cool. The way the UI is laid out with the widget tree is new to me but fun to learn and seems like a very scalable way to build a UI.
  - crooked-v 4y ago
    The tree to me feels a lot like React's model, but without the advantage of JSX to compactify the syntax.
    - benatkin 4y ago
      React, Vue, and Svelte are the ones most attached to angle brackets for building apps now. I like HTML Custom Elements and surprisingly the slot mechanism often isn't the best way to do things. You can just use functions that call createElement a lot of the time or a library like Snabbdom. Templates are more for static content. VsCode, Atom, and CodeMirror all do a lot with the web platform without a high angle bracket to line of code ratio. Web app staples like Floating UI and split-grid don't suffer from a lack of angle brackets.
      - crooked-v 4y ago
        It's not the specific angle-bracket syntax that matters, but that there's a ton of verbosity around widgets creation, children arrays, and other properties that could have been massively reduced with the right transformations or even just some decorator-style syntax.
      - c-hendricks 4y ago
        Does the flutter vscode plugin still insert fake comments telling you what widget this random parentheses in a sea of other parentheses is the end of?
- scarface74 4y ago
  Google has already all but abandoned Flutter for their own apps and said they were going to focus on using the native iOS toolkit. https://9to5google.com/2021/10/10/google-ios-apps-native/ https://9to5google.com/2021/10/10/google-ios-apps-native/
  - darren_ 4y ago
    This link says absolutely nothing about Flutter usage. It's about apps that are already written in native iOS code, which are currently using custom Material Design components (which are mostly/entirely in obj-c), and that going forward those custom Material components are going to be phased out and apps will use standard UIKit elements instead. This tells you absolutely nothing about Google's commitment to flutter.
    - scarface74 4y ago
      So it says nothing about using Flutter even though the entire purpose of Flutter is to write cross platform apps and Google is moving toward not writing cross platform apps and are using standard UIKit components. They also aren’t using Dart and are using Objective C. But that doesn’t mean they are moving away from Flutter for first party apps?
      - Apocryphon 4y ago
        They aren't moving away because these Google apps weren't using Flutter in the first place. The only ones that were are like, Google Pay and Google Classroom. https://flutter.dev/showcase/google-pay https://flutter.dev/showcase/google-pay https://flutter.dev/showcase/google-classroom https://flutter.dev/showcase/google-classroom
        scarface74 4y ago
        Is that really the argument you want to make? That Google doesn’t even dog food their own products for their most popular apps?
- TobyTheDog123 4y ago
  Flutter is a really good start, it's the closest thing I've found to what I'm looking for. I don't even think Google's going to kill it anytime soon. I don't like Dart though, it has an over-reliance on codegen, and I far prefer JSX's XML syntax than the constructor syntax Flutter uses for its layouts.
- ctvo 4y ago
  caniuseflutterwithoutdartyet.com Forcing me to use Dart because you made the poor decision of developing it, and now need a reason to continue funding it if I want to use Flutter? No thanks.
- IshKebab 4y ago
  I don't think that's very likely. Google is clearly still investigating heavily in Flutter, they use it for some of their own apps and devices, and they are clearly aware that the native Android API is not very good. The only thing that would make me suspect that they would kill it is the ongoing performance issues due to shader compilation. But they have actually started fixing that properly by creating a new renderer that doesn't do on-demand shader compilation. The developer tools that Google has released generally don't get suddenly killed. They mostly kill user facing apps that aren't very popular. And Reader.
hbcondo714 4y ago
> The only viable option today, in my opinion, is Flutter I guess it is viable in that Flutter targets, iOS / Android, web and desktop with a "single codebase" but the author of the article isn't aiming for all those platforms.
tengbretson 4y ago
The writing has been on the wall for Ionic since like 2015. If you're a dev still supporting an Ionic codebase today you have my sympathy.
deleted 4y ago
[deleted]
ChicagoDave 4y ago
There’s a well-established and highly supported alternative: https://dotnet.microsoft.com/en-us/apps/maui https://dotnet.microsoft.com/en-us/apps/maui
- samayylmao 4y ago
  I'm not sure Maui has been production ready long enough. It has not even been GA for a year yet.
- axlee 4y ago
  Has anyone here have experience with this? We're currently looking at a forward-looking stack for our multi-platform app, and to be fair the general feedback we read is that they all suck in certain ways. What's the least bad out there?
  - tailspin2019 4y ago
    My experience: MAUI is not yet polished/complete enough for production (in my experience trying to use it for both iOS and macOS apps).
  - datavirtue 4y ago
    If I wrote an article about trying to develop in Xamarin.Forms (MAUI) it would read like the Flutter article that brought us here. Way better than Flutter but still needs work. I spent years on the bleeding edge and mostly ended up with builds failing and other nagging problems. Drained all of my energy. I went back to web dev and have been using Vue 3. Pry it from my cold dead fingers.
  - mustacheemperor 4y ago
    I greatly enjoy building in Maui. By weird chance my first programming gig was in UWP and it’s a pleasure to be working in C# .NET again, able to build UIs with xaml and dynamically out of the code, but with a bigger prospective audience than “people who install uwp apps.” That said, I’m only playing with it right now - I’m doing some weekend projects hacking against LLM APIs and it’s a great way to stand up a simple app quickly that runs on my phone and debugs at the computer and could theoretically one day be on the mobile app stores. But I would tentatively agree with other replies that it might be a little early for commercial adoption. I haven’t encountered any show-stopping bugs or limitations yet, but at the same time when researching for troubleshooting and bug fixing I will find git issues that were resolved less than a year ago for things like images not displaying on android. The built-in MediaElement for video playing only just came out and doesn’t support true full screen playback yet. The other factor from it being new is just the lack of community discourse about it. The docs are great but you’re not going to find many discussion on git and SO about it yet, and the search space is cluttered with results about Xamarin.Forms that are sometimes relevant and sometimes completely not. So IMO that means people should give it a try! But maybe hack on it first before committing to shipping commercial software. Has MS released a commercial/production app built on Maui yet? Are they eating their own dogfood?
preommr 4y ago
> They’re missing that the market has moved from this kind of mindset. If you look at Dribbble, you can’t find mobile design dedicated for iOS and another set dedicated to Android. Interesting that this idea is mainstream when HN hivemind will frequently complain about how bad it is that nothing looks native anymore.
tylerchurch 4y ago
As someone who has deployed projects to the App Store/Play Store in both React Native and Ionic for my day job - Ionic is a breath of fresh air compared to React Native. Ionic+Capacitor delivers on the promise to leverage existing web development knowledge to build mobile apps. React Native somewhat delivers on the promise. But the whole ecosystem loves breaking changes, and debuggability is a nightmare. There are more libraries for native libraries, but the headache of actually integrating them is significant. Capacitor, in comparison, seems very well designed. Where web tech stops and native tech starts is very clear.
- mattnewton 4y ago
  I have only just started working with react native, but I will say the new expo development workflow is pretty great.
  - tylerchurch 4y ago
    Expo makes React Native fairly tolerable. Just don't go outside the guardrails, there lies pain.
    - dbetteridge 4y ago
      Yep was going to say this, Want to use a library that is too low level for expo support? Tough! you eject from Expo and now you have to do the low level RN stuff for everything and not just that library.
      - mattnewton 4y ago
        We haven’t had to fully eject with the dev builds - Have you hit the limits of that new(er) workflow? We have lots of packages not available in expo go (and a few that required some config finagling) https://docs.expo.dev/development/create-development-builds https://docs.expo.dev/development/create-development-builds
        4y ago
candiddevmike 4y ago
Instead of having to use flutter, I'd rather see iOS embrace TWAs like Android so I don't have to use Ionic/Capacitor at all. While I'm wishlisting, I'd like more native controls exposed via JS for PWA/TWAs, like widgets, messaging, and password manager APIs. Don't talk to me about writing native apps, I'm a solo dev and couldn't care less about it. I don't have the cycles or the users "demanding it". PWAs are fine if you know what you're doing.
- cutler 4y ago
  Seconded. I can't imagine how solo native devs manage to make a living given the time involved.
- pjmlp 4y ago
  Here is the thing, for most forms over data applications mobile Web works just fine, PWA or not. When I returned to Web/Cloud development a couple of years ago, all the applications use Web frontends, and the tablet / smartphone users manage just fine, no need to package Web sites as "native" applications. Naturally there are a couple of exceptions, like games.
j45 4y ago
I think I’ve rebuilt one app in early every web/hybrid framework. They all failed including ionic. For one reason or another, beyond the usual and small trade offs between platforms, they have all ultimately failed, become overly complicated to maintain and add more logic to. Especially an issue has been the special punishment of having the same codebase work in a dev environment on Mac/windows/Linux. One tech I see being part of the next curve (the prior curve being things like reactnative, etc) is Flutter, or others like it. First class dev environments, first class documentation.
- axlee 4y ago
  Because it seems you have some experience in the field: is there a way to develop and support a multi-platform app in 2023 without suffering? The idea of having to hire 2(x n)FTE to handle developing mobile apps which will, at the end of the day, look and feel the same to the user, is killing me. What's the least worst option out there?
  - dbetteridge 4y ago
    Nope, you can limit the suffering for your devs by using Expo (RN) or Flutter (Needs Dart). The issue is as soon as you stray off the well laid path similar to the old create-react-app problems you have to choose "do things their way" or "Suffer all the problems you avoided with the framework + all the problems of the library you added". For example at work I help maintain a React-Native app that is one of the core parts of our business, We investigated Expo but we use sodium in the app for keypair generation and its not supported. So we can't have any of Expo's benefits because of one unsupported library. (its supported in iOS and Web but not Android...) * There are packages that implement sodium in expo but they score too poorly on their security scores for us to use them.
  - pjmlp 4y ago
    Those FTE will need to understand the native SDKs no matter what, when the abstractions leak someone will need to debug them.
    - 4y ago
commitpizza 4y ago
What about pwabuilder or just using kotlin multiplatform? Seems like two way better options then flutter to me.
henry2023 4y ago
"if you want to avoid issues with table creation and migration, your choice should be NoSQL" Wow.
- prng2021 4y ago
  Yea this stuck out to me too. Like.. what?
  - TedDoesntTalk 4y ago
    Because you can add arbitrary keys in a new release and there is no migration SQL needed like you would need to do if adding new database columns (or tables). The thing he missed is that you can implement arbitrary key/value pairs in a RDBMS table; you don’t need a NoSQL database necessarily: CREATE TABLE NAME_VALUE ID INT, NAME VARCHAR(32), VALUE VARCHAR(512); Querying on WHERE clauses with multiple keys/names can be tedious but works fine as long as performance is not your first priority.
    - ramraj07 4y ago
      I still don’t understand it. You can add new columns in a new release and it should still work even with SQLite?
      - TedDoesntTalk 4y ago
        Perhaps adding a column was not a good example, sorry.
        thealchemistdev 4y ago
        I have a json column specifically for things that are bound to change often like configs. If I need to add a config key, I just update the json.
        ramraj07 4y ago
        Point likely stands - any schema migration is not an easier problem on either side - you just move the migration logic to your code instead of the database.
TobyTheDog123 4y ago
I don't entirely understand why someone would use Ionic to begin with when both React Native (+React-Native-Web) and Flutter both exist. Don't get me wrong, I don't like any of those options, but these B-list options are fairly obviously miles ahead of whatever these other C-list frameworks are promising. An A-list framework to me would look something like: - Typescript-esque syntax without being tied to JS - JSX (TSX)'s XML syntax for layout creation - Pointers, multiple returns, exhaustive enums/switches/matches - Immutability by default - WASM - can work cross-platform (through the DOM, a canvas, Swift, Kotlin, etc) - Built-in niceties like state management (atoms), shared types (TRPC-esque), etc. I'm very much tired of web technologies, originally built for websites, being retconned into building large, complex cross-platform applications.
lchengify 4y ago
The problem with Ionic and React Native has always been the JS/Native bridge. Works great when you're coding it, but to debug any problem rationally you need both native platform and JS expertise. This problem then fans out into every plugin, every open source library, every native-specific "exception", every random device issue. Then the minute you want deal with any native problem, both Android and iOS (and their stores) have nothing to help you. Play Console stack traces just started supporting Kotlin. Forget trying to debug a pile of JS on top of a pile of Java for some obscure plugin that is ANR'ing. Flutter at least tries to fix this problem by taking the Unity approach: One-click build for each platform, where the framework owns the native problem. Then push everything to native graphics as much as possible, down to DSL-specific management of threads. However Flutter has been slow to be adopted into big projects, and made the mistake of choosing Dart over Kotlin. It's stuck in a purgatory of having fans, but not the level of success to qualify as a "breakout" for Google. The hard truth for mobile development right now, is the same hard truth that existed in 2010: Nothing beats native. You try to do too much cross-platform, you wind up chasing two rabbits with no dinner. Even if Google solves every development problem under the sun, Apple is going to Apple. They own the highest-paying customers, they do what they want with the opaqueness of obsidian, and are the very definition of "full stack" from chips to platform. I am rooting for Flutter, I am rooting for a cross-platform utopia, but outside of game platforms it feels like we are farther than even 5 years ago.
- duxup 4y ago
  I use react native and I enjoy it, and I agree. My biggest fear is running fine … and then when compiled something different. And it happens. For “simple” apps I’m very happy with react native. I can’t say enough good things about it there … but I’m really nervous (especially as the primary developer) as if I’ve got this debugging black hole/ sword of damocles hanging around. For web developers who want to hit both app stores I still highly recommend it. But with the note that you want to be deliberate about changes / know about that black hole.
  - lchengify 4y ago
    Yep. Also, the decision is different when you don't use the app store for distribution. I know lots of niche business-specific use cases where they don't care if it crashes half the time. If you need something on mobile quickly for a narrow use case, RN / Ionic can be your friend.
r9295 4y ago
Dart has surprisingly hideous syntax. I wish they would have gone Go or Kotlin

105 points by benatkin 4y ago

For me, Flutter is a really good project that I'll never use because I'll always expect Google to suddenly kill it in a year or two.

the_only_law 4y ago
I’m frankly surprised Dart made a come back at all. I remember hearing a good bit about it and it’s lofty ambitions years ago, but then it seems like it kinda just fell off until Flutter.
- resoluteteeth 4y ago
  In my opinion it was a huge mistake for them to use dart for flutter. I suspect that there would be a lot more excitement around flutter if it used javascript or kotlin (since a lot of android developers are already using kotlin). (They gave some explanation of why they picked dart at the time but it wasn't at all convincing.)
  - cutler 4y ago
    The original goal was for Dart to replace JS in Chrome.
    - dragonwriter 4y ago
      The original goal was for Dart to be generally adopted by browsers, more specifically, not for it to be Chrome-specific.
      - andsoitis 4y ago
        If true, by what stretch of the imagination did Google think browser vendors would adopt Dart?
        ShadowBanThis01 4y ago
        Arrogance is no stretch for Google.
        pjmlp 4y ago
        By the same strech that they pushed PNaCL that others refused to adopt. Which is ironic, given the fizzling market share from Firefox, and how with exception of Safari, all other browsers are based on Chrome. So there is a certain irony that WASM is anyway driven by Google interests.
        SideburnsOfDoom 4y ago
        > they pushed PNaCL that others refused to adopt. Well, they all did eventually adopt WebAssembly, so this effort did get somewhere, eventually.
        pjmlp 4y ago
        A pyrrhic victory for Mozilla.
- pjmlp 4y ago
  AdWords kept it alive until it got chosen by Flutter.
benatkin 4y ago
It's based on another project that it seemed like Google was going to kill, Dart. I don't think I have good enough priors for this situation but I certainly understand your concern.
- pjmlp 4y ago
  The only reason why Dart didn't die was Ad Words team, they had just migrated from GWT into AngularDart when the whole thing imploded, so they rescued the Dart project as it was easier than yet another rewrite into something else.
david422 4y ago
Been playing around with Flutter the last few months. Still has some rough edges, but the ability to target every major platform with a single code base is very cool. The way the UI is laid out with the widget tree is new to me but fun to learn and seems like a very scalable way to build a UI.
- crooked-v 4y ago
  The tree to me feels a lot like React's model, but without the advantage of JSX to compactify the syntax.
  - benatkin 4y ago
    React, Vue, and Svelte are the ones most attached to angle brackets for building apps now. I like HTML Custom Elements and surprisingly the slot mechanism often isn't the best way to do things. You can just use functions that call createElement a lot of the time or a library like Snabbdom. Templates are more for static content. VsCode, Atom, and CodeMirror all do a lot with the web platform without a high angle bracket to line of code ratio. Web app staples like Floating UI and split-grid don't suffer from a lack of angle brackets.
    - crooked-v 4y ago
      It's not the specific angle-bracket syntax that matters, but that there's a ton of verbosity around widgets creation, children arrays, and other properties that could have been massively reduced with the right transformations or even just some decorator-style syntax.
    - c-hendricks 4y ago
      Does the flutter vscode plugin still insert fake comments telling you what widget this random parentheses in a sea of other parentheses is the end of?
scarface74 4y ago
Google has already all but abandoned Flutter for their own apps and said they were going to focus on using the native iOS toolkit. https://9to5google.com/2021/10/10/google-ios-apps-native/ https://9to5google.com/2021/10/10/google-ios-apps-native/
- darren_ 4y ago
  This link says absolutely nothing about Flutter usage. It's about apps that are already written in native iOS code, which are currently using custom Material Design components (which are mostly/entirely in obj-c), and that going forward those custom Material components are going to be phased out and apps will use standard UIKit elements instead. This tells you absolutely nothing about Google's commitment to flutter.
  - scarface74 4y ago
    So it says nothing about using Flutter even though the entire purpose of Flutter is to write cross platform apps and Google is moving toward not writing cross platform apps and are using standard UIKit components. They also aren’t using Dart and are using Objective C. But that doesn’t mean they are moving away from Flutter for first party apps?
    - Apocryphon 4y ago
      They aren't moving away because these Google apps weren't using Flutter in the first place. The only ones that were are like, Google Pay and Google Classroom. https://flutter.dev/showcase/google-pay https://flutter.dev/showcase/google-pay https://flutter.dev/showcase/google-classroom https://flutter.dev/showcase/google-classroom
      - scarface74 4y ago
        Is that really the argument you want to make? That Google doesn’t even dog food their own products for their most popular apps?
TobyTheDog123 4y ago
Flutter is a really good start, it's the closest thing I've found to what I'm looking for. I don't even think Google's going to kill it anytime soon. I don't like Dart though, it has an over-reliance on codegen, and I far prefer JSX's XML syntax than the constructor syntax Flutter uses for its layouts.
ctvo 4y ago
caniuseflutterwithoutdartyet.com Forcing me to use Dart because you made the poor decision of developing it, and now need a reason to continue funding it if I want to use Flutter? No thanks.
IshKebab 4y ago
I don't think that's very likely. Google is clearly still investigating heavily in Flutter, they use it for some of their own apps and devices, and they are clearly aware that the native Android API is not very good. The only thing that would make me suspect that they would kill it is the ongoing performance issues due to shader compilation. But they have actually started fixing that properly by creating a new renderer that doesn't do on-demand shader compilation. The developer tools that Google has released generally don't get suddenly killed. They mostly kill user facing apps that aren't very popular. And Reader.

hbcondo714 4y ago

> The only viable option today, in my opinion, is Flutter I guess it is viable in that Flutter targets, iOS / Android, web and desktop with a "single codebase" but the author of the article isn't aiming for all those platforms.

tengbretson 4y ago

The writing has been on the wall for Ionic since like 2015. If you're a dev still supporting an Ionic codebase today you have my sympathy.

deleted 4y ago

[deleted]

ChicagoDave 4y ago

There’s a well-established and highly supported alternative: https://dotnet.microsoft.com/en-us/apps/maui https://dotnet.microsoft.com/en-us/apps/maui

samayylmao 4y ago
I'm not sure Maui has been production ready long enough. It has not even been GA for a year yet.
axlee 4y ago
Has anyone here have experience with this? We're currently looking at a forward-looking stack for our multi-platform app, and to be fair the general feedback we read is that they all suck in certain ways. What's the least bad out there?
- tailspin2019 4y ago
  My experience: MAUI is not yet polished/complete enough for production (in my experience trying to use it for both iOS and macOS apps).
- datavirtue 4y ago
  If I wrote an article about trying to develop in Xamarin.Forms (MAUI) it would read like the Flutter article that brought us here. Way better than Flutter but still needs work. I spent years on the bleeding edge and mostly ended up with builds failing and other nagging problems. Drained all of my energy. I went back to web dev and have been using Vue 3. Pry it from my cold dead fingers.
- mustacheemperor 4y ago
  I greatly enjoy building in Maui. By weird chance my first programming gig was in UWP and it’s a pleasure to be working in C# .NET again, able to build UIs with xaml and dynamically out of the code, but with a bigger prospective audience than “people who install uwp apps.” That said, I’m only playing with it right now - I’m doing some weekend projects hacking against LLM APIs and it’s a great way to stand up a simple app quickly that runs on my phone and debugs at the computer and could theoretically one day be on the mobile app stores. But I would tentatively agree with other replies that it might be a little early for commercial adoption. I haven’t encountered any show-stopping bugs or limitations yet, but at the same time when researching for troubleshooting and bug fixing I will find git issues that were resolved less than a year ago for things like images not displaying on android. The built-in MediaElement for video playing only just came out and doesn’t support true full screen playback yet. The other factor from it being new is just the lack of community discourse about it. The docs are great but you’re not going to find many discussion on git and SO about it yet, and the search space is cluttered with results about Xamarin.Forms that are sometimes relevant and sometimes completely not. So IMO that means people should give it a try! But maybe hack on it first before committing to shipping commercial software. Has MS released a commercial/production app built on Maui yet? Are they eating their own dogfood?

preommr 4y ago

> They’re missing that the market has moved from this kind of mindset. If you look at Dribbble, you can’t find mobile design dedicated for iOS and another set dedicated to Android. Interesting that this idea is mainstream when HN hivemind will frequently complain about how bad it is that nothing looks native anymore.

tylerchurch 4y ago

As someone who has deployed projects to the App Store/Play Store in both React Native and Ionic for my day job - Ionic is a breath of fresh air compared to React Native. Ionic+Capacitor delivers on the promise to leverage existing web development knowledge to build mobile apps. React Native somewhat delivers on the promise. But the whole ecosystem loves breaking changes, and debuggability is a nightmare. There are more libraries for native libraries, but the headache of actually integrating them is significant. Capacitor, in comparison, seems very well designed. Where web tech stops and native tech starts is very clear.

mattnewton 4y ago
I have only just started working with react native, but I will say the new expo development workflow is pretty great.
- tylerchurch 4y ago
  Expo makes React Native fairly tolerable. Just don't go outside the guardrails, there lies pain.
  - dbetteridge 4y ago
    Yep was going to say this, Want to use a library that is too low level for expo support? Tough! you eject from Expo and now you have to do the low level RN stuff for everything and not just that library.
    - mattnewton 4y ago
      We haven’t had to fully eject with the dev builds - Have you hit the limits of that new(er) workflow? We have lots of packages not available in expo go (and a few that required some config finagling) https://docs.expo.dev/development/create-development-builds https://docs.expo.dev/development/create-development-builds
      - 4y ago

candiddevmike 4y ago

Instead of having to use flutter, I'd rather see iOS embrace TWAs like Android so I don't have to use Ionic/Capacitor at all. While I'm wishlisting, I'd like more native controls exposed via JS for PWA/TWAs, like widgets, messaging, and password manager APIs. Don't talk to me about writing native apps, I'm a solo dev and couldn't care less about it. I don't have the cycles or the users "demanding it". PWAs are fine if you know what you're doing.

cutler 4y ago
Seconded. I can't imagine how solo native devs manage to make a living given the time involved.
pjmlp 4y ago
Here is the thing, for most forms over data applications mobile Web works just fine, PWA or not. When I returned to Web/Cloud development a couple of years ago, all the applications use Web frontends, and the tablet / smartphone users manage just fine, no need to package Web sites as "native" applications. Naturally there are a couple of exceptions, like games.

j45 4y ago

I think I’ve rebuilt one app in early every web/hybrid framework. They all failed including ionic. For one reason or another, beyond the usual and small trade offs between platforms, they have all ultimately failed, become overly complicated to maintain and add more logic to. Especially an issue has been the special punishment of having the same codebase work in a dev environment on Mac/windows/Linux. One tech I see being part of the next curve (the prior curve being things like reactnative, etc) is Flutter, or others like it. First class dev environments, first class documentation.

axlee 4y ago
Because it seems you have some experience in the field: is there a way to develop and support a multi-platform app in 2023 without suffering? The idea of having to hire 2(x n)FTE to handle developing mobile apps which will, at the end of the day, look and feel the same to the user, is killing me. What's the least worst option out there?
- dbetteridge 4y ago
  Nope, you can limit the suffering for your devs by using Expo (RN) or Flutter (Needs Dart). The issue is as soon as you stray off the well laid path similar to the old create-react-app problems you have to choose "do things their way" or "Suffer all the problems you avoided with the framework + all the problems of the library you added". For example at work I help maintain a React-Native app that is one of the core parts of our business, We investigated Expo but we use sodium in the app for keypair generation and its not supported. So we can't have any of Expo's benefits because of one unsupported library. (its supported in iOS and Web but not Android...) * There are packages that implement sodium in expo but they score too poorly on their security scores for us to use them.
- pjmlp 4y ago
  Those FTE will need to understand the native SDKs no matter what, when the abstractions leak someone will need to debug them.
  - 4y ago

commitpizza 4y ago

What about pwabuilder or just using kotlin multiplatform? Seems like two way better options then flutter to me.

henry2023 4y ago

"if you want to avoid issues with table creation and migration, your choice should be NoSQL" Wow.

prng2021 4y ago
Yea this stuck out to me too. Like.. what?
- TedDoesntTalk 4y ago
  Because you can add arbitrary keys in a new release and there is no migration SQL needed like you would need to do if adding new database columns (or tables). The thing he missed is that you can implement arbitrary key/value pairs in a RDBMS table; you don’t need a NoSQL database necessarily: CREATE TABLE NAME_VALUE ID INT, NAME VARCHAR(32), VALUE VARCHAR(512); Querying on WHERE clauses with multiple keys/names can be tedious but works fine as long as performance is not your first priority.
  - ramraj07 4y ago
    I still don’t understand it. You can add new columns in a new release and it should still work even with SQLite?
    - TedDoesntTalk 4y ago
      Perhaps adding a column was not a good example, sorry.
      - thealchemistdev 4y ago
        I have a json column specifically for things that are bound to change often like configs. If I need to add a config key, I just update the json.
      - ramraj07 4y ago
        Point likely stands - any schema migration is not an easier problem on either side - you just move the migration logic to your code instead of the database.

TobyTheDog123 4y ago

I don't entirely understand why someone would use Ionic to begin with when both React Native (+React-Native-Web) and Flutter both exist. Don't get me wrong, I don't like any of those options, but these B-list options are fairly obviously miles ahead of whatever these other C-list frameworks are promising. An A-list framework to me would look something like: - Typescript-esque syntax without being tied to JS - JSX (TSX)'s XML syntax for layout creation - Pointers, multiple returns, exhaustive enums/switches/matches - Immutability by default - WASM - can work cross-platform (through the DOM, a canvas, Swift, Kotlin, etc) - Built-in niceties like state management (atoms), shared types (TRPC-esque), etc. I'm very much tired of web technologies, originally built for websites, being retconned into building large, complex cross-platform applications.

lchengify 4y ago

The problem with Ionic and React Native has always been the JS/Native bridge. Works great when you're coding it, but to debug any problem rationally you need both native platform and JS expertise. This problem then fans out into every plugin, every open source library, every native-specific "exception", every random device issue. Then the minute you want deal with any native problem, both Android and iOS (and their stores) have nothing to help you. Play Console stack traces just started supporting Kotlin. Forget trying to debug a pile of JS on top of a pile of Java for some obscure plugin that is ANR'ing. Flutter at least tries to fix this problem by taking the Unity approach: One-click build for each platform, where the framework owns the native problem. Then push everything to native graphics as much as possible, down to DSL-specific management of threads. However Flutter has been slow to be adopted into big projects, and made the mistake of choosing Dart over Kotlin. It's stuck in a purgatory of having fans, but not the level of success to qualify as a "breakout" for Google. The hard truth for mobile development right now, is the same hard truth that existed in 2010: Nothing beats native. You try to do too much cross-platform, you wind up chasing two rabbits with no dinner. Even if Google solves every development problem under the sun, Apple is going to Apple. They own the highest-paying customers, they do what they want with the opaqueness of obsidian, and are the very definition of "full stack" from chips to platform. I am rooting for Flutter, I am rooting for a cross-platform utopia, but outside of game platforms it feels like we are farther than even 5 years ago.

duxup 4y ago
I use react native and I enjoy it, and I agree. My biggest fear is running fine … and then when compiled something different. And it happens. For “simple” apps I’m very happy with react native. I can’t say enough good things about it there … but I’m really nervous (especially as the primary developer) as if I’ve got this debugging black hole/ sword of damocles hanging around. For web developers who want to hit both app stores I still highly recommend it. But with the note that you want to be deliberate about changes / know about that black hole.
- lchengify 4y ago
  Yep. Also, the decision is different when you don't use the app store for distribution. I know lots of niche business-specific use cases where they don't care if it crashes half the time. If you need something on mobile quickly for a narrow use case, RN / Ionic can be your friend.

r9295 4y ago

Dart has surprisingly hideous syntax. I wish they would have gone Go or Kotlin