Flutter: the good, the bad and the ugly(medium.com)
medium.com
Flutter: the good, the bad and the ugly
https://medium.com/asos-techblog/flutter-vs-react-native-for-ios-android-app-development-c41b4e038db9
222 comments
Spot on. We experimented with a bunch of platforms for our app and ultimately settled on Flutter for this exact reason. Design is orders of magnitude simpler than in almost anything else. Working on a small team without a full-time designer this was a godsend.
React-Native is great, the only problem is that Facebook does not do enough to nurture the open source use of it, and this creates lots of extra work for teams using it.
Airbnb's decision to abandon RN is clearly due to engineering blunders and political nonsense internal to Airbnb, which has little to do with RN itself.
But if you look at all of the github issues for RN you will see that many of them are open/unresolved for weeks with hundreds or thousands of +1s only to have someone at Facebook mysteriously close them, leaving a lot of people in the lurch.
We're also seeing a lot of API and internal refactoring fromi FB rather than focusing on the ecosystem, which indicates that inside FB it is more beneficial to say "I sped up x by 10% in react-native" than it is to improve usability for the many using it as an open source library trying to get something simple to work as expected.
Airbnb's decision to abandon RN is clearly due to engineering blunders and political nonsense internal to Airbnb, which has little to do with RN itself.
But if you look at all of the github issues for RN you will see that many of them are open/unresolved for weeks with hundreds or thousands of +1s only to have someone at Facebook mysteriously close them, leaving a lot of people in the lurch.
We're also seeing a lot of API and internal refactoring fromi FB rather than focusing on the ecosystem, which indicates that inside FB it is more beneficial to say "I sped up x by 10% in react-native" than it is to improve usability for the many using it as an open source library trying to get something simple to work as expected.
I just had my first encounter with React Native and it wasn't a good one. It's the typical JavaScript dependency hell where things blow up at run-time with cryptical errors and tons of people on SO / GitHub just saying "use a lower version", to get another error and reading "this is fixed in the latest version" which was the one I was just coming from.
This built on top of the iOS build system and everything is intertwined in both directions at least a few times. I've seen builds working starting the iOS app from command line, only to break _everything_ just starting the application from within Xcode. And Android? I didn't even look into it anymore.
I think they're at 0.57 or something and that version number just wants to tell you one thing: We're going to break your shit some more in the near future before the dust finally settles.
This built on top of the iOS build system and everything is intertwined in both directions at least a few times. I've seen builds working starting the iOS app from command line, only to break _everything_ just starting the application from within Xcode. And Android? I didn't even look into it anymore.
I think they're at 0.57 or something and that version number just wants to tell you one thing: We're going to break your shit some more in the near future before the dust finally settles.
I'm hearing this complaint a lot about React Native in particular: That Facebook's "Move Fast And Break Things" philosophy is alive and well in the management of the project.
Most recently the stories were about specific controls that worked on Android but on on iOS, and then the new version arrives, breaks the Android behavior but fixes the iOS behavior...or vice versa, sometimes for the same control, in a later release.
I've heard better things about NativeScript; it's actually a more mature project than React Native, and has a lot of features that React Native lacks. And it's apparently a lot more stable.
But fewer people use NativeScript, so it's possible that I'm just not hearing as many of the horror stories. Also curious about Weex.
But I'm not making apps right now, so I haven't tried any of the above. People keep wanting to pay me lots of money to work on easy backend projects. Who am I to say no? :)
Most recently the stories were about specific controls that worked on Android but on on iOS, and then the new version arrives, breaks the Android behavior but fixes the iOS behavior...or vice versa, sometimes for the same control, in a later release.
I've heard better things about NativeScript; it's actually a more mature project than React Native, and has a lot of features that React Native lacks. And it's apparently a lot more stable.
But fewer people use NativeScript, so it's possible that I'm just not hearing as many of the horror stories. Also curious about Weex.
But I'm not making apps right now, so I haven't tried any of the above. People keep wanting to pay me lots of money to work on easy backend projects. Who am I to say no? :)
I had a similar experience. The idea of React Native is pretty great, but the difficulty developing with it is a significant drawback.
Flutter also has a bit of dependency hell at this point (might be better after it goes stable) - tried installing built_value (immutable data structures) and had a do a lot of dependency version tweaking and overrides.
What library/libraries gave you issues?
>> Airbnb's decision to abandon RN is clearly due to engineering blunders and political nonsense internal to Airbnb
I could be wrong here, but from what I understood the cost of maintaining a hybrid RN + fully-native apps > full-native apps. I.e. What airbnb would gain by not having to code both android/iOS was lost by having to deal with all the RN non-sense (third-party libraries being deprecated, very fast non-backward compatible changes, etc.) but also having to always bridge the gap between what was RN and what was truly-native. At the end of the day, you look at your time and you realize that you spend more time trying to make it work with RN to "save time" rather than just coding it on both platform.
But then, most people using RN don't have to deal with this issue because they don't have an existing non-RN code base to bridge with RN.
I could be wrong here, but from what I understood the cost of maintaining a hybrid RN + fully-native apps > full-native apps. I.e. What airbnb would gain by not having to code both android/iOS was lost by having to deal with all the RN non-sense (third-party libraries being deprecated, very fast non-backward compatible changes, etc.) but also having to always bridge the gap between what was RN and what was truly-native. At the end of the day, you look at your time and you realize that you spend more time trying to make it work with RN to "save time" rather than just coding it on both platform.
But then, most people using RN don't have to deal with this issue because they don't have an existing non-RN code base to bridge with RN.
This mirrors my experience working with Xamarin. You had to know both everything going on at the native level and the c# .net and Xamarin levels as well.
This is why I always advocate for platform languages on production code.
Too many hours spent in the past writing FFI code, tracking down bugs not knowing if they were on the platform or 3rd party language runtime, missing integration with platform tooling.
Naturally I don't always succeed at that.
Too many hours spent in the past writing FFI code, tracking down bugs not knowing if they were on the platform or 3rd party language runtime, missing integration with platform tooling.
Naturally I don't always succeed at that.
See, and I think that React Native is terrible, and Airbnb abandoning it clearly shows that their engineering culture is solid and not driven by cargo cult engineers chasing the latest fad.
>and Airbnb abandoning it clearly shows that their engineering culture is solid and not driven by cargo cult engineers chasing the latest fad.
Depends on what they pick next (and why they picked RN before in the first place?), but as a standalone decision it's not enough to "clearly show" anything of the sort.
Depends on what they pick next (and why they picked RN before in the first place?), but as a standalone decision it's not enough to "clearly show" anything of the sort.
I’m not sure about that. The ability to identify and accept a hard problem, and then do something about it, speaks of good management in their engineering department.
Agreed, it was a (probably too subtle) retort to the idea that them abandoning it clearly meant they’re a dysfunctional mess.
I use the Airbnb app a lot and have done so for years and there is nothing terribly advanced or unusual going on. It may have been a cargo cult decision to layer RN into whatever they had beforehand, but if so that increases the chance that evicting it was also a cargo cult decision.
Read the blog posts, they had no approach to app-side state and it was essentially a battle between sub teams to see who could make their own ad hoc approach to state “win” organizationally and force other teams to deal with it when data sharing.
Sounds like a nightmare both from a cultural and engineering perspective. It made it so the only way to get a unified engineering perspective was a political “purge” of RN adherents.
Read the blog posts, they had no approach to app-side state and it was essentially a battle between sub teams to see who could make their own ad hoc approach to state “win” organizationally and force other teams to deal with it when data sharing.
Sounds like a nightmare both from a cultural and engineering perspective. It made it so the only way to get a unified engineering perspective was a political “purge” of RN adherents.
Discord uses React Native, and they only have two developers on their iOS app. Millions of users, impressive app with high performance...two devs.
> Millions of users, impressive app with high performance
No offense to the Discord iOS developers, but their apps is neither “high performance” nor impressive. It’s outright janky at times.
No offense to the Discord iOS developers, but their apps is neither “high performance” nor impressive. It’s outright janky at times.
And their iOS app is saddled with loads unresolved UI/UX issues that have been around for years, the iPad version is heavily unoptimised, and it lags behind the desktop/web versions by miles.
The Android version suffers the same but moreso.
The Android version suffers the same but moreso.
I haven’t used their app, but scaling an app isn’t actually that difficult if the backend can handle it. I don’t think that their use of RN is relevant here unless you think there’s no way that a native iOS app of similar complexity couldn’t be built by two devs? But then you’d have to explain all the counterexamples, or even where a solo dev builds an app that goes viral and gets millions of users...
"Scaling" an app doesn't simply mean being able to use it on many devices (hence, "if the backend can handle it"). It also can mean you're able to be productive when adding new features to the application.
I specifically was referring to scaling to millions of users. I’m a solo app dev consultant and some of the apps I’ve worked on have had big spikes of users. No big deal.
It’s kind of like saying your frontend framework is awesome because it scales to millions of users. Well yeah, they’re all running it on their own machines, so assuming you can deliver the code to them and the backend can handle it, you could scale to quadrillions of users.
It’s kind of like saying your frontend framework is awesome because it scales to millions of users. Well yeah, they’re all running it on their own machines, so assuming you can deliver the code to them and the backend can handle it, you could scale to quadrillions of users.
Yeah but the more people that use your app the more tested it gets. The more gnarly edge cases crop up, the bigger the impact if you accidentally ship buggy features, etc. Scale means even your front end has to live up to a higher quality bar. And given that app store downloads are driven by reviews, it's even more critical to avoid bad performance than on the web.
That’s true, and numerous people in this thread report that their app is nothing to be proud of.
"airbnb abandoning it shows it's bad, but other companies using it successfully doesn't sbow it's good!"
Abandoning something takes more work than using it, since it adds the cost of a rewrite. If Airbnb adopted framework X that wouldn't make me confident in framework X -- they haven't even used it yet! If they used it for a long time that would increase my confidence in X (in the absence of evidence to the contrary). But if everyone else started abandoning X I'd take Airbnb's experience with a grain of salt. I get that Discord is able to do well with it, but that doesn't mean everyone is able to do well with it depending on their needs. And who knows, maybe Discord is having just enough trouble that it hurts but too little to switch.
They give it rave reviews: https://blog.discordapp.com/why-discord-is-sticking-with-rea...
I was making a tongue in cheek retort about it “clearly” meaning that, since person I was responding to said it clearly meant they were dysfunctional. Probably could have made it more explicit.
I do think that scaling an app to millions of users says basically nothing on its own about the app framework / code quality itself. You’re scaling across as many devices as you have users. There’s no challenge at all there on the mobile dev side.
I do think that scaling an app to millions of users says basically nothing on its own about the app framework / code quality itself. You’re scaling across as many devices as you have users. There’s no challenge at all there on the mobile dev side.
React and react native is a fantastic design and a great project. It has been so successful that it is still having some growing pains.
It's certainly possible for both RN and AirBnB's internal organization to not be great.
They also started making enough money that the cost of two native development teams isn't a problem.
> React-Native is great, the only problem is that Facebook does not do enough to nurture the open source use of it, and this creates lots of extra work for teams using it.
Airbnb's decision to abandon RN is clearly due to engineering blunders and political nonsense internal to Airbnb, which has little to do with RN itself.
This is a very generalised opinion for a very specific technology with _many_ significant trade offs. React native can be excellent for one team, and terrible for a different team at the same time.
It may be great in your specific circumstances, but I’d give Airbnbs mature engineering team the benefit of the doubt that it isn’t the right fit for them.
This is a very generalised opinion for a very specific technology with _many_ significant trade offs. React native can be excellent for one team, and terrible for a different team at the same time.
It may be great in your specific circumstances, but I’d give Airbnbs mature engineering team the benefit of the doubt that it isn’t the right fit for them.
Well, if you read all the blog posts and read in between the lines a bit, they had a group of native developers who preferred to use their existing native skill set to build things, and since there was no unified approach to state, it became cumbersome to manage state between a hodgepodge of rn and native components.
So already the deck is severely stacked against rn because of the lack of guiding architecture decisions.
Then one can imagine how experienced native developers would end up with political leverage to evict rn, and by the time it happened it may have been the right choice.
But if architecture is done correctly the main problems Airbnb had would simply not happen and many of those native devs would not have had to be hired in the first place.
So already the deck is severely stacked against rn because of the lack of guiding architecture decisions.
Then one can imagine how experienced native developers would end up with political leverage to evict rn, and by the time it happened it may have been the right choice.
But if architecture is done correctly the main problems Airbnb had would simply not happen and many of those native devs would not have had to be hired in the first place.
The fact that you have jumped to "speculate airbnb developers are unprofessional and their architects are bad" is definitely something you could think about.
> Well, if you read all the blog posts > they had a group of native developers who preferred to use their existing native skill set to build things, and since there was no unified approach to state, it became cumbersome to manage state between a hodgepodge of rn and native components
This is an immature straw man reducing their issues to one thing - it's a long blog series I have read (and presented back to clients in a series of case studies).
I don't want to come in too hot because it's increasingly clear you are pretty fresh in your career, but taking this kind of negative view based on pure speculation is really going to be limiting for you.
As I said, RN is great in some circumstances, but like any framework / tech there _is many_ cases and orgs where it is not a good fit.
> Well, if you read all the blog posts > they had a group of native developers who preferred to use their existing native skill set to build things, and since there was no unified approach to state, it became cumbersome to manage state between a hodgepodge of rn and native components
This is an immature straw man reducing their issues to one thing - it's a long blog series I have read (and presented back to clients in a series of case studies).
I don't want to come in too hot because it's increasingly clear you are pretty fresh in your career, but taking this kind of negative view based on pure speculation is really going to be limiting for you.
As I said, RN is great in some circumstances, but like any framework / tech there _is many_ cases and orgs where it is not a good fit.
> reducing their issues to one thing
Not at all, I focused on the one thing that was mentioned as the most significant reason for team frustration with react native.
> I don't want to come in too hot
No worries
> it's increasingly clear you are pretty fresh in your career
I was thinking the same thing about you, no offense.
> but taking this kind of negative view
Not sure what you found negative about my view. Teams and individuals make mistakes and misjudgments. That is part of life. If you read my comments I said that removing RN was probably the right thing to do by the time it happened. This is often the case with bad technological decisions in startups and is rational because of sunk cost.
> many_ cases and orgs where it is not a good fit
This is why I cite architecture. With react or react-native you really need to know where the data is coming from and how the data will flow through the application. I'm arguing that the architect should have had a plan for how this would work before introducing react native into the app.
Airbnb has done a lot of great react-native work, so I know the issue isn't technical competency, but the linting rules Airbnb popularized suggest a very trees-oriented (not forest oriented) perspective on tech, which is the kind of perspective that makes the above kind of mistake.
Not at all, I focused on the one thing that was mentioned as the most significant reason for team frustration with react native.
> I don't want to come in too hot
No worries
> it's increasingly clear you are pretty fresh in your career
I was thinking the same thing about you, no offense.
> but taking this kind of negative view
Not sure what you found negative about my view. Teams and individuals make mistakes and misjudgments. That is part of life. If you read my comments I said that removing RN was probably the right thing to do by the time it happened. This is often the case with bad technological decisions in startups and is rational because of sunk cost.
> many_ cases and orgs where it is not a good fit
This is why I cite architecture. With react or react-native you really need to know where the data is coming from and how the data will flow through the application. I'm arguing that the architect should have had a plan for how this would work before introducing react native into the app.
Airbnb has done a lot of great react-native work, so I know the issue isn't technical competency, but the linting rules Airbnb popularized suggest a very trees-oriented (not forest oriented) perspective on tech, which is the kind of perspective that makes the above kind of mistake.
> Not sure what you found negative about my view.
Cool reading your other comments too I realise I’m getting trolled at this point so I’ll finish up here.
Cool reading your other comments too I realise I’m getting trolled at this point so I’ll finish up here.
> I’m getting trolled
In other words you have no rational or thoughtful response and have for the second time decided to use ad hominem attacks, this time the highly sophisticated one known as name calling.
In other words you have no rational or thoughtful response and have for the second time decided to use ad hominem attacks, this time the highly sophisticated one known as name calling.
[deleted]
> indicates that inside FB it is more beneficial to say "I sped up x by 10% in react-native"
Are FB's internal goals related to improving their open source projects or related to improving FB products that might happen to use their open source projects? In most companies that would be the latter.
Are FB's internal goals related to improving their open source projects or related to improving FB products that might happen to use their open source projects? In most companies that would be the latter.
> don’t worry, it’s super easy if you’re familiar with Java, JS, Kotlin, Swift or C#
Those languages are pretty different from each other. I've used 4 out of 5 of them professionally, and I'd say it takes a good 6 months to get comfortable with the new syntax and idioms.
(Learning to speak a language may be super easy if you already know another one in the same family, but you still have to learn it. Easy learning is not a zero cost activity.)
JS and Swift, in particular, feel like opposites. Besides using the {} characters a lot, I can't think of much they have in common.
Programmers today frequently need to learn new languages, but why? If you believe that these languages are similar enough to be "super easy" to cross between them, then how is it the incremental value of any of these languages so great that it justifies writing a new compiler, and making millions of programmers figure it out? It's not just learning time. I've run into nasty bugs with every compiler I've ever used.
As an engineering decision, is there any feature of Dart that is required by Flutter? This looks like the software analog of the pentalobe screw. It's not technically difficult to deal with but it serves no real purpose except to be different.
Those languages are pretty different from each other. I've used 4 out of 5 of them professionally, and I'd say it takes a good 6 months to get comfortable with the new syntax and idioms.
(Learning to speak a language may be super easy if you already know another one in the same family, but you still have to learn it. Easy learning is not a zero cost activity.)
JS and Swift, in particular, feel like opposites. Besides using the {} characters a lot, I can't think of much they have in common.
Programmers today frequently need to learn new languages, but why? If you believe that these languages are similar enough to be "super easy" to cross between them, then how is it the incremental value of any of these languages so great that it justifies writing a new compiler, and making millions of programmers figure it out? It's not just learning time. I've run into nasty bugs with every compiler I've ever used.
As an engineering decision, is there any feature of Dart that is required by Flutter? This looks like the software analog of the pentalobe screw. It's not technically difficult to deal with but it serves no real purpose except to be different.
The Flutter team has answered this question directly in a few public pieces:
https://hackernoon.com/why-flutter-uses-dart-dd635a054ebf
https://flutter.io/docs/resources/faq#why-did-flutter-choose...
I personally already knew Dart, and had quite a bit of experience with it before I found out about Flutter, but honestly, I still don't see the language itself as _that_ much of a barrier to a platform to where it should be one of the most common criticisms of the entire framework.
After all, there _do_ exist alternative mobile development frameworks/infrastructure, in the other languages that people usually bring up as alternatives to Dart (ex. Kotlin, Java, Swift, C#, JS).
https://hackernoon.com/why-flutter-uses-dart-dd635a054ebf
https://flutter.io/docs/resources/faq#why-did-flutter-choose...
I personally already knew Dart, and had quite a bit of experience with it before I found out about Flutter, but honestly, I still don't see the language itself as _that_ much of a barrier to a platform to where it should be one of the most common criticisms of the entire framework.
After all, there _do_ exist alternative mobile development frameworks/infrastructure, in the other languages that people usually bring up as alternatives to Dart (ex. Kotlin, Java, Swift, C#, JS).
Thanks for replying, but I don't actually see the answer to my question here. They read like post-hoc rationalization, i.e., Given that Dart was chosen, what are some attributes of it that programmers found desirable?
Several other languages offer most of these desired features. Did anyone compare the effort required to add the remaining requirements to an existing language? That's what would make it an engineering decision.
Even if Dart somehow takes zero effort to learn, I'm still not convinced it was a net win.
Several other languages offer most of these desired features. Did anyone compare the effort required to add the remaining requirements to an existing language? That's what would make it an engineering decision.
Even if Dart somehow takes zero effort to learn, I'm still not convinced it was a net win.
Here's a podcast episode with Randal Schwartz on Flutter that you might find interesting, as it might shed some light as to how Flutter evolved from the Dartium project and how the Chrome team was involved.
https://softwareengineeringdaily.com/2018/07/11/flutter-in-p...
You can also skim the transcript (pgs. 3-6) Transcript here:
https://softwareengineeringdaily.com/2018/07/11/flutter-in-p...
You can also skim the transcript (pgs. 3-6) Transcript here:
Going with Dart gave flutter
- complied to machine code
- fast GC
- stateful Hotreload, a feature of the Dart vm use in dev builds.
My understanding is Dart originally started out with a vm along with a Dart-to-JavaScript compiler. The Dart team was also doing their own experiments in the iot and ios space.
Flutter, at that time it was call the Sky project/experiment, looked at several languages before give dart a go.
Apple only allows their JS VM on ios.
The nature of flutter, creating and discard many objects per frame, required a fast GC.
The hotreload feature was one the Flutter team didn't know they wanted, it was a suggestion from the Dart team.
So the Dart Team was able to meet flutters needs of creating a fast GC and being able to be compiled to machine code for ios and android as well.
My understanding is Dart originally started out with a vm along with a Dart-to-JavaScript compiler. The Dart team was also doing their own experiments in the iot and ios space.
Flutter, at that time it was call the Sky project/experiment, looked at several languages before give dart a go.
Apple only allows their JS VM on ios.
The nature of flutter, creating and discard many objects per frame, required a fast GC.
The hotreload feature was one the Flutter team didn't know they wanted, it was a suggestion from the Dart team.
So the Dart Team was able to meet flutters needs of creating a fast GC and being able to be compiled to machine code for ios and android as well.
"is there any feature of Dart that is required by Flutter?"
The Dart platform provides the following features:
- Subsecond hot reload
- AOT to ARM
- Bytecode interpreter for debug mode on IOS
- JIT for debug mode on Android
- GC tuned for Flutter's build methods. (like React's render)
Not aware of any other platform provides all of these features. Bolting these features on to another existing language and platform which wasn't designed with these goals would be hard.
The Dart platform provides the following features:
- Subsecond hot reload
- AOT to ARM
- Bytecode interpreter for debug mode on IOS
- JIT for debug mode on Android
- GC tuned for Flutter's build methods. (like React's render)
Not aware of any other platform provides all of these features. Bolting these features on to another existing language and platform which wasn't designed with these goals would be hard.
Spend some time with Common Lisp, specially the commercial versions like Allegro or LispWorks.
Eiffel would be another possibility.
Then there was the way Oberon was originally designed.
The fact is that there is nothing special about Dart other than trying to save the language.
Eiffel would be another possibility.
Then there was the way Oberon was originally designed.
The fact is that there is nothing special about Dart other than trying to save the language.
So much arm chair theorising, lol. Meanwhile someone has picked up the Dart tool chain and built a compelling framework with it. There is nothing "theoretically" special about this, but it is special in the "practical" sense that it exists, and I can use it today.
I can download it, install it, and get hot-reload on Android and iOS mobile devices while coding. I can swap out code at any layer of the framework since all of the framework's layout code and widgets are implemented in the same language as used to build an app.
Dart's performance characteristics and the combination of the AOT, JIT, and bytecode interpreter make this possible.
I write Clojure for a living. I like the elegance of Lisps. Clojure is mostly tolerable. The thing I like most about it is loading code immediately into the REPL. I hope more of the industry moves towards live programming. (or moves back to live programming, since I guess back in the Smalltalk days it used to be mainstream.)
I can download it, install it, and get hot-reload on Android and iOS mobile devices while coding. I can swap out code at any layer of the framework since all of the framework's layout code and widgets are implemented in the same language as used to build an app.
Dart's performance characteristics and the combination of the AOT, JIT, and bytecode interpreter make this possible.
I write Clojure for a living. I like the elegance of Lisps. Clojure is mostly tolerable. The thing I like most about it is loading code immediately into the REPL. I hope more of the industry moves towards live programming. (or moves back to live programming, since I guess back in the Smalltalk days it used to be mainstream.)
Commercial Common Lisp compilers can also target mobile platforms, nothing theoric about it.
In any case, the issue is that Dart isn't a special snowflake with some extraordinary set of AOT, JIT, and bytecode interpreter not available to any other programming language.
There are plenty of programming languages that offer these applicabilities.
Flutter can be equality well implemented with any of them and I believe Dart is going to bet the cause of Flutter's failure, unless Google forces it upon us, e.g. replacing Android with Fuchsia.
In any case, the issue is that Dart isn't a special snowflake with some extraordinary set of AOT, JIT, and bytecode interpreter not available to any other programming language.
There are plenty of programming languages that offer these applicabilities.
Flutter can be equality well implemented with any of them and I believe Dart is going to bet the cause of Flutter's failure, unless Google forces it upon us, e.g. replacing Android with Fuchsia.
Well for the mainstream VMs: Hotswap on the JVM is very limited, likewise with edit and continue on the CLR. Xamarin has live XAML updates, only for markup though. V8 is better at hot reloading, but then suffers on the performance front, since it's basically impossible to do efficient AOT for it.
So which languages/platforms do you mean?
So which languages/platforms do you mean?
Eiffel would be such an example, from the list I have listed.
Regarding JVM, hotswap is only limited if you constrain yourself to the OpenJDK basic features.
As we in the Java community are well aware, that are other options out there, like HotswapAgent and JRebel for example.
Commits adding Fuchsia support for ART started to land on AOSP, so lets see how much love Flutter/Dart will actually get from Google internal politics.
Regarding JVM, hotswap is only limited if you constrain yourself to the OpenJDK basic features.
As we in the Java community are well aware, that are other options out there, like HotswapAgent and JRebel for example.
Commits adding Fuchsia support for ART started to land on AOSP, so lets see how much love Flutter/Dart will actually get from Google internal politics.
Haven't used Eiffel. Seems to compile to C and CIL, also GPL and likely even less popular than Dart.
Jrebel dicontinued android support. Does hotswapagent support android?
Cool watching Fuchsia evolve. It will definitely support Android apps, otherwise google throws away their playstore monopoly.
Cool watching Fuchsia evolve. It will definitely support Android apps, otherwise google throws away their playstore monopoly.
Eiffel uses its own VM for interactive development, and compilation to native code via system C and C++ compilers. CIL and Java support is just a kind of integration support, the MELT VM is what matters.
Eiffel is a commercial language, with a GPL based license for open source projects.
It is also used in enterprise production code since the mid-90's, definitely more battle tested than Dart will ever be, which lets be honest it is struggling for survival.
Eiffel is a commercial language, with a GPL based license for open source projects.
It is also used in enterprise production code since the mid-90's, definitely more battle tested than Dart will ever be, which lets be honest it is struggling for survival.
Back to where this started:
"is there any feature of Dart that is required by Flutter?"
This is me paraphrasing why the Flutter team think Dart is a good fit:
It's a familiar language for developers who have written JS, Java, C#, or C++. It has types to allow working on large codebases, and efficient AOT compilation. It has tooling for popular IDEs. Does subsecond hot-reload on iOS and Android (also more than just method bodies). It's performance, even on iOS dev mode is sufficient to do all of the layout and widget code. It's open source under liberal license which allows you to embed it your app.
Your claim: "There are plenty of programming languages that offer these applicabilities."
I don't think this is true. Even if you want to count Eiffel that's one, not plenty.
Nor could Eiffel have been used for Flutter since the GPL means you can't embed the VM in your app. Nor is it particular familiar for developers of existing mainstream languages.
Anyways, I agree that there's nothing "special snowflakey" about any of this technology, but no-one else, that I'm aware of, is shipping a language and toolchain that ticks all of these boxes at the moment. Hopefully someone will build this stuff for other popular stacks too.
(I am also aware of Eiffel. I remember hearing about it at uni back in the mid-90s when discussing CBD. I think it may be older than mid-90s too. I also don't think it would have been a very good choice for Flutter.)
Also what's with this whole "Dart struggling for survival" meme of yours. It comes off as kinda unhinged. Feel free to ignore the language. And people who like using it can happily ignore you.
This is me paraphrasing why the Flutter team think Dart is a good fit:
It's a familiar language for developers who have written JS, Java, C#, or C++. It has types to allow working on large codebases, and efficient AOT compilation. It has tooling for popular IDEs. Does subsecond hot-reload on iOS and Android (also more than just method bodies). It's performance, even on iOS dev mode is sufficient to do all of the layout and widget code. It's open source under liberal license which allows you to embed it your app.
Your claim: "There are plenty of programming languages that offer these applicabilities."
I don't think this is true. Even if you want to count Eiffel that's one, not plenty.
Nor could Eiffel have been used for Flutter since the GPL means you can't embed the VM in your app. Nor is it particular familiar for developers of existing mainstream languages.
Anyways, I agree that there's nothing "special snowflakey" about any of this technology, but no-one else, that I'm aware of, is shipping a language and toolchain that ticks all of these boxes at the moment. Hopefully someone will build this stuff for other popular stacks too.
(I am also aware of Eiffel. I remember hearing about it at uni back in the mid-90s when discussing CBD. I think it may be older than mid-90s too. I also don't think it would have been a very good choice for Flutter.)
Also what's with this whole "Dart struggling for survival" meme of yours. It comes off as kinda unhinged. Feel free to ignore the language. And people who like using it can happily ignore you.
Dart was dropped by Chrome and Angular teams, rescued from certain death by the AdWords team.
Without something like Flutter, the language has nowhere else to go.
The judge is how there regarding how Flutter adoption is actually going to take off on the mass market, outside a few agreements to show off at keynotes.
Without something like Flutter, the language has nowhere else to go.
The judge is how there regarding how Flutter adoption is actually going to take off on the mass market, outside a few agreements to show off at keynotes.
So seems similar to GWT which also saw little adoption outside of Google, and was used by the AdWords team. But here we are in 2018 and GWT is still ticking along with regular commits. I guess that means Dart is here to stay too.
And now Flutter is becoming popular and is being used by external developers. "Struggling for survival" is hyperbole today, and pre-Flutter, but agree this was true in the pre-AdWords days.
https://github.com/gwtproject/gwt/commits/master
And now Flutter is becoming popular and is being used by external developers. "Struggling for survival" is hyperbole today, and pre-Flutter, but agree this was true in the pre-AdWords days.
https://github.com/gwtproject/gwt/commits/master
> Hotswap on the JVM is very limited
It mystifies me why this has not been integrated into Sun's/Oracle's JVM and OpenJDK, since it's been available in other JVM implementations for a long time and is so obviously a hugely useful feature – with the agonizingly slow startup of Java applications you really need code reloading at runtime.
Anyway, the Android VM (ART) has Instant Run nowadays. It also doesn't support hot-swapping anything more than method implementations without restarting, but restarting on Android is not as painful as on the regular JVM.
https://developer.android.com/studio/run/#instant-run
It mystifies me why this has not been integrated into Sun's/Oracle's JVM and OpenJDK, since it's been available in other JVM implementations for a long time and is so obviously a hugely useful feature – with the agonizingly slow startup of Java applications you really need code reloading at runtime.
Anyway, the Android VM (ART) has Instant Run nowadays. It also doesn't support hot-swapping anything more than method implementations without restarting, but restarting on Android is not as painful as on the regular JVM.
https://developer.android.com/studio/run/#instant-run
Hopefully Flutter's popularity will bump the priorities of the other VM developers to improve code reloading.
i dont think lisp is as popular...
i actually prefer a java like language than learn prefix calls and conj
i actually prefer a java like language than learn prefix calls and conj
C-like languages have prefix calls; what you have to learn is that no commas are required and the opening parenthesis encloses the operator, not just the arguments. You were able to create a HN account, so I think you can handle it.
Sure, the point being there is nothing special about Dart.
What it gets promoted as Dart special features for Flutter is also available in other languages, not only Lisp.
What it gets promoted as Dart special features for Flutter is also available in other languages, not only Lisp.
The short answer is that the Flutter team wanted a language that was something like Dart, and the Dart team needed a killer app and was willing to put a lot of effort into satisfying Flutter's requirements.
It's unlikely that Flutter could have gotten that level of cooperation and influence over a more successful language, back when they were getting started and nobody had heard of them yet.
It's unlikely that Flutter could have gotten that level of cooperation and influence over a more successful language, back when they were getting started and nobody had heard of them yet.
I spend most of my time with JavaScript, Obj-c and Java. It took me about 3 days to wrap my head around dart and start writing productive code.
I'd like to hear your opinions as well (e.g. how you manage states, what type of navigations (tab, stack, drawer) you used)
I suppose they're all more imperative and OO languages than not? Certainly they're more similar to each other than to Haskell or Go, for instance.
As for why Flutter uses Dart, this is the canonical answer: https://hackernoon.com/why-flutter-uses-dart-dd635a054ebf
As for why Flutter uses Dart, this is the canonical answer: https://hackernoon.com/why-flutter-uses-dart-dd635a054ebf
I got a reply here on hn awhile back with a similar question[1].
> Dart really is a big part of why the Flutter framework is as it is. Obviously you could design similar frameworks in other languages and have similar results, but there's really a very nice synergy between Dart's design and the Flutter framework, all the way down to small details like how garbage collection works in Dart vs how the framework happens to allocate objects.
So the rationalization seems to be performance.
[1]https://news.ycombinator.com/item?id=16476886
> Dart really is a big part of why the Flutter framework is as it is. Obviously you could design similar frameworks in other languages and have similar results, but there's really a very nice synergy between Dart's design and the Flutter framework, all the way down to small details like how garbage collection works in Dart vs how the framework happens to allocate objects.
So the rationalization seems to be performance.
[1]https://news.ycombinator.com/item?id=16476886
You're right, they are of course different. What I meant is that if you know any of those languages, your knowledge can be very easily mapped to Dart. I had experience with those langs before, and I was productive with Dart from day 1, it never felt like a problem to me. I'm just happy Google didn't go down the route of using JS like in RN :P
Flutter looks good, the ‘goods’ out weighing the ‘bads.’ I am “retiring” next spring, and I look forward to getting back into user experience development. I wrote successful commercial UI heavy products for three platforms when they were first released (Xerox Lisp Machine, 1984 Mac, Windows 1.0 beta) but mostly people pay me for AI development, but I would enjoy getting back into UI. I used RubyMotion to convert Cookingspace.com to simple iOS and Android apps a few years ago, but RubyMotion hit a road block, I think, when it was sold to an individual. Flutter seems more secure longer termed.
Also: it would be cool if Flutter was extended to support macOS, GTK (Linux), and maybe even Windows 10. Give small dev teams more market reach.
Creating desktop apps with Flutter is possible: https://medium.com/flutter-community/flutter-from-mobile-to-...
The Flutter engine has an embedding API that is intended for this purpose:
https://github.com/flutter/engine/tree/master/shell/platform...
https://github.com/flutter/engine/tree/master/shell/platform...
Agreed Flutter for :
Android /IOS /Web /Windows 10 /MacOS
Would be the amazing killer combo, that would cause me to invest considerable resource into Flutter and switch my team to it.
I know there is an unofficial versions that apparently do this, I would need the comfort of an official proven Google version.
[deleted]
FWIW, I’ve found the RubyMotion community to be more active since it was sold and people are very helpful on Slack. I’m saying this as someone who has done hybrid for mobile in the past and have recently been trying RubyMotion and Flutter.
Thanks for this. My yearly license has expired, but now I will take another look.
Flutter appears to have a lot of the momentum that other frameworks lack. I've usually sworn to Qt/QtQuick, but only because I want to be able to easily jump into native code, and/or reuse existing C/C++ libraries, even on mobile devices. Flutter can't do that yet afaik. Qt just isn't going in the right direction. IMO if they'd gotten their act together, even years ago, all these new fangled X-Platform frameworks, wouldn't even have existed.
I have to admit, that I haven't really taken RN seriously, because I fundamentally don't believe in that architecture on a mobile device. RN only seems exist to provide a means for people who like React. Not to actually provide a beneficial application framework.
I have to admit, that I haven't really taken RN seriously, because I fundamentally don't believe in that architecture on a mobile device. RN only seems exist to provide a means for people who like React. Not to actually provide a beneficial application framework.
I think I can more or less say that we would not have been able to build what we have without RN. At least not with same budget. There is a large class of apps that would suck @ in a webview but can get by just fine in RN with 90% cross-platform code re-use. If you're already a team of experienced react developers the learning curve mostly just comes down to learning how to resolve build issues. And possibly expo can take care of that depending on your app. (anyone actually use expo for real stuff?)
With RN + React Web + [PaaS/FaaS] I feel like a lone dev can be dangerous theses days.
Doesn't mean Flutter or PWA's won't obsolete it eventually, and I'm optimistic about Flutter's approach. Just saying that there's a reason RN is a thing.
With RN + React Web + [PaaS/FaaS] I feel like a lone dev can be dangerous theses days.
Doesn't mean Flutter or PWA's won't obsolete it eventually, and I'm optimistic about Flutter's approach. Just saying that there's a reason RN is a thing.
Could you elaborate what is the sweet spot for RN, when webview is not enough?
I think webview is rarely enough. If you already have React experience then building React Native is only marginally more difficult than a web app but the UX is much better.
[deleted]
I also don't believe in RN and for me Flutter is the last hope of keeping Dart relevant outside the Googleplex.
I don't see any reason to waste my time with Dart. It was a good decision to focus on JavaScript back then, and it is more so in the context of native apps.
Regarding Qt, when I tried it about 4 years ago, I was quite disappointed with their mobile support, because they only had the bare minimum, and integrating the platform APIs meant in the end the effort was bigger than just doing C++ plus native views.
Meanwhile they seem to have switched focus to customers that are actually willing to pay for their tooling, thus hardware manufactures selling medical, IoT and automobile devices, as one can easily see from the upcoming Qt World Summit schedule.
At personal level I have been using the former approach of C++ plus native views, while at work our mobile projects have been either Ionic based or plain mobile web sites.
Still weighting to switch back to Qt or adopt Xamarin for hobby projects, although with Google and Microsoft pulling their weight behind PWAs, I am starting to think that might be the future for all mobile apps that aren't performance critical, given WebAssembly and access to device APIs without additional FFI when authenticated.
How was your mobile Qt experience been?
I don't see any reason to waste my time with Dart. It was a good decision to focus on JavaScript back then, and it is more so in the context of native apps.
Regarding Qt, when I tried it about 4 years ago, I was quite disappointed with their mobile support, because they only had the bare minimum, and integrating the platform APIs meant in the end the effort was bigger than just doing C++ plus native views.
Meanwhile they seem to have switched focus to customers that are actually willing to pay for their tooling, thus hardware manufactures selling medical, IoT and automobile devices, as one can easily see from the upcoming Qt World Summit schedule.
At personal level I have been using the former approach of C++ plus native views, while at work our mobile projects have been either Ionic based or plain mobile web sites.
Still weighting to switch back to Qt or adopt Xamarin for hobby projects, although with Google and Microsoft pulling their weight behind PWAs, I am starting to think that might be the future for all mobile apps that aren't performance critical, given WebAssembly and access to device APIs without additional FFI when authenticated.
How was your mobile Qt experience been?
WebAssembly on-device might be a game changer for performance critical apps. I'll happily welcome it when I see it, but I'm not holding my breath.
The thing is that most things coming from Web just moves faster, and there's so many more resources available for the 95% app. For all of that JS kinda makes sense. It just comes with a bad upbringing and poor manners, when seen through the glasses of considering a phone as an "embedded" device with resource restrictions. Performance is always seems an afterthought in most things web. And that's understandable, because even the baseline resource usage, as fast and small as you can get on a Javascript runtime, is still above what I'd consider acceptable. It just isn't for most apps out there and people have sort of gotten used to charging their phones mid-way through the day.
Qt definitely isn't perfect, and it can be a bit of a pain to work with. QtCreator is just... and there's no live reloading.
The good thing is that runs really fast on the machine you're already working on, so most of the time you just work on the Desktop windowed version anyway.
I wish there's was a bigger selection of UI frameworks available though. For mobile there's Qt Quick Controls 2, which is quite good, but not at all as expansive as what you have available on the web for instance.
I do think though, that if Qt doesn't do something about their tooling and ecosystem, that they'll get run into the ground when some of these other frameworks bridges the gap to some of the features that Qt is still unique in having.
The thing is that most things coming from Web just moves faster, and there's so many more resources available for the 95% app. For all of that JS kinda makes sense. It just comes with a bad upbringing and poor manners, when seen through the glasses of considering a phone as an "embedded" device with resource restrictions. Performance is always seems an afterthought in most things web. And that's understandable, because even the baseline resource usage, as fast and small as you can get on a Javascript runtime, is still above what I'd consider acceptable. It just isn't for most apps out there and people have sort of gotten used to charging their phones mid-way through the day.
Qt definitely isn't perfect, and it can be a bit of a pain to work with. QtCreator is just... and there's no live reloading.
The good thing is that runs really fast on the machine you're already working on, so most of the time you just work on the Desktop windowed version anyway.
I wish there's was a bigger selection of UI frameworks available though. For mobile there's Qt Quick Controls 2, which is quite good, but not at all as expansive as what you have available on the web for instance.
I do think though, that if Qt doesn't do something about their tooling and ecosystem, that they'll get run into the ground when some of these other frameworks bridges the gap to some of the features that Qt is still unique in having.
Reactjs Architecture is very suited for mobile development. After all it's a view centric one. RN problem I assume same for Flutter is the bridge accessing native apis.
When I say architecture, I mean running a full web-runtime as your core application layer. That is a fundamentally broken paradigm in my opinion. That's also the difference between RN and Flutter.
Flutter allows the use of plugins which, through glue code, allow using native code and existing libraries. It's pretty comparable functionally to Java's JNI.
Yeah I know about https://flutter.io/docs/development/platform-integration/pla...
But, that's almost the same as not having support at all. JNI isn't really a poster-child of usability.
With Qt, since you're already on the right side of the fence, it's just a matter of "#include "whatever.h" and linking it at compile time.
I mean, even just getting a camera feed on Flutter isn't a built-in: https://pub.dartlang.org/packages/camera
But, that's almost the same as not having support at all. JNI isn't really a poster-child of usability.
With Qt, since you're already on the right side of the fence, it's just a matter of "#include "whatever.h" and linking it at compile time.
I mean, even just getting a camera feed on Flutter isn't a built-in: https://pub.dartlang.org/packages/camera
One thing that's different about Flutter is that we've deliberately focused on keeping the Flutter framework small. We write many of the plug-ins ourselves to the same standard as the core framework, but keeping them separate lets us iterate on them at a different cadence. See https://github.com/flutter/plugins for our plug-in repository.
(Disclosure: I'm a PM on the Flutter team.)
(Disclosure: I'm a PM on the Flutter team.)
Hey Tim. I can completely understand the reasoning behind it from a project development perspective, I'm just pointing out some of the pitfalls in doing it this way.
Obviously I don't know how you've structured responsibilities internally, but what I've seen before is, that the quality of individual components, or plugins if you will, live and die by the interest of the teams and people behind them.
Qt has this very same problem, often leading to some bugs ageing unacceptably long, or features never properly maturing, simply because there's little to no inside interest. NPM has a variant of the same problem as well. I'd venture a guess that a large percentage of packages on NPM right now, is downright abandonware.
I will be keeping a interested eye out for the developments of Flutter and I'm hopeful you succeed in this space. There's definitely room for it.
With regards to the native stuff, I'm mainly coming from a performance perspective on GPGPU and computer vision applications. I think going forward, there's going to be a huge increase in AR/MR apps, that will need easy access to do heavy lifting on metal. Coincidentally, I was lucky enough to catch a quick chat with Michael Thomsen, after his talk at Coldfront recently and he mentioned that, that was indeed on the roadmap. If you guys manage to provide the easiest cross platform way to do Vulkan/Metal or whatever the next-gen iOS and Android HAL is going to be, you're definitely going to come out on top.
Obviously I don't know how you've structured responsibilities internally, but what I've seen before is, that the quality of individual components, or plugins if you will, live and die by the interest of the teams and people behind them.
Qt has this very same problem, often leading to some bugs ageing unacceptably long, or features never properly maturing, simply because there's little to no inside interest. NPM has a variant of the same problem as well. I'd venture a guess that a large percentage of packages on NPM right now, is downright abandonware.
I will be keeping a interested eye out for the developments of Flutter and I'm hopeful you succeed in this space. There's definitely room for it.
With regards to the native stuff, I'm mainly coming from a performance perspective on GPGPU and computer vision applications. I think going forward, there's going to be a huge increase in AR/MR apps, that will need easy access to do heavy lifting on metal. Coincidentally, I was lucky enough to catch a quick chat with Michael Thomsen, after his talk at Coldfront recently and he mentioned that, that was indeed on the roadmap. If you guys manage to provide the easiest cross platform way to do Vulkan/Metal or whatever the next-gen iOS and Android HAL is going to be, you're definitely going to come out on top.
Michael Thomsen's Coldfront talk is up on youtube,
https://youtu.be/sl5TaN7EwjQ
https://youtu.be/sl5TaN7EwjQ
Funny enough it is the lack of native Google Places support that makes Flutter a no go for me.
Also not having a JSX like syntax. I went into RN expecting to hate JSX, but I ended up loving it.
Doing UI development with nested {} is so hideous in comparison. I am impressed at the quality of UIs Flutter can make, but the code behind them is, IMHO, much harder to read than the RN equivalent.
Also not having a JSX like syntax. I went into RN expecting to hate JSX, but I ended up loving it.
Doing UI development with nested {} is so hideous in comparison. I am impressed at the quality of UIs Flutter can make, but the code behind them is, IMHO, much harder to read than the RN equivalent.
> even just getting a camera feed on Flutter isn't a built-in
Why should it be built-in? That's such a C++ (or C) mindset: that using dependencies is bad, which stems from the difficulty of adding and updating dependencies in the C++ world.
In a language with a rock solid package manager, it's better to have a small core and then pull in what you need. Each of these out-of-core dependencies can have separate lifecycles, which makes it a lot easier for them to be developed and updated, making them higher quality. If breaking changes need to be made, that can easily be done in out-of-core libraries, since existing projects can continue depending on their SemVer-defined compatible version of the dependency ad infinitum, and the project maintainers can continue releasing updates to any SemVer series of the package if they need to backport changes to older versions. When something is in the core, it's very hard to update it while maintaining complete compatibility, and people can only depend on one version of your core library at a time, so there's no room to be flexible. This constricts growth, since the core needs to meet everyone's needs, but it doesn't have the flexibility to do that as the world changes, so it often meets no one's needs.
I don't know how good Dart's package manager is, since I haven't really touched Dart since the very earliest days of the language after it became public, but Rust's package manager is excellent, and having most things out-of-std has been great for the community. Futures and async have flourished out-of-std and gone through several very different approaches to gain real world experience. Some very small pieces of that ecosystem will be stabilized into the core language soon, but only the most bare minimum features to add the "await" keyword to the language. As much as possible will still remain in outside libraries.
In general, things go to stdlib to die.[0] The main exception I've seen with this over the years is Go, where they have done a really great job of maintaining and extending their huge batteries-included stdlib to the point that most people almost always recommend starting with the stdlib before reaching for a third-party package.
[0]: http://www.leancrew.com/all-this/2012/04/where-modules-go-to...
Why should it be built-in? That's such a C++ (or C) mindset: that using dependencies is bad, which stems from the difficulty of adding and updating dependencies in the C++ world.
In a language with a rock solid package manager, it's better to have a small core and then pull in what you need. Each of these out-of-core dependencies can have separate lifecycles, which makes it a lot easier for them to be developed and updated, making them higher quality. If breaking changes need to be made, that can easily be done in out-of-core libraries, since existing projects can continue depending on their SemVer-defined compatible version of the dependency ad infinitum, and the project maintainers can continue releasing updates to any SemVer series of the package if they need to backport changes to older versions. When something is in the core, it's very hard to update it while maintaining complete compatibility, and people can only depend on one version of your core library at a time, so there's no room to be flexible. This constricts growth, since the core needs to meet everyone's needs, but it doesn't have the flexibility to do that as the world changes, so it often meets no one's needs.
I don't know how good Dart's package manager is, since I haven't really touched Dart since the very earliest days of the language after it became public, but Rust's package manager is excellent, and having most things out-of-std has been great for the community. Futures and async have flourished out-of-std and gone through several very different approaches to gain real world experience. Some very small pieces of that ecosystem will be stabilized into the core language soon, but only the most bare minimum features to add the "await" keyword to the language. As much as possible will still remain in outside libraries.
In general, things go to stdlib to die.[0] The main exception I've seen with this over the years is Go, where they have done a really great job of maintaining and extending their huge batteries-included stdlib to the point that most people almost always recommend starting with the stdlib before reaching for a third-party package.
[0]: http://www.leancrew.com/all-this/2012/04/where-modules-go-to...
Disclaimer, I'm not a C++ guy.
I agree that a truly solid package system, is inherently a good thing for any framework. But it has to be just that. Qt is severely lacking in that aspect; qpm isn't even close IMO.
Counter to your point though, just take a look at the ecosystem around NPM for instance. What a mess...
For a cross platform development framework, to truly shine, I need to be able to "trust", that my majority use case is covered within the framework itself, so I don't have to go package shopping and spend a lot of time on quality controlling vendored code.
For a mobile app framework, I want the most ubiquitous device capabilities covered. That means various hardware specific things, such as networking, gps, bluetooth and yes, the camera. Whatever is to be expected present on most devices.
So yeah, I guess it boils down to dependability and trust. Something which is implicit in the framework and core library for the most part.
I agree that a truly solid package system, is inherently a good thing for any framework. But it has to be just that. Qt is severely lacking in that aspect; qpm isn't even close IMO.
Counter to your point though, just take a look at the ecosystem around NPM for instance. What a mess...
For a cross platform development framework, to truly shine, I need to be able to "trust", that my majority use case is covered within the framework itself, so I don't have to go package shopping and spend a lot of time on quality controlling vendored code.
For a mobile app framework, I want the most ubiquitous device capabilities covered. That means various hardware specific things, such as networking, gps, bluetooth and yes, the camera. Whatever is to be expected present on most devices.
So yeah, I guess it boils down to dependability and trust. Something which is implicit in the framework and core library for the most part.
In this case, the camera package they linked to is being developed by the Flutter team, so... the quality controls are surely in line with the core library. Having it outside the core offers a number of benefits, as I mentioned.
You're right. I didn't actually know that was the case. That makes inclusion in a project a much easier decision.
Tim Sneath linked to the official plugins list in another comment, https://github.com/flutter/plugins, and both camera, sensors and connectivity, would be akin to the kind of ownership I'd expect. It's definitely a good start.
Tim Sneath linked to the official plugins list in another comment, https://github.com/flutter/plugins, and both camera, sensors and connectivity, would be akin to the kind of ownership I'd expect. It's definitely a good start.
> But, that's almost the same as not having support at all.
Please explain your logic here.
Please explain your logic here.
When the mental burden of integrating existing libraries, through tons of wrapping/boilerplating, such as it is with JNI, starts to overshadow rebuilding the same thing, at your current application layer, it's close to a zero value proposition.
That's a lot of negative assumptions you're making. And, IMHO, still not enough to warrant or in line with saying "that's almost the same as not having support at all."
It is very similar to having no support at all, since any language supports calling any other language by way of manually written bridges and wrappers – so if that's "support" then the set of languages without such support is empty.
React Native will get rid of bridge costly serialization/deserialization for crutial parts like animations very soon. See talk https://www.youtube.com/watch?v=UcqRXTriUVI If you had already invested in RN, i wouldn't jump to flutter and rather wait. From what I read here on HN, even Android team is kind of skeptical about flutter (but maybe they are also about RN, who knows).
What I personally don't like about flutter is that I have to learn new language (which I cannot use anywhere else), ui components will never look look same as native (specially visible when you would like to mix native part of application with part written in flutter) and far less components and libraries to choose from than RN.
But of course there are some benefits on flutter's side too. Article covers that pretty much.
What I personally don't like about flutter is that I have to learn new language (which I cannot use anywhere else), ui components will never look look same as native (specially visible when you would like to mix native part of application with part written in flutter) and far less components and libraries to choose from than RN.
But of course there are some benefits on flutter's side too. Article covers that pretty much.
The hot reload feature makes all the negatives seem trivial. I cannot stress enough how much productivity improves when you can see your changes in less than a second.
big YES! RN has that too, and it was one of its main benefits for me...for the rest, the experience with RN is not as friendly as it is with Flutter...
http://www.injectionforxcode.com lets you hot load swift/objc
Injection is a nice project, but it’s fundamentally limited to what the what the Objective-C runtime allows.
RN has hot reload too.
When I first tried flutter I thought writing Dart was going to annoy me. But I quickly realized how similar it is to C# and loved it. The vscode experience from nothing to hello world app running on my device was amazingly intuitive.
> which I cannot use anywhere else
You can certainly use Dart in the server, and even compiled to JavaScript in the browser (which I believe was its initial purpose).
You can certainly use Dart in the server, and even compiled to JavaScript in the browser (which I believe was its initial purpose).
There is also angular dart. https://webdev.dartlang.org/angular
Yes in theory. But in practice ES6 or typescript is far more popular and usage of Dart in such use cases is marginal. My point is that, Dart can be used in web dev, but for most devs using flutter means to learn Dart first as they normally would choose ES6 or typescript.
Ive been using RN for the last 6-8 months and love it. I have no plans to leave it anytime soon
I make Cordova, React Native, NativeScript and now Flutter plugins for a living. I’ve been using RN since it was born and I use it every day.
Flutter has a superior developer experience in my opinion.
Dart was a breeze to pick up.
Flutter has a superior developer experience in my opinion.
Dart was a breeze to pick up.
I guess you don't write flutter plugins in Dart or are you?
What kind of plugins do you make?
I specialize in background geolocation.
React Native
- https://github.com/transistorsoft/react-native-background-ge...
- https://github.com/transistorsoft/react-native-background-fe...
Flutter
https://github.com/transistorsoft/flutter_background_geoloca...
https://github.com/transistorsoft/flutter_background_fetch
React Native
- https://github.com/transistorsoft/react-native-background-ge...
- https://github.com/transistorsoft/react-native-background-fe...
Flutter
https://github.com/transistorsoft/flutter_background_geoloca...
https://github.com/transistorsoft/flutter_background_fetch
> Debugging is not at its best.
I don't think the author correctly represents this functionality in flutter.
I've found the debugging of flutter apps inside Android Studio to be excellent! You add a break point (by clicking on the lane to the left of your code or hitting some keyboard shortcut) and execution will be stopped and you can step through etc etc..
Using print statements to debug is slow and cumbersome, debugging in flutter is not.
I don't think the author correctly represents this functionality in flutter.
I've found the debugging of flutter apps inside Android Studio to be excellent! You add a break point (by clicking on the lane to the left of your code or hitting some keyboard shortcut) and execution will be stopped and you can step through etc etc..
Using print statements to debug is slow and cumbersome, debugging in flutter is not.
I'm a backend developer; so not much stake in this game. But honest question: why does this need a relatively unknown and unloved language, i.e. Dart? I mean Google just made a big commitment to Kotlin, which is awesome (using it on the backend) and has lots of momentum, and does native compilation as well. So what is up with Dart, aka yet another language not quite unlike swift, java, javascript, c# and indeed kotlin? They've been pushing Dart for nearly a decade and I've yet to meet a single developer specializing in it. I more or less considered this completely dead, obsolete, irrelevant, and forgotten until Google started talking about this flutter thing.
Why is this language needed at all? What's so good about this flutter thing that it could not possibly be done with other languages (i.e. Kotlin) but must have its own language (and associated tools, and other cruft).
I mean, I look at this and think: when is Google going to walk away from this one (again)? Or did they already and just not bother to inform the poor people behind it. It sort of fits in a long line of Google abandon ware. Call me cynical but; really honestly: is this a last ditch attempt at getting Dart on people's agenda or just plain and simple dead on arrival abandon ware.
Why is this language needed at all? What's so good about this flutter thing that it could not possibly be done with other languages (i.e. Kotlin) but must have its own language (and associated tools, and other cruft).
I mean, I look at this and think: when is Google going to walk away from this one (again)? Or did they already and just not bother to inform the poor people behind it. It sort of fits in a long line of Google abandon ware. Call me cynical but; really honestly: is this a last ditch attempt at getting Dart on people's agenda or just plain and simple dead on arrival abandon ware.
Technical reasoning for Dart: https://hackernoon.com/why-flutter-uses-dart-dd635a054ebf
https://flutter.io/docs/resources/faq#why-did-flutter-choose...
As for having to learn another language- Dart seems simple and boringly conventional enough to pick up. And it's not as if there isn't ample precedence for mobile engineers having to learn a niche language to make apps. How many Swift, Kotlin, or Objective-C uses are there outside of mobile apps right now? How many servers are running Vapor? How many programs are using Kotlin/Native?
Which isn't a knock on those projects. Like Flutter, they're all relatively new endeavors using fairly new languages. And so, Dart might not be used as much yet, as it's not the native language of choice, and Google's attempts to promote it in web haven't caught on, but low adoption at the beginning doesn't mean it's fundamentally unsound.
https://flutter.io/docs/resources/faq#why-did-flutter-choose...
As for having to learn another language- Dart seems simple and boringly conventional enough to pick up. And it's not as if there isn't ample precedence for mobile engineers having to learn a niche language to make apps. How many Swift, Kotlin, or Objective-C uses are there outside of mobile apps right now? How many servers are running Vapor? How many programs are using Kotlin/Native?
Which isn't a knock on those projects. Like Flutter, they're all relatively new endeavors using fairly new languages. And so, Dart might not be used as much yet, as it's not the native language of choice, and Google's attempts to promote it in web haven't caught on, but low adoption at the beginning doesn't mean it's fundamentally unsound.
It seems to mostly boil down to the fact that they were able to work together with the Dart team to integrate the tooling, compiler and VM to provide a good debugging and hot reloading experience.
Kotlin/Native was not really ready at the time they started on Flutter.
But otherwise, I think Kotlin would be a much better fit, since it has fairly unique features to support building UI hierarchies[1] in code the way Flutter wants to do[2], which Dart lacks. They way this kind of code has to be written in Dart reminds me of old Java code, with callbacks using anonymous classes for lack of lambda functions.
[1] https://kotlinlang.org/docs/reference/type-safe-builders.htm...
[2] https://flutter.io/docs/development/ui/layout#step-2-impleme...
Kotlin/Native was not really ready at the time they started on Flutter.
But otherwise, I think Kotlin would be a much better fit, since it has fairly unique features to support building UI hierarchies[1] in code the way Flutter wants to do[2], which Dart lacks. They way this kind of code has to be written in Dart reminds me of old Java code, with callbacks using anonymous classes for lack of lambda functions.
[1] https://kotlinlang.org/docs/reference/type-safe-builders.htm...
[2] https://flutter.io/docs/development/ui/layout#step-2-impleme...
I have been doing a lot of research recently on Flutter, and sadly there are a lot of "little things" that end up feeling like showstoppers, at least if you want to support iOS, that all stem from a combination of its premise (to reimplement all of the UI) and its focus (which seems to be Android first). Here are a few examples that mattered to me: the keyboard input has tons of open issues that make it seem unusable (and what app doesn't need good text input...), taking photos with the camera picker apparently strips all of the EXIF data (which means the photo is going to show up in the wrong orientation with the wrong gamma, and so look totally broken), and despite constantly reading "they spent a ton of time making the accessibility work", if you actually glance through their issue tracker there are lots of accessibility issues that would seem to be serious problems for users relying on VoiceOver (and then of course, there are tons of accessibility features on iOS that are for people with other disabilities, and pretty much none of them are implemented at all for Flutter as these are all subtle changes to the native controls, each of which they are slowly reimplementing).
https://github.com/flutter/flutter/issues/12920 https://github.com/flutter/flutter/issues/9507 https://github.com/flutter/flutter/issues/20693
https://github.com/flutter/flutter/issues/24575 https://github.com/flutter/flutter/issues/24574 https://github.com/flutter/flutter/issues/18391
https://github.com/flutter/flutter/issues/1668 https://github.com/flutter/flutter/issues/14543
https://github.com/flutter/flutter/issues/4830 https://github.com/flutter/flutter/issues/4827 https://github.com/flutter/flutter/issues/4826
And like... there are even serious issues on Android, stemming from a massive argument about how the core developers of Flutter don't want to support synchronous callbacks into the Dart isolate even though there are tons of Android lifecycle APIs that fundamentally require synchronous delegates :/. This issue is so serious that it supposedly makes Flutter entirely unusable on many Android devices, as it can't react to memory pressure requests (which means activities get destroyed) but also is unable to implement the save/restore state mechanism (so views come back either in subtly wrong ways or even entirely broken); and so people have been reporting that it is literally impossible to use the photo picker on smaller Android devices (as that is a widget that deterministically causes memory pressure).
https://github.com/flutter/flutter/issues/6827 (opened Nov 2016) https://github.com/flutter/engine/pull/4358 ("closed" due to being rejected)
https://github.com/flutter/flutter/issues/15479 https://github.com/flutter/flutter/issues/15478 https://github.com/flutter/flutter/issues/15476
https://github.com/flutter/flutter/issues/21102 https://github.com/flutter/flutter/issues/18059 https://github.com/flutter/flutter/issues/17186
https://github.com/flutter/flutter/issues/17165 https://github.com/flutter/flutter/issues/18700 https://github.com/flutter/flutter/issues/17950
Essentially, I highly encourage anyone attempting to use pretty much anything to sit around and read through the open issues and look at what is currently being built vs. what is still on the roadmap, as the marketing messages behind a lot of these projects might say "we now support so many more iOS controls and it is amazing" while the reality on the ground is that the controls they have might only sort of work and the things that you need might not only not yet be done but might be on the list of things that the project has some philosophical aversion to (which is the case with the Android issues there: if any of those things will cause you a problem, you might be waiting for years to see fixes for them, as the obvious fix was rejected).
https://github.com/flutter/flutter/issues/12920 https://github.com/flutter/flutter/issues/9507 https://github.com/flutter/flutter/issues/20693
https://github.com/flutter/flutter/issues/24575 https://github.com/flutter/flutter/issues/24574 https://github.com/flutter/flutter/issues/18391
https://github.com/flutter/flutter/issues/1668 https://github.com/flutter/flutter/issues/14543
https://github.com/flutter/flutter/issues/4830 https://github.com/flutter/flutter/issues/4827 https://github.com/flutter/flutter/issues/4826
And like... there are even serious issues on Android, stemming from a massive argument about how the core developers of Flutter don't want to support synchronous callbacks into the Dart isolate even though there are tons of Android lifecycle APIs that fundamentally require synchronous delegates :/. This issue is so serious that it supposedly makes Flutter entirely unusable on many Android devices, as it can't react to memory pressure requests (which means activities get destroyed) but also is unable to implement the save/restore state mechanism (so views come back either in subtly wrong ways or even entirely broken); and so people have been reporting that it is literally impossible to use the photo picker on smaller Android devices (as that is a widget that deterministically causes memory pressure).
https://github.com/flutter/flutter/issues/6827 (opened Nov 2016) https://github.com/flutter/engine/pull/4358 ("closed" due to being rejected)
https://github.com/flutter/flutter/issues/15479 https://github.com/flutter/flutter/issues/15478 https://github.com/flutter/flutter/issues/15476
https://github.com/flutter/flutter/issues/21102 https://github.com/flutter/flutter/issues/18059 https://github.com/flutter/flutter/issues/17186
https://github.com/flutter/flutter/issues/17165 https://github.com/flutter/flutter/issues/18700 https://github.com/flutter/flutter/issues/17950
Essentially, I highly encourage anyone attempting to use pretty much anything to sit around and read through the open issues and look at what is currently being built vs. what is still on the roadmap, as the marketing messages behind a lot of these projects might say "we now support so many more iOS controls and it is amazing" while the reality on the ground is that the controls they have might only sort of work and the things that you need might not only not yet be done but might be on the list of things that the project has some philosophical aversion to (which is the case with the Android issues there: if any of those things will cause you a problem, you might be waiting for years to see fixes for them, as the obvious fix was rejected).
Thank you for providing these detailed examples, some of these are serious showstoppers indeed and indicate this project is still very much in the alpha stage. It's always seemed to me that frameworks that try to emulate native UI widgets are continually chasing a moving target and the results can be quite hit or miss.
This is really interesting, thanks!
It makes me wonder if the flutter team is aiming to totally replace native apps or replace 'most' native apps, because I tend to agree with Hixie re the synchronous calls, but only in 90% of app use-cases.
The iOS text stuff is surprising, though, especially since the last beta release had a 'Pixel Perfect Cupertino' focus. Hopefully will be fixed before they bring out 1.0
It makes me wonder if the flutter team is aiming to totally replace native apps or replace 'most' native apps, because I tend to agree with Hixie re the synchronous calls, but only in 90% of app use-cases.
The iOS text stuff is surprising, though, especially since the last beta release had a 'Pixel Perfect Cupertino' focus. Hopefully will be fixed before they bring out 1.0
thank you for the insight and I couldn't agree more with your closing paragraph.
I've been thinking about trying flutter for a fun little side project; now I'm going to browse through open issues and see if anything seems like a showstopper. hope not because flutter seems neat and RN scares me.
https://github.com/flutter/flutter/issues
I've been thinking about trying flutter for a fun little side project; now I'm going to browse through open issues and see if anything seems like a showstopper. hope not because flutter seems neat and RN scares me.
https://github.com/flutter/flutter/issues
Thank you! I did an hour and a half of reading last night on these. Especially on https://github.com/flutter/engine/pull/4358. Very, very interesting and certainly put me on a watch out about Flutter.
Also, this should really be a top comment.
Also, this should really be a top comment.
Man, this issue is really damning.
Flutter team member here.
Just letting you know we haven't forgotten about these issues and will be getting to them in the coming months. The iOS text issues, specifically, have someone looking into them sooner rather than later.
Just letting you know we haven't forgotten about these issues and will be getting to them in the coming months. The iOS text issues, specifically, have someone looking into them sooner rather than later.
One year and counting since I've been watching this issue (just to trigger "Next" on the keyboard); it's finally on their "near-term radar":
https://github.com/flutter/flutter/issues/11344
https://github.com/flutter/flutter/issues/11344
This is probably the most informative critique of Flutter that I've read. Should be higher up on the thread. Thanks!
a combination of its premise (to reimplement all of the UI)
This, in particular, even with Google-level attention and resources, seems like a design dead end, at least for third party apps.
This, in particular, even with Google-level attention and resources, seems like a design dead end, at least for third party apps.
Note that the truth is more complicated than that "Skia is the graphics engine for Mozilla Firefox". Firefox does use Skia on many platforms right now, but on Windows (by far the most popular platform) Direct2D is mostly used instead. Moreover, at the moment we're in the process of switching to WebRender, which represents an approach quite different from legacy APIs like Skia.
Flutter has a lot of potential. If Google also officially supported macOS and Windows (even without the native components) it would be amazing.
I'm working on just such a project:
https://feather-apps.com/
(although it's not officially supported by Google)
https://feather-apps.com/
(although it's not officially supported by Google)
Is this Open-sourced? looking at the website it doesn't seem like it
No the code we write is mostly closed-source, but it is based on this open-source project: https://github.com/google/flutter-desktop-embedding
So how are you going to monetize this?
do you plan on open sourcing? what are your plans?
No, it's a commercial product. At some point we will charge a fee to publish apps on our platform.
I know!
How is that going btw?
How is that going btw?
Pretty good! We're planning to have our first public release next week (for Mac, not Windows yet). You can register to be notified of new releases here: https://feather-apps.com/#cta-5
Yes I would normally expect "cross-platform" to indicate support for iOS, Android, macOS, and Windows... not just the first two.
The down sides for me for me are Dart - no thanks to learning another language, and to Google lock in. As others have pointed out, Google has a pattern of developing and then abandoning products and technology. See https://gcemetery.co/
It's a good language though, and if you have experience with C#/Swift/Kotlin/Java etc...you'll be productive from day 1...there's not really much to learn, I wouldn't call it a problem.
My concern about Dart wouldn't so much be language quality, it would be the ecosystem. I know if I go out there and do a project in JavaScript or C# (so RN/Xamarin) there's piles of libraries out there. There's documentation. There's Stack Overflow answers and tutorials.
Did you just say that Dart is a good language? You're aware of the memes about Dart's type system being completely broken by design right?
https://www.dartlang.org/faq#q-why-are-generics-covariant
Of course this is from the company that brought us interface{} and people seem to be OK with that...
https://www.dartlang.org/faq#q-why-are-generics-covariant
Of course this is from the company that brought us interface{} and people seem to be OK with that...
Flaws in the type system just aren't that important to most people. Consider the popularity of Typescript, which is unsound.
I gather that you would prefer invariant generics. I know a bit about type systems but very little about subtyping so I would really enjoy some information :)
Why are covariant generics bad? (also just a link is fine)
Why are covariant generics bad? (also just a link is fine)
Invariant generics would at least let you rely on the type system doing its job correctly. But even better would be to annotate each type parameter as covariant, contravariant, or invariant - this is what Scala and C# and probably a bunch of other languages do.
As an example, here's approximately how the Function trait is defined in Scala. The square brackets indicate type parameters (like angle brackets in Java), the - indicates covariance, and the + indicates contravariance.
As an example, here's approximately how the Function trait is defined in Scala. The square brackets indicate type parameters (like angle brackets in Java), the - indicates covariance, and the + indicates contravariance.
trait Function1[-T, +R] {
def apply(arg1: T): R
}It's open source, so the lock in shouldn't be an issue.. My first reaction when hearing about it was to wonder how good the ffi in Dart is. Would it be possible to interface to Flutter from different languages? Then I would definitely be interested..
People say this but having the right backing is important for something so essential to a project. Having a big company behind the development and especially dogfooding makes a world of difference in terms of stability.
GWT is 12 years old, Android is 10 years old, Go is 9 years old, Dart is 7 years old.
I'd say their client platforms are OK.
Another thing I'd point out is that the flutter widgets themself have perhaps the most extensive, and useful, documentation in code I've come across. If you're using an editor that let's you "click through" into the thing you're calling then it's almost all the documentation you need!
Co-creator of Selenum 1.0 checking in. My part of the 2004 Selenium was the wire protocol that allowed one process (the Java/Ruby/C#/Python test runner) to control the other (the browser). In so doing implemented a rudimentary COMET protocol, as it happens.
Anyway, FlutterDriver is pretty frickin limited. Its like Selenium-RC without the XPath. Thank Turing that Simon Stewart and WebDriver came along and did a reverse takeover of Selenium. Selenium on my MacBookAir for perfected build toolchains can zip along at 3-5 tests as second with the browser open and you being able to roughly see what it is doing. Not 3-5 clicks a second, 3-5 tests a second.
FlutterDriver, by contrast is 5x slower. And even then that's only after the APK has been shoved into the emulator which can be minutes on my MBA. It feels to me like the FlutterDriver tests are being added to the APK being sent to the emulator, and then phoning home with minimal output of the run (not withstanding the ability to attach a debugger). There's no doubt that the better solution would be to open a socket to the host OS's test-runner process and chat back and forth about direction of the testing. If needs be, that shitty Selenium-RC COMETalike way , but there's no reason a whole bunch of telemetry couldn't be traded too if a BEEPlike protocol were developed. And the running process shouldn't be constrained to Dart. Some teams will want their test runner logic in another 3GL like Python.
Then there's the lack of reflection. I may agree that production apps may want to explicitly turn off reflection in order to be more efficient. But for test-automation purposes it is great (e.g. Gherkin), and it would be nice of there were some effort to publish patterns and set policy that would allow that way of working to be lasting.
Also, Apple are way ahead with a simulator for iOS and the XCode toolchain that's so much faster for testing considerations. Faster than a reliance on QEMU - at lest on busy 8GB machines. I bought a Mac Mini two days ago, mostly because of Flutter really, but general bloat too.
Anyway, FlutterDriver is pretty frickin limited. Its like Selenium-RC without the XPath. Thank Turing that Simon Stewart and WebDriver came along and did a reverse takeover of Selenium. Selenium on my MacBookAir for perfected build toolchains can zip along at 3-5 tests as second with the browser open and you being able to roughly see what it is doing. Not 3-5 clicks a second, 3-5 tests a second.
FlutterDriver, by contrast is 5x slower. And even then that's only after the APK has been shoved into the emulator which can be minutes on my MBA. It feels to me like the FlutterDriver tests are being added to the APK being sent to the emulator, and then phoning home with minimal output of the run (not withstanding the ability to attach a debugger). There's no doubt that the better solution would be to open a socket to the host OS's test-runner process and chat back and forth about direction of the testing. If needs be, that shitty Selenium-RC COMETalike way , but there's no reason a whole bunch of telemetry couldn't be traded too if a BEEPlike protocol were developed. And the running process shouldn't be constrained to Dart. Some teams will want their test runner logic in another 3GL like Python.
Then there's the lack of reflection. I may agree that production apps may want to explicitly turn off reflection in order to be more efficient. But for test-automation purposes it is great (e.g. Gherkin), and it would be nice of there were some effort to publish patterns and set policy that would allow that way of working to be lasting.
Also, Apple are way ahead with a simulator for iOS and the XCode toolchain that's so much faster for testing considerations. Faster than a reliance on QEMU - at lest on busy 8GB machines. I bought a Mac Mini two days ago, mostly because of Flutter really, but general bloat too.
It's totally fair to say that flutter_driver isn't a great experience today. The reality is that you hardly ever need to use it, though, because you can do pretty much everything you want using unit tests (including doing golden file tests). We mostly only use driver tests for on-device benchmarks.
Is react native really on it's way out ? I was about to start a new expo project and invest some time in building something i plan to stick in the google app store.
I think React Native is still a good choice, for now; lots of apps use it, and it can allow you to share JS code between mobile apps and web apps. I'd still personally recommend checking flutter out though, it makes for some buttery smooth apps.
I have an enterprise B2B app on react native with expo and the experience is great. Code push (over the air updates) on expo is a killer feature and something which Flutter doesn't seem to have yet. If you are a small team that uses/knows React then React Native can be a better choice if there isn't a compelling reason not to use it.
I don't think React Native on the way out, but there has been a public perception wave against it this year with AirBnB and Udacity publicly abandoning it.
My main problem with using anything from Google is that I work on projects that may end up in production for years, and Google's history of playing fast and loose with (or shit-canning) the frameworks it develops doesn't inspire much confidence.
Fortunately for me UI dev isn't my primary role.
Fortunately for me UI dev isn't my primary role.
Tell that to the Go crowd :(
I’m not sure i understand your comment : do you think go is going to be cut off by google anytime soon ??
"cut off ... soon" is an exaggeration and not what I've said.
I've been around a while and seen many languages and products being developed and hyped up by one company for 5, 10, 15 years and then bent out of shape, or sold out, or being put on life support. Sometimes when the company wants to push a new, competing product, often times their priorities change and they stop focusing on the needs of the developer community.
Fair enough, though Go would probably be dead if it suffered the same churn as Google's frontend projects.
[deleted]
If Flutter was js + jsx I'd jump right in.
Funny...one of the reasons I like it (and prefer it over RN) is that it doesn't use JS :)
We started with JavaScript actually. We switched away from JavaScript because it was too quirky, among other things.
I would say it's a lot cleaner IMO. I much prefer function calls/constructors to HTML syntax, since it's so much more concise and readable if you indent properly.
BTW, for those looking for another option other than Flutter and React Native, check out NativeScript[0], or Nativescript-Vue[1].
Nativescript is different from react native because it includes a native call translation layer -- you can write JS that actually uses native runtime objects. It's also got excellent support for cross platform applications that reach down to native on both platforms, and can meld right in with a fully native app as well, and is thoroughly F/OSS (they take the marketplace approach to monetization).
Nativescript different from Flutter in that it has nothing to do with the tirefire that is Dart. Nativescript is OSS and is taking the marketplace approach to capitalizing and recently they got Hot Module Reloading as a result of integrating more closely with webpack/other capable bundlers.
I've recently done projects (one larger client app, another a small personal project) in both and kept some notes on what I liked about Nativescript vs Flutter (I'm pretty biased for Nativescript now), not sure if I'll make a blog post about it but here are some hopefully interesting points:
- Performance tradeoffs are roughly the same for dart vs nativescript, do hard work in an isolate (dart) or webworker(nativescript)
- Flutter's reactivity is 10x more tedious than Nativescript-Vue. Making an entire other class and doing all these overrides for what should be a basic feature is pretty ridiculous, though everyone's fine with it because they just right click in their $IDE.
- Flutter's data management is not great -- everything they've made so far seems like a hack. I'm uncomfortable with the build function being on the state object conceptually, InheritedWidgets are just using context as a grab-bag, the BLoC pattern is so complicated.
- State<MyPage> & StatefulWidget being separate classes and the State<MyPage> having the build function unsettles me. I don't know if it had to be this way because of dart 2's type system (which is subpar in my experience, Typescript is better because it at least offers duck-typed interfaces)
- Dart is terrible. It is a modern language yet it lacks almost none of the advances of modern languages, Dart 2 was a near rewrite and it it still manages to be less compelling than Typescript, and nowhere near languages like Go, Rust, Crystal, etc. I am kind of suspicious google is pushing this language just because they invented it and can control it -- I don't know a single redeeming quality of dart, especially if you consider dart 1 before you consider dart 2.
- Flutter subtly forces you into either Material Design or Cupertino -- this surprised me. Flutter subtly pushes you towards material design, which I have no interest in, and I think most people actually trying to create unique app experiences wouldn't either. This is a double edged sword, in Nativescript you have to seek out native-looking components, but in Flutter they're forced upon you especially at the beginning, and I prefer the former.
- Automatic sending of crash logs to Google -- who thought this was a good idea? And to make it opt-out instead of opt-in?
- Flutter probably has the better longer term viability because it's being embedded into Fuschia and other things google is doing.
- I expect Nativescript to eventually take on WASM and really open up the choices for languages to use with it.
[0]: https://docs.nativescript.org
[1]: https://nativescript-vue.org/
Nativescript is different from react native because it includes a native call translation layer -- you can write JS that actually uses native runtime objects. It's also got excellent support for cross platform applications that reach down to native on both platforms, and can meld right in with a fully native app as well, and is thoroughly F/OSS (they take the marketplace approach to monetization).
Nativescript different from Flutter in that it has nothing to do with the tirefire that is Dart. Nativescript is OSS and is taking the marketplace approach to capitalizing and recently they got Hot Module Reloading as a result of integrating more closely with webpack/other capable bundlers.
I've recently done projects (one larger client app, another a small personal project) in both and kept some notes on what I liked about Nativescript vs Flutter (I'm pretty biased for Nativescript now), not sure if I'll make a blog post about it but here are some hopefully interesting points:
- Performance tradeoffs are roughly the same for dart vs nativescript, do hard work in an isolate (dart) or webworker(nativescript)
- Flutter's reactivity is 10x more tedious than Nativescript-Vue. Making an entire other class and doing all these overrides for what should be a basic feature is pretty ridiculous, though everyone's fine with it because they just right click in their $IDE.
- Flutter's data management is not great -- everything they've made so far seems like a hack. I'm uncomfortable with the build function being on the state object conceptually, InheritedWidgets are just using context as a grab-bag, the BLoC pattern is so complicated.
- State<MyPage> & StatefulWidget being separate classes and the State<MyPage> having the build function unsettles me. I don't know if it had to be this way because of dart 2's type system (which is subpar in my experience, Typescript is better because it at least offers duck-typed interfaces)
- Dart is terrible. It is a modern language yet it lacks almost none of the advances of modern languages, Dart 2 was a near rewrite and it it still manages to be less compelling than Typescript, and nowhere near languages like Go, Rust, Crystal, etc. I am kind of suspicious google is pushing this language just because they invented it and can control it -- I don't know a single redeeming quality of dart, especially if you consider dart 1 before you consider dart 2.
- Flutter subtly forces you into either Material Design or Cupertino -- this surprised me. Flutter subtly pushes you towards material design, which I have no interest in, and I think most people actually trying to create unique app experiences wouldn't either. This is a double edged sword, in Nativescript you have to seek out native-looking components, but in Flutter they're forced upon you especially at the beginning, and I prefer the former.
- Automatic sending of crash logs to Google -- who thought this was a good idea? And to make it opt-out instead of opt-in?
- Flutter probably has the better longer term viability because it's being embedded into Fuschia and other things google is doing.
- I expect Nativescript to eventually take on WASM and really open up the choices for languages to use with it.
[0]: https://docs.nativescript.org
[1]: https://nativescript-vue.org/
We definitely don't intend to push you into Material... can you elaborate on that? What would we have to change for you to think we were not pushing you into Material?
Regarding the crash logs, it has definitely helped us improve stability. We do try hard to notify you that it's happening. It's opt-out because people don't tend to opt in to that kind of thing and so the data would be more or less useless (not representative of real usage) if we made it opt-in.
Regarding the crash logs, it has definitely helped us improve stability. We do try hard to notify you that it's happening. It's opt-out because people don't tend to opt in to that kind of thing and so the data would be more or less useless (not representative of real usage) if we made it opt-in.
Sorry for the delay in response, I didn't see this. I think the problem is kind of endemic -- it's kind of like all the documentation and everything always starts from a Material component. Like if you look at provided scaffolds and you see CupertinoScaffold in the Widget Index[0], you might expect MaterialScaffold to be an option as well, but it's just "Scaffold". Little things like this indicate that you expect "MaterialScaffold" to be the default resting state. 99% of the time when I'm writing an app I have the design already and it may or may not be in material style or Cupertino style -- I personally would expect a framework to offer general tools first then the specializations. There are a bunch of other example of components that only really work correctly in the Material context. It's not a huge thing, and Google does have a pony in the race (which makes it easier for me to tinfoilhat about it), you have every right to push material as the default/make it easier to work with -- but I enjoy not having any such bias with Nativescript, even if it costs me slightly more work to get components that are stylistically coherent with either paradigm.
From an engineering standpoint I absolutely understand the automatic crash logging, it's good that you're able to get the user data. I think you guys are just fine as I'm more tinfoil-hatty than 99% of the usual developer will ever be -- the average developer won't care. I don't know realistically how it could be improved without sacrificing that useful data, but maybe a notice @ install time? I just never saw any mention (I read through the docs, watched lots of video), and was surprised -- maybe the negative impression was amplified because I was having issues with flutter at the time. My thought/reaction at the time was that "Oh so a weird crash and you're sending the details back without me explicitly allowing it? classic google".
To wrap this up, I do want to thank you (I'm assuming you're on the flutter team) for the hard work -- drawing every pixel and building a composable, considered system to do that is very hard, and you've expanded the mobile development landscape, Flutter is unique in it's approach AFAIK, and I mention it any time I talk about the mobile dev continuum. Building flexibly to support multiple embedders is awesome and I'm sure flutter will go far.
[0]: https://flutter.io/docs/reference/widgets
From an engineering standpoint I absolutely understand the automatic crash logging, it's good that you're able to get the user data. I think you guys are just fine as I'm more tinfoil-hatty than 99% of the usual developer will ever be -- the average developer won't care. I don't know realistically how it could be improved without sacrificing that useful data, but maybe a notice @ install time? I just never saw any mention (I read through the docs, watched lots of video), and was surprised -- maybe the negative impression was amplified because I was having issues with flutter at the time. My thought/reaction at the time was that "Oh so a weird crash and you're sending the details back without me explicitly allowing it? classic google".
To wrap this up, I do want to thank you (I'm assuming you're on the flutter team) for the hard work -- drawing every pixel and building a composable, considered system to do that is very hard, and you've expanded the mobile development landscape, Flutter is unique in it's approach AFAIK, and I mention it any time I talk about the mobile dev continuum. Building flexibly to support multiple embedders is awesome and I'm sure flutter will go far.
[0]: https://flutter.io/docs/reference/widgets
It's always interesting to hear about lesser-known cross-platform solutions. Why do you think Nativescript never got the buzz that React Native, Flutter, Xamarin, or web-focused efforts like Ionic, have?
tl;dr - Progress (the company that sponsors Nativescript) doesn't the market/advertising dollars compared to Facebook/React, and Google/Flutter or MS/Xamarin.
Well I think the biggest difference is purchasing power of the companies behind those other solutions in terms of marketing. Flutter has gotten this the most right, so far -- they make very published developer resources, and market aggressively, they have things like the Flutter Development Show[0], and little 30 second clips introducing parts of the platform[1] . It's a good thing (they're innovating in the documentation/dev experience space), but taken cynically it's just a marketing ploy.
I hate to say it, but lately people have been applying the same advertising and marketing logic they use on consumers on developers rather than necessarily making the best product they can and letting word spread organically. It's a bit of a chicken and egg problem -- you usually can only build the best product with help from others, which means getting in front of them, but usually you want to make a good thing so you can justify getting in front of the developers in the first place... So people put out shitty tools, then just iterate after the community shows up and finds out there are lots of rough edges (see: mongo, react, dart, etc).
The last I'll say on the subject is that "developer evangelists" are basically paid marketers/advertisers.
Nativescript also has this thing where it was popular years ago, but has recently seen a surge in popularity -- you have projects like nativescript-exit[2] (which provides a cross platform way to exit the app from JS) that have code from 2 years ago. This is actually a really great point for nativescript, because solidly written plugins like nativescript-exit really are solid -- I very recently used it in a project and it just worked. The integration points available in Nativescript have a very high potential (not to say other platforms don't).
[0]: https://www.youtube.com/playlist?list=PLOU2XLYxmsIK0r_D-zWcm...
[1]: https://www.youtube.com/watch?v=R9C5KMJKluE
[2]: https://github.com/dvabuzyarov/nativescript-exit
Well I think the biggest difference is purchasing power of the companies behind those other solutions in terms of marketing. Flutter has gotten this the most right, so far -- they make very published developer resources, and market aggressively, they have things like the Flutter Development Show[0], and little 30 second clips introducing parts of the platform[1] . It's a good thing (they're innovating in the documentation/dev experience space), but taken cynically it's just a marketing ploy.
I hate to say it, but lately people have been applying the same advertising and marketing logic they use on consumers on developers rather than necessarily making the best product they can and letting word spread organically. It's a bit of a chicken and egg problem -- you usually can only build the best product with help from others, which means getting in front of them, but usually you want to make a good thing so you can justify getting in front of the developers in the first place... So people put out shitty tools, then just iterate after the community shows up and finds out there are lots of rough edges (see: mongo, react, dart, etc).
The last I'll say on the subject is that "developer evangelists" are basically paid marketers/advertisers.
Nativescript also has this thing where it was popular years ago, but has recently seen a surge in popularity -- you have projects like nativescript-exit[2] (which provides a cross platform way to exit the app from JS) that have code from 2 years ago. This is actually a really great point for nativescript, because solidly written plugins like nativescript-exit really are solid -- I very recently used it in a project and it just worked. The integration points available in Nativescript have a very high potential (not to say other platforms don't).
[0]: https://www.youtube.com/playlist?list=PLOU2XLYxmsIK0r_D-zWcm...
[1]: https://www.youtube.com/watch?v=R9C5KMJKluE
[2]: https://github.com/dvabuzyarov/nativescript-exit
NativeScript really? i had enough of XML in the last 20 years, it's also Telerik, well it's enough of that as well. I really like Fluter's new mindset.
lots of grammatical errors in this comment... but this one was the worst:
"lacks almost none of the advances" -> "lacks almost all the advances" (I was talking about the typing stuff...)
Apologies for the repeating of several points... This comment is pretty badly written and I can't edit it now.
"lacks almost none of the advances" -> "lacks almost all the advances" (I was talking about the typing stuff...)
Apologies for the repeating of several points... This comment is pretty badly written and I can't edit it now.
Does Flutter (and related tooling) offer anything to push small code changes out to devices without doing a full version update to the app stores (similar to what can be done with React Native)?
Flutter is compiled to native ARM code, and as such doesn't allow this functionality. This exact limitation is mentioned in the article.
In my experience these cross-platform tools (Flutter/RN) have such a limited use-case that they are rarely worth it. Even basic stuff (navigation) require huge amateur libraries that barely work. Couple that with the dumpster fire that is javascript and it's a recipe for disaster.
An organization wants their app to run on both mobile platforms. That's not a limited use case.
I had the exact oposite experience.
Native apps are rarely worth it and cross-platform tools are mostly enough for more than 90% of use-cases.
I think native apps only make sense when custom platform specfic code makes up more than 50% of your app. How often is this the case?
Native apps are rarely worth it and cross-platform tools are mostly enough for more than 90% of use-cases.
I think native apps only make sense when custom platform specfic code makes up more than 50% of your app. How often is this the case?
True. Yet managers love them because these tools promise the ultimate pipe dream: uniform, interchangeable engineers.
Still waiting for Kotlin to be the 1-stop shop for app development.
Serious question: why do people, software developers actually, use Medium for blogging?
- they nag mobile users to install a shitty app "optimized for readers" because apparently the browser is no longer suitable for freaking blogs
- they nag desktop users to login
- they are in fact not GDPR compliant
- the downloaded pages are huge, the browser ends up downloading and interpreting over 2 megabytes of crap in order to display 3 paragraphs of text
- the domain name isn't yours so you can lose your content and your identity and it isn't easy to port to other platforms
Why do you put up with this shit?
I have a blog built with a static site generator since 2008, with minimal maintenance and costs required, on my own domain, with changes tracked in Github. My blog is at this point at least 4 years older than all Medium accounts and will probably outlast Medium.
This may not be for your grandmother, but you're a software developer and the setup would take you one day of work. It actually takes more than that to write a good article.
- they nag mobile users to install a shitty app "optimized for readers" because apparently the browser is no longer suitable for freaking blogs
- they nag desktop users to login
- they are in fact not GDPR compliant
- the downloaded pages are huge, the browser ends up downloading and interpreting over 2 megabytes of crap in order to display 3 paragraphs of text
- the domain name isn't yours so you can lose your content and your identity and it isn't easy to port to other platforms
Why do you put up with this shit?
I have a blog built with a static site generator since 2008, with minimal maintenance and costs required, on my own domain, with changes tracked in Github. My blog is at this point at least 4 years older than all Medium accounts and will probably outlast Medium.
This may not be for your grandmother, but you're a software developer and the setup would take you one day of work. It actually takes more than that to write a good article.
> Serious question: why do people, software developers actually, use Medium for blogging?
Serious question: why first comment on HN have to be totally unrelated to the fine article?
Do we really need to discuss medium issues every time a blog post entry is posted here, instead of discussing the post itself.
Serious question 2: Why don't you write a blog post about "Using Medium for blogging" on your own static self-hosted blog, and put a link here for discussing it?
Serious question: why first comment on HN have to be totally unrelated to the fine article?
Do we really need to discuss medium issues every time a blog post entry is posted here, instead of discussing the post itself.
Serious question 2: Why don't you write a blog post about "Using Medium for blogging" on your own static self-hosted blog, and put a link here for discussing it?
thank you for saying that. so annoying
In my case, it's not at all for the network effect, since these days they have too much content and anyway favor "premium" posts in terms of visibility...so for me it's more about the following:
* I don't need to create my own blog. I know, it takes a 5 minutes, have done it many many times before...just to kill it some time after because seeing it so empty was too sad. With Medium you publish whenever you want, and because it's not really "your blog", it doesn't feel as sad if you don't publish anything for months and months.
* it's super simple to paste images, code snippets and videos. I can just focus on writing and I know it will "look good" in the end. Sounds stupid, but it's true.
* I don't have to worry about spam comments, t&c, privacy policy (if I want to have analytics, which Medium has) etc...it's all on them
So yes, for a non-prolific writer, I think it works well. It's a pity they no longer allow custom domains though (which they had in the past), and at times it's toooo limited (eg: no nested bulleted/numbered lists...which I usually used a lot), but still good enough.
I'd probably switch to my own blog if were to publish stuff regularly and wanted to have my own "brand"/style/design.
* I don't need to create my own blog. I know, it takes a 5 minutes, have done it many many times before...just to kill it some time after because seeing it so empty was too sad. With Medium you publish whenever you want, and because it's not really "your blog", it doesn't feel as sad if you don't publish anything for months and months.
* it's super simple to paste images, code snippets and videos. I can just focus on writing and I know it will "look good" in the end. Sounds stupid, but it's true.
* I don't have to worry about spam comments, t&c, privacy policy (if I want to have analytics, which Medium has) etc...it's all on them
So yes, for a non-prolific writer, I think it works well. It's a pity they no longer allow custom domains though (which they had in the past), and at times it's toooo limited (eg: no nested bulleted/numbered lists...which I usually used a lot), but still good enough.
I'd probably switch to my own blog if were to publish stuff regularly and wanted to have my own "brand"/style/design.
I don't use Medium but I know one big reason is for their network and promotional features. If you're not active on social media and don't have a big following you can post your blog posts to, then Medium helps disseminate your writing to a larger audience with similar interests.
Sure, but a blog is how you get a social media following.
I don't buy that Medium can do a better job of connecting you with people. For programming you can just take that link and post it on Reddit and you'll get plenty of visitors.
I don't buy that Medium can do a better job of connecting you with people. For programming you can just take that link and post it on Reddit and you'll get plenty of visitors.
It's not either/or, it's all of the above. They blog on Medium, leverage its network, and post on reddit/Twitter/etc.
In addition, the lack of syntax highlighting means authors have to either
- deal with shitty monochrome code
- have unsearchable and uncopyable screenshots
- embed a gist iframe
All of these suck. Jekyll/Hugo/every other blogging solution has this feature out of the box as table stakes.
- deal with shitty monochrome code
- have unsearchable and uncopyable screenshots
- embed a gist iframe
All of these suck. Jekyll/Hugo/every other blogging solution has this feature out of the box as table stakes.
Wat. 1 day of work for a SV dev is at least 1000 dollars, that's far too expensive.
I agree and people who say about Medium's networking abilities, well WordPress already does this. You can self-host your blog using WordPress and connect it to their WordPress.com site using JetPack. Hey presto, you have a huge network of WordPress Bloggers with the advantages of controlling your own Blog.
Also, I applaud you on creating your own blog using a static site generator, the speed improvements and easier reading are great. I do however hope you also have an RSS feed so readers can subscribe and syndicate it[0].
[0] https://developer.mozilla.org/en-US/docs/Web/RSS/Getting_Sta...
Also, I applaud you on creating your own blog using a static site generator, the speed improvements and easier reading are great. I do however hope you also have an RSS feed so readers can subscribe and syndicate it[0].
[0] https://developer.mozilla.org/en-US/docs/Web/RSS/Getting_Sta...
no one really uses RSS anymore imo, i just "subscribe" to the author on twitter - that way i get more interaction than just notification of articles
It's the experience of reading comments that does it for me. It's just so poor.
It's really bad. On my small phone in landscape orientation, the header has a height of 1.5 cm, the footer 1.0 cm and the content 3 cm.
Network effect of medium could be one
Why are they not GDPR compliant?
> you're a software developer and the setup would take you one day of work
I hear this a lot and I don't get it. Just because I'm tech savvy doesn't mean I want to do everything myself. My time on earth is finite like everyone else's. I don't value it less just because I can program.
I've built my own blog many times, actually. But the purpose of a blog is to write and share content. Every second I spend messing with the blog is energy I could've allocated towards writing content.
Also, static site generators tend to not have nice publishing editors, like the ability to just drag an image in.
But we really need to dispose of this idea that "you can build anything so why don't you want to build everything?" I also think hosting my email is a waste of my time.
I hear this a lot and I don't get it. Just because I'm tech savvy doesn't mean I want to do everything myself. My time on earth is finite like everyone else's. I don't value it less just because I can program.
I've built my own blog many times, actually. But the purpose of a blog is to write and share content. Every second I spend messing with the blog is energy I could've allocated towards writing content.
Also, static site generators tend to not have nice publishing editors, like the ability to just drag an image in.
But we really need to dispose of this idea that "you can build anything so why don't you want to build everything?" I also think hosting my email is a waste of my time.
I know the article says that mostly techies will care, but has there ever been research into seeing if normal users care about native? When I look at many apps on the market, they are so heavily themed that the nativeness is hard to find. When I worked with Ionic one of the issues was how jarring it would be for people in iOS. Has anyone seen this concern become a reality?
Normal people don’t know the difference and even experienced people can be fooled.
Anecdote: I have an Ionic app that is used by 15,000 people daily. It looks like a native app. Nobody ever wrote me an email that the app is not native, not fast enough or anything else. Normal people want to get their shit done and move on.
Heck, one user apparently was a dev and came up with a suggestion (enable keyboard suggestions for text input fields) and he wrote me specifically which iOS UI element I should choose over some other element he thought I was using. I replied: thanks, but this is an Ionic app, it doesn’t use native iOS elements ;)
Native apps are totally overrated imho, unless you make heavy use of fine-grained input controls. Here, Ionic does have its limits. You can’t control the keyboard properly for example, unless you wire in some Cordova plugins.
Oh and JS doesn’t run in the background. This can cause issues if you do a lot of background processing.
But performance is not much of an issue anymore in 2018 and Ionic is the most polished web-based framework that is tough to distinguish from native apps.
Anecdote: I have an Ionic app that is used by 15,000 people daily. It looks like a native app. Nobody ever wrote me an email that the app is not native, not fast enough or anything else. Normal people want to get their shit done and move on.
Heck, one user apparently was a dev and came up with a suggestion (enable keyboard suggestions for text input fields) and he wrote me specifically which iOS UI element I should choose over some other element he thought I was using. I replied: thanks, but this is an Ionic app, it doesn’t use native iOS elements ;)
Native apps are totally overrated imho, unless you make heavy use of fine-grained input controls. Here, Ionic does have its limits. You can’t control the keyboard properly for example, unless you wire in some Cordova plugins.
Oh and JS doesn’t run in the background. This can cause issues if you do a lot of background processing.
But performance is not much of an issue anymore in 2018 and Ionic is the most polished web-based framework that is tough to distinguish from native apps.
(Ionic CEO here) Thanks for the response and sharing your experience. I also have not heard any feedback that iOS users find Ionic's iOS styles jarring. Ionic is also meant to be customized and branded quite a bit, so stock native style isn't really what we're after anyways.
A priority for us in 2019 is making keyboard and background processing easier!
A priority for us in 2019 is making keyboard and background processing easier!
I phrased that poorly. I personally liked the look of Ionic. I read Medium post after Medium post while researching telling me I'm crazy to use Ionic since iOS people pay for apps and demand native appearance.
Interesting, well considering even a side menu isn’t official Apple UI that might be a case of native engineers projecting their own opinions on developers. Hard to say
Interesting. I haven’t written more than 5 lines of custom CSS. Besides changing the primary color, it’s all Ionic stock styles.
Just curious, what app is this? I’ve generally been of the opinion that it’s very hard to make native-looking Ionic apps.
Most apps are 90% table views, buttons, lists, images, nav controller transitions or modal slideups. Since Ionic gets all of these pretty much right, every Ionic app that makes heavy use of these components will look like a native app.
I won’t post my app here, since this leads to opinionated discussions that serve no purpose. You will always find something that looks off (but you can find off-looking things also in pure native apps).
So to turn the question back to you: what bothers you and what makes it hard to have native-looking apps?
I won’t post my app here, since this leads to opinionated discussions that serve no purpose. You will always find something that looks off (but you can find off-looking things also in pure native apps).
So to turn the question back to you: what bothers you and what makes it hard to have native-looking apps?
> Most apps are 90% table views, buttons, lists, images, nav controller transitions or modal slideups. Since Ionic gets all of these pretty much right, every Ionic app that makes heavy use of these components will look like a native app.
I took a look at this again today, using a demo I found online: http://ionic-team.github.io/ionic-conference-app/www/, which I converted to a web app by adding it to my homescreen. Please let me know if this isn't representative of the current state of Ionic development. Here's just a few of the things that seemed broken/were wrong:
* I can't scroll to the top by tapping the top of the screen.
* The appearance and behavior of the search bar is incorrect.
* The size of the segmented control in the navigation bar is incorrect.
* Scrolling the menu frequently breaks completely–as in, I can't scroll at all. This also happens in the "Filter sessions" page.
* Swiping on switches doesn't match the system behavior: I should not be able to move it until I lift my finger. The animation that changes the switches from "wide" to "circular" isn't correct either.
* I broke the scrollbar insets on the support page.
* I can scroll the navigation bar out of the viewport.
* The background color for pickers is wrong.
* The location from where a backwards swipe can begin is wrong.
* The touch target on bar buttons is too small.
* There is no vibrancy at all.
And from a stylistic point of view:
* Floating action buttons are for Android, not iOS.
* Hamburger menus that duplicate the function of the tab bar are frowned upon.
* Table view selection isn't correct–it deselects itself too quickly.
* Buttons should be render before the view loads, not after.
I took a look at this again today, using a demo I found online: http://ionic-team.github.io/ionic-conference-app/www/, which I converted to a web app by adding it to my homescreen. Please let me know if this isn't representative of the current state of Ionic development. Here's just a few of the things that seemed broken/were wrong:
* I can't scroll to the top by tapping the top of the screen.
* The appearance and behavior of the search bar is incorrect.
* The size of the segmented control in the navigation bar is incorrect.
* Scrolling the menu frequently breaks completely–as in, I can't scroll at all. This also happens in the "Filter sessions" page.
* Swiping on switches doesn't match the system behavior: I should not be able to move it until I lift my finger. The animation that changes the switches from "wide" to "circular" isn't correct either.
* I broke the scrollbar insets on the support page.
* I can scroll the navigation bar out of the viewport.
* The background color for pickers is wrong.
* The location from where a backwards swipe can begin is wrong.
* The touch target on bar buttons is too small.
* There is no vibrancy at all.
And from a stylistic point of view:
* Floating action buttons are for Android, not iOS.
* Hamburger menus that duplicate the function of the tab bar are frowned upon.
* Table view selection isn't correct–it deselects itself too quickly.
* Buttons should be render before the view loads, not after.
Thanks for taking the time to analyze the conference app. In contrast to my sibling poster, I actually think the Ionic demo conference app is what you get if you use Ionic. Sure, some stuff you can achieve with plugins (such as vibrancy), but overall, this is the styling you get if you start to develop an Ionic app now. IMHO, the point of Ionic is that you get a good UI toolkit built with web-technologies that don't require further customization.
However: I'm sure you're right with all of the things you listed. If you go back to the original question, it was: "Do normal people notice?" And my point is still: Normal people won't notice. You listed small details, half of them I don't even notice (search bar, scroll to top, switches, size of segment control, background color of a picker). For some things, you surely have a point and if your users insist on the last 5% of polish for that stuff, go ahead, do everything natively.
But if you see the conference app, the list views, the switches, the segment buttons and say: Well, it might not be at 100%, but surely at 90-95%, and this is good enough for me and my users, then I'd urge anyone to check out Ionic. Because going native obviously comes with a huge cost and the benefits of a Cordova-based app might outweight these details. Obviously, this again boils down to the fruitless discussion of "does dev experience matter or should only the user experience matter". This, you can only answer yourself.
I'm a solo-dev running a business and I can clearly answer this question with: Dev experience matters to me and my users don't give a shit about these kind of details, at least not enough to NOT use my app. I can even say: I have enough users. If some don't use my app because of small UI details, so be it.
However: I'm sure you're right with all of the things you listed. If you go back to the original question, it was: "Do normal people notice?" And my point is still: Normal people won't notice. You listed small details, half of them I don't even notice (search bar, scroll to top, switches, size of segment control, background color of a picker). For some things, you surely have a point and if your users insist on the last 5% of polish for that stuff, go ahead, do everything natively.
But if you see the conference app, the list views, the switches, the segment buttons and say: Well, it might not be at 100%, but surely at 90-95%, and this is good enough for me and my users, then I'd urge anyone to check out Ionic. Because going native obviously comes with a huge cost and the benefits of a Cordova-based app might outweight these details. Obviously, this again boils down to the fruitless discussion of "does dev experience matter or should only the user experience matter". This, you can only answer yourself.
I'm a solo-dev running a business and I can clearly answer this question with: Dev experience matters to me and my users don't give a shit about these kind of details, at least not enough to NOT use my app. I can even say: I have enough users. If some don't use my app because of small UI details, so be it.
That is a demo app that is not representative of what you can do with Ionic. As the README on Github says "This is purely a demo of Ionic with TypeScript. It is still in development."
Maybe you should/could report these at https://github.com/ionic-team/ionic-conference-app/issues...
Maybe you should/could report these at https://github.com/ionic-team/ionic-conference-app/issues...
My experience has been that they do care, but not in the way you’d think: they will voice their concerns as the app breaking something they expected to work, it being slow or laggy, or “not looking right”. They don’t know what’s going in the background but they can usually figure out the effects that it has on their experience.
Is this really your experience or are you stating what other devs say what their experience is? Because slow and laggy are no issues, especially on iOS with insane JS performance. "Not looking right“ – I have never had a single email or review saying this.
Normal people care about the tasks they can complete with your app and maybe missing features, but not small UI details.
And furthermore: even small details that aren’t perfectly polished aren’t necessarily a deal breaker. But of course, it depends whether or not your app is exchangeable and lots of competitors offer a similar experience or not (where polish maybe matters more).
I had great success by having my app generally different from the others. But I have to admit that it’s a niche app and not for the mass market.
Normal people care about the tasks they can complete with your app and maybe missing features, but not small UI details.
And furthermore: even small details that aren’t perfectly polished aren’t necessarily a deal breaker. But of course, it depends whether or not your app is exchangeable and lots of competitors offer a similar experience or not (where polish maybe matters more).
I had great success by having my app generally different from the others. But I have to admit that it’s a niche app and not for the mass market.
> Is this really your experience or are you stating what other devs say what their experience is?
Both.
> Because slow and laggy are no issues, especially on iOS with insane JS performance.
Not every iOS device can say this. And there are certain things that a webview just cannot do performantly, no matter how fast JavaScriptCore is.
> "Not looking right“ – I have never had a single email or review saying this.
People will not generally voice this to you, especially since they may not know what about the app looks wrong to them. But they might be put off from using it, or at least dislike it, without telling you.
> Normal people care about the tasks they can complete with your app and maybe missing features, but not small UI details.
I really believe that both things are important, especially since small UI details might sometimes be things that are important to them. Take accessibility support, for example, or inclusion of keyboard shortcuts.
> And furthermore: even small details that aren’t perfectly polished aren’t necessarily a deal breaker. But of course, it depends whether or not your app is exchangeable and lots of competitors offer a similar experience or not (where polish maybe matters more).
This is true, obviously, but in my experience, at least on iOS, polish is very important. Apollo, the Reddit app, is a good example: it's has found a niche where people use it over competitors because it's more polished (it's not enough for me, but I'm especially picky.)
Both.
> Because slow and laggy are no issues, especially on iOS with insane JS performance.
Not every iOS device can say this. And there are certain things that a webview just cannot do performantly, no matter how fast JavaScriptCore is.
> "Not looking right“ – I have never had a single email or review saying this.
People will not generally voice this to you, especially since they may not know what about the app looks wrong to them. But they might be put off from using it, or at least dislike it, without telling you.
> Normal people care about the tasks they can complete with your app and maybe missing features, but not small UI details.
I really believe that both things are important, especially since small UI details might sometimes be things that are important to them. Take accessibility support, for example, or inclusion of keyboard shortcuts.
> And furthermore: even small details that aren’t perfectly polished aren’t necessarily a deal breaker. But of course, it depends whether or not your app is exchangeable and lots of competitors offer a similar experience or not (where polish maybe matters more).
This is true, obviously, but in my experience, at least on iOS, polish is very important. Apollo, the Reddit app, is a good example: it's has found a niche where people use it over competitors because it's more polished (it's not enough for me, but I'm especially picky.)
Accessibility support: True, you're right.
> Apollo, the Reddit app, is a good example: it's has found a niche where people use it over competitors because it's more polished
I'd say this is actually a bad example. Because apparently, Apollo distinguishes itself from the official Reddit app, because it is more polished. So being polished is the sole differentiator. My point is: If your product is unique in some way that doesn't rely on polish, nobody gives a shit.
Sure, your app might be a bit better if it was native, but implementing everything natively comes with a huge cost. I, as a solo developer, can't support 3 platforms (Android, iOS, web). So Ionic or Cordova-based apps are golden.
> People will not generally voice this to you, especially since they may not know what about the app looks wrong to them. But they might be put off from using it, or at least dislike it, without telling you.
Yes, they might not tell me, they might just ditch the app. But there are thousands of reasons why people ditch apps and I'd argue that polish is the least important of them. The most important is whether people or not understand the workflow, whether or not it matches how they thing about the tasks they want to complete.
You make it sound as if native was always superior to web-based apps. Let me give you a counter example:
My app is not native, but it works completely offline and focuses on "expert" users in my niche. A competitor is truly native, but it doesn't work offline. It saves all data to the cloud and has noticeable lag when an item is saved. This app, despite being native, is "less polished" than my app, because of this noticeable lag.
What I'm saying is: If any small dev team or solo dev tries to weight the tradeoffs between native and hybrid/web-based (and I thought about these things for a long time, way too long actually, before I settled on Ionic): Just go with hybrid, because polishing an app is way more than native UI controls and native UI controls might actually be the least important one.
> Apollo, the Reddit app, is a good example: it's has found a niche where people use it over competitors because it's more polished
I'd say this is actually a bad example. Because apparently, Apollo distinguishes itself from the official Reddit app, because it is more polished. So being polished is the sole differentiator. My point is: If your product is unique in some way that doesn't rely on polish, nobody gives a shit.
Sure, your app might be a bit better if it was native, but implementing everything natively comes with a huge cost. I, as a solo developer, can't support 3 platforms (Android, iOS, web). So Ionic or Cordova-based apps are golden.
> People will not generally voice this to you, especially since they may not know what about the app looks wrong to them. But they might be put off from using it, or at least dislike it, without telling you.
Yes, they might not tell me, they might just ditch the app. But there are thousands of reasons why people ditch apps and I'd argue that polish is the least important of them. The most important is whether people or not understand the workflow, whether or not it matches how they thing about the tasks they want to complete.
You make it sound as if native was always superior to web-based apps. Let me give you a counter example:
My app is not native, but it works completely offline and focuses on "expert" users in my niche. A competitor is truly native, but it doesn't work offline. It saves all data to the cloud and has noticeable lag when an item is saved. This app, despite being native, is "less polished" than my app, because of this noticeable lag.
What I'm saying is: If any small dev team or solo dev tries to weight the tradeoffs between native and hybrid/web-based (and I thought about these things for a long time, way too long actually, before I settled on Ionic): Just go with hybrid, because polishing an app is way more than native UI controls and native UI controls might actually be the least important one.
On the other hand, stepping outside the bounds of the framework becomes much more difficult, so it's a double edged sword. But I'm a simple type, I like Bootstrap just fine - Flutter does things well enough for the most part.