5 ms·

Personally I think that Flutter is the future for cross-platform UI toolkits. As a React dev (in my spare time, I’m still a student), using RN was a pain due to

Personally I think that Flutter is the future for cross-platform UI toolkits. As a React dev (in my spare time, I’m still a student), using RN was a pain due to the need to install native extensions for almost everything. The batteries-included approach of Flutter and just the polish around the dev workflow made it more attractive to a beginner mobile dev.

mdocherty 7y ago
I would be hesitant to recommend seriously pursuing cross-platform. Most serious applications generally run into scaling issues as they get more complicated and demands require more than the abstractions the cross-platform tool can provide.
- freehunter 7y ago
  On the other hand, very few applications need to scale to the point where it matters. If the options are "ship something now and refactor later" versus "ship something in six months that's perfect but too late", most people here would benefit from cross platform solutions. Very few companies have ever failed because their tech stack didn't scale well.
  - SquishyPanda23 7y ago
    This is a nit, but there's a pretty big difference between refactoring and rearchitecting. If you plan for an eventual migration of the app from a cross-platform toolkit to native, then often you're committing to a significant rewrite of the app. This means either you dedicate a team to the rewrite or you stop adding features while it gets rewritten. Plus it will take a while for the native version to get feature parity with the cross-platform version, and you typically can't roll out the native version until you have parity. I'm sure there are tools and strategies for getting this right, but I've seen this basically kill startups.
    - freehunter 7y ago
      You're right, I didn't use the correct terminology and I appreciate the correction. On the other hand, using information from Facebook themselves (creators of React Native), the cross-platform solution seems to be able to scale pretty darn well [1]. Facebook, Instagram, Bloomberg, Skype, Walmart, Uber... these are some pretty big names with some pretty big audiences. If React Native can get your company from a startup to the size of any of these companies, I'd say you're doing pretty well on the technology front. Kind of like how Twitter had to do a major rewrite from Rails, but Rails got them to the point where they needed that rewrite. [1] https://facebook.github.io/react-native/showcase https://facebook.github.io/react-native/showcase
      - K0SM0S 7y ago
        I think you'd indeed have to look at more demanding applications, more "bleeding edge" stuff computationally: 3D gaming is probably as good a candidate as ever, maybe some in-app AI workflows, idk. Truth is, I know how to bring a desktop/server to its knees because there are valid use-cases for that, but on mobile I struggle to find many examples indeed. I guess any heavy data crunching app might fit the bill, but when don't you run that remotely? On-premises offline pro apps maybe, like tools for e.g. plumbers and electricians? All of that stuff is in embedded afaik. Dedicated devices, rugged cases, it's a whole other market/target. So cross-platform solutions on mobile indeed seem to fit most-if-not-all of the 'normal' use-cases, assuming there's server resource available. The Twitter/Rails example is one perfect illustration, and there are many such examples throughout big names we know today.
        vlozko 7y ago
        The issues you tend to run into with mobile is that you have to either create so many shim layers to use native app features or resort to 3rd party solutions. And there are loads of examples (speaking for iOS here): 1. JSON parsing 2. Network calls 3. Background downloading 4. Notifications 5. Camera access 6. Password/contact/code auto fill 7. VoiceOver 8. Web Views 9. JavaScript bridging 10. Encryption 11. And many more Almost every app needs some combination of those and in some of these cases you’re forced to use a native solution. What ends up happening is that a significant amount of developer resources gets wasted bridging many of these things with massive bug logs to go with them. It’s why at this point I refuse to do anything but native in my career.
  - davnicwil 7y ago
    > Very few companies have ever failed because their tech stack didn't scale well Just out of interest, are there any clear examples where this happened, ever? Can anyone name any? What I mean specifically is - a company with a well known product that was growing in popularity but then hit a ceiling because of technical scale issues and couldn't support any more customers, growth halted, and they couldn't fix it in time to keep the momentum going (or got overtaken by a competitor) and failed?
    - zmj 7y ago
      It happens all the time. When it does, though, the narrative is usually "scrappy upstart takes over" and not "segment leader fossilizes".
      - rwallace 7y ago
        So what would be some examples of when a scrappy upstart took over because the segment leader ran into tech stack scaling issues? (As opposed to the segment leader running into corrupt or incompetent management, failing to notice a new market opportunity etc.)
- amimetic 7y ago
  Today is a weird time to get into mobile app dev. The standard 'native' UI frameworks are pretty terrible in terms of how they cope with complexity and their ability to change over time with their dated OOP APIs. Though on both platforms the tooling has been climbing ever upwards towards local maxima. The best options available for most Apps today (even if just for a single platform) are typically React Native or Flutter. With their React(-ish) UI approaches you can both quickly build and iterate in the future. SwiftUI is not ready for most uses (I've shipped a small but non trivial app https://apps.apple.com/us/app/pattern-maker/id1484249212 https://apps.apple.com/us/app/pattern-maker/id1484249212 and was surprised by how many bugs there are for very standard things and how many hacks seemed to be required). Jetpack Compose seems to be at an even earlier stage. I expect both will be great but probably not for some time.
  - pjmlp 7y ago
    For those into gamming the standard native UI never mattered. Then there are several kinds of workflows that are quite doable as mobile Web. One just has to take into consideration that 3G isn't broadband, nor a mobile display a last generation 25" screen.
- rubber_duck 7y ago
  There are plenty of "serious" applications written with cross platform tools. Flutter, React Native even ionic/cordova - it depends entirely on what your application does.
pjmlp 7y ago
I bet that Chrome and Android team would have more political muscle than the Flutter team. PWAs will keep being pushed by Chrome team, alongside Microsoft, and I wouldn't be surprised to see a Kotlin/Native variant of Jetpack Composer by Google IO 2020.
jmull 7y ago
Flutter is DOA for anything but short-term projects. For one thing, it’s tied to a custom language. That means there’s significant overhead for developers which shows itself directly as a learning curve, or indirectly in terms of hiring or retention of developers. At least as significantly, they chose to implement custom controls (rather than wrap native controls). With that approach there’s really no way for them to implement native expectations for controls in the first place, much less keep up with native functionality across platforms.
- preommr 7y ago
  > For one thing, it’s tied to a custom language. Are you talking about Dart? If so, that's absolutely savage, lmao. To not only call it a "custom" language but not even name it. The amount of disrespect - and the worst thing is I don't even think it was intended. Even if this is one person, I think this speaks volumes about how much of a joke the language is. It's just so sad. And to think that the team behind flutter purposefully chose it after considering a bunch of other languages.
  - fctorial 7y ago
    I don't think he meant it that way. He's probably trying to say that depending on a "custom language" is a bad thing in itself. I personally don't feel that dart is tied in any way to flutter. It was originally meant to be compiled to js, and that shows in vm architecture, but that doesn't look like a con.
  - literallycancer 7y ago
    Well they did add the compiler half way through. You can write idiomatic Dart code that won't run because Flutter asserts crash it at runtime. And you fix it by writing code that the Dart compiler complains about but lets you run and it works (even though it shouldn't). Is there another compiled language where this is the norm? What's the point of dealing with a half baked ecosystem when there are much better languages available?
- Qasaur 7y ago
  I disagree strongly with this. I'm currently writing a cross-platform app in Flutter that is launching soon, and I found that the developer experience is world-class and I've had very few issues so far. The language is incredibly easy to pick up with close to zero overhead if you are a somewhat competent programmer as it is essentially a very lightweight OOP language. My main languages are otherwise Go and Rust, and picking up Dart was not difficult at all for me and I don't think you need to be a wizard to figure it out. I suspect JS devs will find it even easier to pick up as many of the constructs are similar. It took only a couple of days to get up to speed with Flutter-specific functionality as well as the native API bindings, and I was already writing production code for the app the first week of exposure to the language. The UI framework is declarative and very easy to reason about and design, and the tooling is also incredibly seamless and easy to use, although I do agree that it needs some polishing as there are some edge cases that you sometimes need to trawl the Github issues page to fix. Yes, sometimes it is frustrating as there are some things that are lacking in the standard library, but the third-party library scene is picking up and you can do 95% of what you want to do without major issue. I'm convinced that Flutter is going to become bigger in the future and is going to cover most use cases for all but the most performant apps and perhaps games.
billfruit 7y ago
Perhaps Xamarin is a good choice as well for who want to transition from development of desktop apps. Also support for F# on Xamarin is also a plus.
- graydsl 7y ago
  I was waiting for someone to mention Xamarin. :D I haven't worked with the platform for 2 to 3 years. In my old job we had massive problems at the end hence we switched to native (we were an agency). Problems we had: * Deploying to devices was painfully slow compared to native stack. * We all had Macs and the tooling (Visual Studio for Mac/MonoDevelop) was pretty bad compared to Android Studio. * Wrapping 3rd party native libs was a pain, if not impossible. Especially in a stressful agency environment. When we heard about the acquisition of Xamarin by Microsoft I was hopeful things would change to the better. But month later they rebranded MonoDevelop and focused on integrating Azure. Did it get any better?
  - pjmlp 7y ago
    Visual Studio for Mac has suffered quite a refactoring after the acquisition, as many of the MonoDevelop internals have been refactored into common libraries shared between Visual Studio and Visual Studio for Mac, one of the reasons why the new plugin infrastructure is based on .NET instead of COM. There a release event happening next month, https://visualstudio.microsoft.com/vs/mac/event/ https://visualstudio.microsoft.com/vs/mac/event/
elevenoh 7y ago
How is flutter's open source widget community?

mdocherty 7y ago

I would be hesitant to recommend seriously pursuing cross-platform. Most serious applications generally run into scaling issues as they get more complicated and demands require more than the abstractions the cross-platform tool can provide.

freehunter 7y ago
On the other hand, very few applications need to scale to the point where it matters. If the options are "ship something now and refactor later" versus "ship something in six months that's perfect but too late", most people here would benefit from cross platform solutions. Very few companies have ever failed because their tech stack didn't scale well.
- SquishyPanda23 7y ago
  This is a nit, but there's a pretty big difference between refactoring and rearchitecting. If you plan for an eventual migration of the app from a cross-platform toolkit to native, then often you're committing to a significant rewrite of the app. This means either you dedicate a team to the rewrite or you stop adding features while it gets rewritten. Plus it will take a while for the native version to get feature parity with the cross-platform version, and you typically can't roll out the native version until you have parity. I'm sure there are tools and strategies for getting this right, but I've seen this basically kill startups.
  - freehunter 7y ago
    You're right, I didn't use the correct terminology and I appreciate the correction. On the other hand, using information from Facebook themselves (creators of React Native), the cross-platform solution seems to be able to scale pretty darn well [1]. Facebook, Instagram, Bloomberg, Skype, Walmart, Uber... these are some pretty big names with some pretty big audiences. If React Native can get your company from a startup to the size of any of these companies, I'd say you're doing pretty well on the technology front. Kind of like how Twitter had to do a major rewrite from Rails, but Rails got them to the point where they needed that rewrite. [1] https://facebook.github.io/react-native/showcase https://facebook.github.io/react-native/showcase
    - K0SM0S 7y ago
      I think you'd indeed have to look at more demanding applications, more "bleeding edge" stuff computationally: 3D gaming is probably as good a candidate as ever, maybe some in-app AI workflows, idk. Truth is, I know how to bring a desktop/server to its knees because there are valid use-cases for that, but on mobile I struggle to find many examples indeed. I guess any heavy data crunching app might fit the bill, but when don't you run that remotely? On-premises offline pro apps maybe, like tools for e.g. plumbers and electricians? All of that stuff is in embedded afaik. Dedicated devices, rugged cases, it's a whole other market/target. So cross-platform solutions on mobile indeed seem to fit most-if-not-all of the 'normal' use-cases, assuming there's server resource available. The Twitter/Rails example is one perfect illustration, and there are many such examples throughout big names we know today.
      - vlozko 7y ago
        The issues you tend to run into with mobile is that you have to either create so many shim layers to use native app features or resort to 3rd party solutions. And there are loads of examples (speaking for iOS here): 1. JSON parsing 2. Network calls 3. Background downloading 4. Notifications 5. Camera access 6. Password/contact/code auto fill 7. VoiceOver 8. Web Views 9. JavaScript bridging 10. Encryption 11. And many more Almost every app needs some combination of those and in some of these cases you’re forced to use a native solution. What ends up happening is that a significant amount of developer resources gets wasted bridging many of these things with massive bug logs to go with them. It’s why at this point I refuse to do anything but native in my career.
- davnicwil 7y ago
  > Very few companies have ever failed because their tech stack didn't scale well Just out of interest, are there any clear examples where this happened, ever? Can anyone name any? What I mean specifically is - a company with a well known product that was growing in popularity but then hit a ceiling because of technical scale issues and couldn't support any more customers, growth halted, and they couldn't fix it in time to keep the momentum going (or got overtaken by a competitor) and failed?
  - zmj 7y ago
    It happens all the time. When it does, though, the narrative is usually "scrappy upstart takes over" and not "segment leader fossilizes".
    - rwallace 7y ago
      So what would be some examples of when a scrappy upstart took over because the segment leader ran into tech stack scaling issues? (As opposed to the segment leader running into corrupt or incompetent management, failing to notice a new market opportunity etc.)
amimetic 7y ago
Today is a weird time to get into mobile app dev. The standard 'native' UI frameworks are pretty terrible in terms of how they cope with complexity and their ability to change over time with their dated OOP APIs. Though on both platforms the tooling has been climbing ever upwards towards local maxima. The best options available for most Apps today (even if just for a single platform) are typically React Native or Flutter. With their React(-ish) UI approaches you can both quickly build and iterate in the future. SwiftUI is not ready for most uses (I've shipped a small but non trivial app https://apps.apple.com/us/app/pattern-maker/id1484249212 https://apps.apple.com/us/app/pattern-maker/id1484249212 and was surprised by how many bugs there are for very standard things and how many hacks seemed to be required). Jetpack Compose seems to be at an even earlier stage. I expect both will be great but probably not for some time.
- pjmlp 7y ago
  For those into gamming the standard native UI never mattered. Then there are several kinds of workflows that are quite doable as mobile Web. One just has to take into consideration that 3G isn't broadband, nor a mobile display a last generation 25" screen.
rubber_duck 7y ago
There are plenty of "serious" applications written with cross platform tools. Flutter, React Native even ionic/cordova - it depends entirely on what your application does.

pjmlp 7y ago

I bet that Chrome and Android team would have more political muscle than the Flutter team. PWAs will keep being pushed by Chrome team, alongside Microsoft, and I wouldn't be surprised to see a Kotlin/Native variant of Jetpack Composer by Google IO 2020.

jmull 7y ago

Flutter is DOA for anything but short-term projects. For one thing, it’s tied to a custom language. That means there’s significant overhead for developers which shows itself directly as a learning curve, or indirectly in terms of hiring or retention of developers. At least as significantly, they chose to implement custom controls (rather than wrap native controls). With that approach there’s really no way for them to implement native expectations for controls in the first place, much less keep up with native functionality across platforms.

preommr 7y ago
> For one thing, it’s tied to a custom language. Are you talking about Dart? If so, that's absolutely savage, lmao. To not only call it a "custom" language but not even name it. The amount of disrespect - and the worst thing is I don't even think it was intended. Even if this is one person, I think this speaks volumes about how much of a joke the language is. It's just so sad. And to think that the team behind flutter purposefully chose it after considering a bunch of other languages.
- fctorial 7y ago
  I don't think he meant it that way. He's probably trying to say that depending on a "custom language" is a bad thing in itself. I personally don't feel that dart is tied in any way to flutter. It was originally meant to be compiled to js, and that shows in vm architecture, but that doesn't look like a con.
- literallycancer 7y ago
  Well they did add the compiler half way through. You can write idiomatic Dart code that won't run because Flutter asserts crash it at runtime. And you fix it by writing code that the Dart compiler complains about but lets you run and it works (even though it shouldn't). Is there another compiled language where this is the norm? What's the point of dealing with a half baked ecosystem when there are much better languages available?
Qasaur 7y ago
I disagree strongly with this. I'm currently writing a cross-platform app in Flutter that is launching soon, and I found that the developer experience is world-class and I've had very few issues so far. The language is incredibly easy to pick up with close to zero overhead if you are a somewhat competent programmer as it is essentially a very lightweight OOP language. My main languages are otherwise Go and Rust, and picking up Dart was not difficult at all for me and I don't think you need to be a wizard to figure it out. I suspect JS devs will find it even easier to pick up as many of the constructs are similar. It took only a couple of days to get up to speed with Flutter-specific functionality as well as the native API bindings, and I was already writing production code for the app the first week of exposure to the language. The UI framework is declarative and very easy to reason about and design, and the tooling is also incredibly seamless and easy to use, although I do agree that it needs some polishing as there are some edge cases that you sometimes need to trawl the Github issues page to fix. Yes, sometimes it is frustrating as there are some things that are lacking in the standard library, but the third-party library scene is picking up and you can do 95% of what you want to do without major issue. I'm convinced that Flutter is going to become bigger in the future and is going to cover most use cases for all but the most performant apps and perhaps games.

billfruit 7y ago

Perhaps Xamarin is a good choice as well for who want to transition from development of desktop apps. Also support for F# on Xamarin is also a plus.

graydsl 7y ago
I was waiting for someone to mention Xamarin. :D I haven't worked with the platform for 2 to 3 years. In my old job we had massive problems at the end hence we switched to native (we were an agency). Problems we had: * Deploying to devices was painfully slow compared to native stack. * We all had Macs and the tooling (Visual Studio for Mac/MonoDevelop) was pretty bad compared to Android Studio. * Wrapping 3rd party native libs was a pain, if not impossible. Especially in a stressful agency environment. When we heard about the acquisition of Xamarin by Microsoft I was hopeful things would change to the better. But month later they rebranded MonoDevelop and focused on integrating Azure. Did it get any better?
- pjmlp 7y ago
  Visual Studio for Mac has suffered quite a refactoring after the acquisition, as many of the MonoDevelop internals have been refactored into common libraries shared between Visual Studio and Visual Studio for Mac, one of the reasons why the new plugin infrastructure is based on .NET instead of COM. There a release event happening next month, https://visualstudio.microsoft.com/vs/mac/event/ https://visualstudio.microsoft.com/vs/mac/event/

elevenoh 7y ago

How is flutter's open source widget community?