Flutter: the good, the bad and the ugly
medium.com
medium.com
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.
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.
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.
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.
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.
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.
No offense to the Discord iOS developers, but their apps is neither “high performance” nor impressive. It’s outright janky at times.
The Android version suffers the same but moreso.
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.
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.
> 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.
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.
Cool reading your other comments too I realise I’m getting trolled at this point so I’ll finish up here.
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.
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.
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? :)
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.
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.
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.
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 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.
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.
i actually prefer a java like language than learn prefix calls and conj
What it gets promoted as Dart special features for Flutter is also available in other languages, not only Lisp.
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.)
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.
So which languages/platforms do you mean?
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.
Cool watching Fuchsia evolve. It will definitely support Android apps, otherwise google throws away their playstore monopoly.
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.
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.
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.
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.
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.
As for why Flutter uses Dart, this is the canonical answer: https://hackernoon.com/why-flutter-uses-dart-dd635a054ebf
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.
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).
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.
https://softwareengineeringdaily.com/2018/07/11/flutter-in-p...
You can also skim the transcript (pgs. 3-6) Transcript here:
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.
> 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.
https://github.com/flutter/engine/tree/master/shell/platform...
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.
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
Please explain your logic here.
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...
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.
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.
(Disclosure: I'm a PM on the Flutter team.)
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.
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.
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.
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?
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.
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.
You can certainly use Dart in the server, and even compiled to JavaScript in the browser (which I believe was its initial purpose).
Flutter has a superior developer experience in my opinion.
Dart was a breeze to pick up.
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...
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.
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.
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.
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...
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).
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.
This, in particular, even with Google-level attention and resources, seems like a design dead end, at least for third party apps.
Also, this should really be a top comment.
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
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.
> through a fast C++ 2D graphics library called Skia (which also serves as the graphics engine for Google Chrome, Chrome OS, Android, Mozilla Firefox and Firefox OS, and many other products).
(although it's not officially supported by Google)
How is that going btw?
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...
Why are covariant generics bad? (also just a link is fine)
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
}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.
Fortunately for me UI dev isn't my primary role.
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.
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...
"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.
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.
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.
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?
- 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.
- 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.
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 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.
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...
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.
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?
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.
A priority for us in 2019 is making keyboard and background processing easier!
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 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.
Maybe you should/could report these at https://github.com/ionic-team/ionic-conference-app/issues...
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.
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.
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.)
> 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.