17 ms·

Flutter: the good, the bad and the ugly

307 points by marcobellinaso 8y ago

faitswulff 8y ago
I think the biggest benefit of Flutter, speaking as a developer, is that the design choices have been abstracted away. It feels like SquareSpace or Lego for mobile app design. I compose the component hierarchy and then the app looks, for the most part, like I want it. In contrast to React Native, where there are a lot more fiddly bits and CSS that I'm not interested in. 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.
- nv-vn 8y ago
  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.
d0100 8y ago
If Flutter was js + jsx I'd jump right in.
- marcobellinaso 8y ago
  Funny...one of the reasons I like it (and prefer it over RN) is that it doesn't use JS :)
- nv-vn 8y ago
  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.
- Hixie 8y ago
  We started with JavaScript actually. We switched away from JavaScript because it was too quirky, among other things.
finchisko 8y ago
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 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.
- pier25 8y ago
  > 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).
  - finchisko 8y ago
    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.
  - kyrra 8y ago
    There is also angular dart. https://webdev.dartlang.org/angular https://webdev.dartlang.org/angular
- HappySweeney 8y ago
  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.
  - 8y ago
GenericsMotors 8y ago
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.
- eeZah7Ux 8y ago
  Tell that to the Go crowd :(
  - GenericsMotors 8y ago
    Fair enough, though Go would probably be dead if it suffered the same churn as Google's frontend projects.
  - bsaul 8y ago
    I’m not sure i understand your comment : do you think go is going to be cut off by google anytime soon ??
    - eeZah7Ux 8y ago
      "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.
pier25 8y ago
Flutter has a lot of potential. If Google also officially supported macOS and Windows (even without the native components) it would be amazing.
- MarkMc 8y ago
  I'm working on just such a project: https://feather-apps.com/ https://feather-apps.com/ (although it's not officially supported by Google)
  - MartianSquirrel 8y ago
    Is this Open-sourced? looking at the website it doesn't seem like it
    - MarkMc 8y ago
      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 https://github.com/google/flutter-desktop-embedding
      - sunsetMurk 8y ago
        do you plan on open sourcing? what are your plans?
        MarkMc 8y ago
        No, it's a commercial product. At some point we will charge a fee to publish apps on our platform.
      - pier25 8y ago
        So how are you going to monetize this?
  - pier25 8y ago
    I know! How is that going btw?
bad_user 8y ago
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.
- mikewhy 8y ago
  It's the experience of reading comments that does it for me. It's just so poor.
- eat_veggies 8y ago
  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.
- SkyMarshal 8y ago
  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.
  - bad_user 8y ago
    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.
talkingtab 8y ago
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/ https://gcemetery.co/
- weavie 8y ago
  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..
  - preommr 8y ago
    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.
- marcobellinaso 8y ago
  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.
  - brianpgordon 8y ago
    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 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...
    - skybrian 8y ago
      Flaws in the type system just aren't that important to most people. Consider the popularity of Typescript, which is unsound.
mark_l_watson 8y ago
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.
- mark_l_watson 8y ago
  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.
  - hasbot 8y ago
    Creating desktop apps with Flutter is possible: https://medium.com/flutter-community/flutter-from-mobile-to-desktop-93635e8de64e https://medium.com/flutter-community/flutter-from-mobile-to-...
  - cmrdporcupine 8y ago
    The Flutter engine has an embedding API that is intended for this purpose: https://github.com/flutter/engine/tree/master/shell/platform/embedder https://github.com/flutter/engine/tree/master/shell/platform...
  - garyclarke27 8y ago
    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 8y ago
      [deleted]
matchbok 8y ago
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.
- matt2000 8y ago
  Flutter doesn't use javascript.
  - HappySweeney 8y ago
    Nor do you need any libraries for navigation.
- hasbot 8y ago
  An organization wants their app to run on both mobile platforms. That's not a limited use case.
- aaaaaaaaaab 8y ago
  True. Yet managers love them because these tools promise the ultimate pipe dream: uniform, interchangeable engineers.
- k__ 8y ago
  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?
rhardih 8y ago
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.
- hasbot 8y ago
  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.
  - rhardih 8y ago
    Yeah I know about https://flutter.io/docs/development/platform-integration/platform-channels 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 https://pub.dartlang.org/packages/camera
    - hasbot 8y ago
      > But, that's almost the same as not having support at all. Please explain your logic here.
      - rhardih 8y ago
        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.
supergilbert 8y ago
Still waiting for Kotlin to be the 1-stop shop for app development.
deleted 8y ago
[deleted]
misiti3780 8y ago
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.
- jchw 8y ago
  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.
- gilfoyle 8y ago
  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.
- Apocryphon 8y ago
  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.
bonsai80 8y ago
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)?
- judge2020 8y ago
  Flutter is compiled to native ARM code, and as such doesn't allow this functionality. This exact limitation is mentioned in the article.
convery 8y ago
Any idea about how well Flutter would integrate with C/C++? As in, using Flutter for the UI and having callbacks to C++.
- pjmlp 8y ago
  Flutter is built on top of Skia, so there is some kind of integration there.
resters 8y ago
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.
- ryanwaggoner 8y ago
  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.
  - coldtea 8y ago
    >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.
    - eksemplar 8y ago
      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.
      - coldtea 8y ago
        We just know that they changed toolkits. Not whether they did it to adopt a better one, out of some new fad, with valid reasons, etc...
virmundi 8y ago
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?
- WA 8y ago
  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.
  - yesimahuman 8y ago
    (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!
    - virmundi 8y ago
      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.
ken 8y ago
> 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.
- xxgreg 8y ago
  "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.
  - pjmlp 8y ago
    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.
    - ilrwbwrkhv 8y ago
saurik 8y ago
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/12920 https://github.com/flutter/flutter/issues/9507 https://github.com/flutter/flutter/issues/9507 https://github.com/flutter/flutter/issues/20693 https://github.com/flutter/flutter/issues/20693 https://github.com/flutter/flutter/issues/24575 https://github.com/flutter/flutter/issues/24575 https://github.com/flutter/flutter/issues/24574 https://github.com/flutter/flutter/issues/24574 https://github.com/flutter/flutter/issues/18391 https://github.com/flutter/flutter/issues/18391 https://github.com/flutter/flutter/issues/1668 https://github.com/flutter/flutter/issues/1668 https://github.com/flutter/flutter/issues/14543 https://github.com/flutter/flutter/issues/14543 https://github.com/flutter/flutter/issues/4830 https://github.com/flutter/flutter/issues/4830 https://github.com/flutter/flutter/issues/4827 https://github.com/flutter/flutter/issues/4827 https://github.com/flutter/flutter/issues/4826 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 https://github.com/flutter/flutter/issues/6827 (opened Nov 2016) https://github.com/flutter/engine/pull/4358 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/15479 https://github.com/flutter/flutter/issues/15478 https://github.com/flutter/flutter/issues/15478 https://github.com/flutter/flutter/issues/15476 https://github.com/flutter/flutter/issues/15476 https://github.com/flutter/flutter/issues/21102 https://github.com/flutter/flutter/issues/21102 https://github.com/flutter/flutter/issues/18059 https://github.com/flutter/flutter/issues/18059 https://github.com/flutter/flutter/issues/17186 https://github.com/flutter/flutter/issues/17186 https://github.com/flutter/flutter/issues/17165 https://github.com/flutter/flutter/issues/17165 https://github.com/flutter/flutter/issues/18700 https://github.com/flutter/flutter/issues/18700 https://github.com/flutter/flutter/issues/17950 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).
alexhayes 8y ago
> 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.
alexhayes 8y ago
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!
pcwalton 8y ago
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.
- rofrol 8y ago
  comment in wrong place?
  - PaulBGD_ 8y ago
    No, the article mentions that Skia is used in multiple web browsers. > 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).
jillesvangurp 8y ago
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.
- Apocryphon 8y ago
  Technical reasoning for Dart: https://hackernoon.com/why-flutter-uses-dart-dd635a054ebf https://hackernoon.com/why-flutter-uses-dart-dd635a054ebf https://flutter.io/docs/resources/faq#why-did-flutter-choose-to-use-dart 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.
- ptx 8y ago
  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.html https://kotlinlang.org/docs/reference/type-safe-builders.htm... [2] https://flutter.io/docs/development/ui/layout#step-2-implement-the-title-row https://flutter.io/docs/development/ui/layout#step-2-impleme...
hardwaresofton 8y ago
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 https://docs.nativescript.org [1]: https://nativescript-vue.org/ https://nativescript-vue.org/
paul_h 8y ago
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.
- Hixie 8y ago
  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.

I think the biggest benefit of Flutter, speaking as a developer, is that the design choices have been abstracted away. It feels like SquareSpace or Lego for mobile app design. I compose the component hierarchy and then the app looks, for the most part, like I want it. In contrast to React Native, where there are a lot more fiddly bits and CSS that I'm not interested in. 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.

nv-vn 8y ago
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.

d0100 8y ago

If Flutter was js + jsx I'd jump right in.

marcobellinaso 8y ago
Funny...one of the reasons I like it (and prefer it over RN) is that it doesn't use JS :)
nv-vn 8y ago
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.
Hixie 8y ago
We started with JavaScript actually. We switched away from JavaScript because it was too quirky, among other things.

finchisko 8y ago

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 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.

pier25 8y ago
> 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).
- finchisko 8y ago
  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.
- kyrra 8y ago
  There is also angular dart. https://webdev.dartlang.org/angular https://webdev.dartlang.org/angular
HappySweeney 8y ago
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.
- 8y ago

GenericsMotors 8y ago

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.

eeZah7Ux 8y ago
Tell that to the Go crowd :(
- GenericsMotors 8y ago
  Fair enough, though Go would probably be dead if it suffered the same churn as Google's frontend projects.
- bsaul 8y ago
  I’m not sure i understand your comment : do you think go is going to be cut off by google anytime soon ??
  - eeZah7Ux 8y ago
    "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.

pier25 8y ago

Flutter has a lot of potential. If Google also officially supported macOS and Windows (even without the native components) it would be amazing.

MarkMc 8y ago
I'm working on just such a project: https://feather-apps.com/ https://feather-apps.com/ (although it's not officially supported by Google)
- MartianSquirrel 8y ago
  Is this Open-sourced? looking at the website it doesn't seem like it
  - MarkMc 8y ago
    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 https://github.com/google/flutter-desktop-embedding
    - sunsetMurk 8y ago
      do you plan on open sourcing? what are your plans?
      - MarkMc 8y ago
        No, it's a commercial product. At some point we will charge a fee to publish apps on our platform.
    - pier25 8y ago
      So how are you going to monetize this?
- pier25 8y ago
  I know! How is that going btw?

bad_user 8y ago

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.

mikewhy 8y ago
It's the experience of reading comments that does it for me. It's just so poor.
eat_veggies 8y ago
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.
SkyMarshal 8y ago
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.
- bad_user 8y ago
  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.

talkingtab 8y ago

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/ https://gcemetery.co/

weavie 8y ago
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..
- preommr 8y ago
  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.
marcobellinaso 8y ago
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.
- brianpgordon 8y ago
  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 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...
  - skybrian 8y ago
    Flaws in the type system just aren't that important to most people. Consider the popularity of Typescript, which is unsound.

mark_l_watson 8y ago

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.

mark_l_watson 8y ago
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.
- hasbot 8y ago
  Creating desktop apps with Flutter is possible: https://medium.com/flutter-community/flutter-from-mobile-to-desktop-93635e8de64e https://medium.com/flutter-community/flutter-from-mobile-to-...
- cmrdporcupine 8y ago
  The Flutter engine has an embedding API that is intended for this purpose: https://github.com/flutter/engine/tree/master/shell/platform/embedder https://github.com/flutter/engine/tree/master/shell/platform...
- garyclarke27 8y ago
  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 8y ago
    [deleted]

matchbok 8y ago

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.

matt2000 8y ago
Flutter doesn't use javascript.
- HappySweeney 8y ago
  Nor do you need any libraries for navigation.
hasbot 8y ago
An organization wants their app to run on both mobile platforms. That's not a limited use case.
aaaaaaaaaab 8y ago
True. Yet managers love them because these tools promise the ultimate pipe dream: uniform, interchangeable engineers.
k__ 8y ago
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?

rhardih 8y ago

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.

hasbot 8y ago
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.
- rhardih 8y ago
  Yeah I know about https://flutter.io/docs/development/platform-integration/platform-channels 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 https://pub.dartlang.org/packages/camera
  - hasbot 8y ago
    > But, that's almost the same as not having support at all. Please explain your logic here.
    - rhardih 8y ago
      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.

supergilbert 8y ago

Still waiting for Kotlin to be the 1-stop shop for app development.

deleted 8y ago

[deleted]

misiti3780 8y ago

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.

jchw 8y ago
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.
gilfoyle 8y ago
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.
Apocryphon 8y ago
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.

bonsai80 8y ago

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)?

judge2020 8y ago
Flutter is compiled to native ARM code, and as such doesn't allow this functionality. This exact limitation is mentioned in the article.

convery 8y ago

Any idea about how well Flutter would integrate with C/C++? As in, using Flutter for the UI and having callbacks to C++.

pjmlp 8y ago
Flutter is built on top of Skia, so there is some kind of integration there.

resters 8y ago

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.

ryanwaggoner 8y ago
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.
- coldtea 8y ago
  >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.
  - eksemplar 8y ago
    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.
    - coldtea 8y ago
      We just know that they changed toolkits. Not whether they did it to adopt a better one, out of some new fad, with valid reasons, etc...

virmundi 8y ago

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?

WA 8y ago
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.
- yesimahuman 8y ago
  (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!
  - virmundi 8y ago
    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.

ken 8y ago

> 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.

xxgreg 8y ago
"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.
- pjmlp 8y ago
  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.
  - ilrwbwrkhv 8y ago

saurik 8y ago

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/12920 https://github.com/flutter/flutter/issues/9507 https://github.com/flutter/flutter/issues/9507 https://github.com/flutter/flutter/issues/20693 https://github.com/flutter/flutter/issues/20693 https://github.com/flutter/flutter/issues/24575 https://github.com/flutter/flutter/issues/24575 https://github.com/flutter/flutter/issues/24574 https://github.com/flutter/flutter/issues/24574 https://github.com/flutter/flutter/issues/18391 https://github.com/flutter/flutter/issues/18391 https://github.com/flutter/flutter/issues/1668 https://github.com/flutter/flutter/issues/1668 https://github.com/flutter/flutter/issues/14543 https://github.com/flutter/flutter/issues/14543 https://github.com/flutter/flutter/issues/4830 https://github.com/flutter/flutter/issues/4830 https://github.com/flutter/flutter/issues/4827 https://github.com/flutter/flutter/issues/4827 https://github.com/flutter/flutter/issues/4826 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 https://github.com/flutter/flutter/issues/6827 (opened Nov 2016) https://github.com/flutter/engine/pull/4358 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/15479 https://github.com/flutter/flutter/issues/15478 https://github.com/flutter/flutter/issues/15478 https://github.com/flutter/flutter/issues/15476 https://github.com/flutter/flutter/issues/15476 https://github.com/flutter/flutter/issues/21102 https://github.com/flutter/flutter/issues/21102 https://github.com/flutter/flutter/issues/18059 https://github.com/flutter/flutter/issues/18059 https://github.com/flutter/flutter/issues/17186 https://github.com/flutter/flutter/issues/17186 https://github.com/flutter/flutter/issues/17165 https://github.com/flutter/flutter/issues/17165 https://github.com/flutter/flutter/issues/18700 https://github.com/flutter/flutter/issues/18700 https://github.com/flutter/flutter/issues/17950 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).

alexhayes 8y ago

> 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.

alexhayes 8y ago

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!

pcwalton 8y ago

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.

rofrol 8y ago
comment in wrong place?
- PaulBGD_ 8y ago
  No, the article mentions that Skia is used in multiple web browsers. > 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).

jillesvangurp 8y ago

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.

Apocryphon 8y ago
Technical reasoning for Dart: https://hackernoon.com/why-flutter-uses-dart-dd635a054ebf https://hackernoon.com/why-flutter-uses-dart-dd635a054ebf https://flutter.io/docs/resources/faq#why-did-flutter-choose-to-use-dart 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.
ptx 8y ago
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.html https://kotlinlang.org/docs/reference/type-safe-builders.htm... [2] https://flutter.io/docs/development/ui/layout#step-2-implement-the-title-row https://flutter.io/docs/development/ui/layout#step-2-impleme...

hardwaresofton 8y ago

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 https://docs.nativescript.org [1]: https://nativescript-vue.org/ https://nativescript-vue.org/

paul_h 8y ago

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.

Hixie 8y ago
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.