3 ms·

Yeah I know about https://flutter.io/docs/development/platform-integration/platform-channels https://flutter.io/docs/development/platform-integration/pla... Bu

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.
  - hasbot 8y ago
    That's a lot of negative assumptions you're making. And, IMHO, still not enough to warrant or in line with saying "that's almost the same as not having support at all."
    - ptx 8y ago
      It is very similar to having no support at all, since any language supports calling any other language by way of manually written bridges and wrappers – so if that's "support" then the set of languages without such support is empty.
coder543 8y ago
> even just getting a camera feed on Flutter isn't a built-in Why should it be built-in? That's such a C++ (or C) mindset: that using dependencies is bad, which stems from the difficulty of adding and updating dependencies in the C++ world. In a language with a rock solid package manager, it's better to have a small core and then pull in what you need. Each of these out-of-core dependencies can have separate lifecycles, which makes it a lot easier for them to be developed and updated, making them higher quality. If breaking changes need to be made, that can easily be done in out-of-core libraries, since existing projects can continue depending on their SemVer-defined compatible version of the dependency ad infinitum, and the project maintainers can continue releasing updates to any SemVer series of the package if they need to backport changes to older versions. When something is in the core, it's very hard to update it while maintaining complete compatibility, and people can only depend on one version of your core library at a time, so there's no room to be flexible. This constricts growth, since the core needs to meet everyone's needs, but it doesn't have the flexibility to do that as the world changes, so it often meets no one's needs. I don't know how good Dart's package manager is, since I haven't really touched Dart since the very earliest days of the language after it became public, but Rust's package manager is excellent, and having most things out-of-std has been great for the community. Futures and async have flourished out-of-std and gone through several very different approaches to gain real world experience. Some very small pieces of that ecosystem will be stabilized into the core language soon, but only the most bare minimum features to add the "await" keyword to the language. As much as possible will still remain in outside libraries. In general, things go to stdlib to die.[0] The main exception I've seen with this over the years is Go, where they have done a really great job of maintaining and extending their huge batteries-included stdlib to the point that most people almost always recommend starting with the stdlib before reaching for a third-party package. [0]: http://www.leancrew.com/all-this/2012/04/where-modules-go-to-die/ http://www.leancrew.com/all-this/2012/04/where-modules-go-to...
- rhardih 8y ago
  Disclaimer, I'm not a C++ guy. I agree that a truly solid package system, is inherently a good thing for any framework. But it has to be just that. Qt is severely lacking in that aspect; qpm isn't even close IMO. Counter to your point though, just take a look at the ecosystem around NPM for instance. What a mess... For a cross platform development framework, to truly shine, I need to be able to "trust", that my majority use case is covered within the framework itself, so I don't have to go package shopping and spend a lot of time on quality controlling vendored code. For a mobile app framework, I want the most ubiquitous device capabilities covered. That means various hardware specific things, such as networking, gps, bluetooth and yes, the camera. Whatever is to be expected present on most devices. So yeah, I guess it boils down to dependability and trust. Something which is implicit in the framework and core library for the most part.
timsneath 8y ago
One thing that's different about Flutter is that we've deliberately focused on keeping the Flutter framework small. We write many of the plug-ins ourselves to the same standard as the core framework, but keeping them separate lets us iterate on them at a different cadence. See https://github.com/flutter/plugins https://github.com/flutter/plugins for our plug-in repository. (Disclosure: I'm a PM on the Flutter team.)
- rhardih 8y ago
  Hey Tim. I can completely understand the reasoning behind it from a project development perspective, I'm just pointing out some of the pitfalls in doing it this way. Obviously I don't know how you've structured responsibilities internally, but what I've seen before is, that the quality of individual components, or plugins if you will, live and die by the interest of the teams and people behind them. Qt has this very same problem, often leading to some bugs ageing unacceptably long, or features never properly maturing, simply because there's little to no inside interest. NPM has a variant of the same problem as well. I'd venture a guess that a large percentage of packages on NPM right now, is downright abandonware. I will be keeping a interested eye out for the developments of Flutter and I'm hopeful you succeed in this space. There's definitely room for it. With regards to the native stuff, I'm mainly coming from a performance perspective on GPGPU and computer vision applications. I think going forward, there's going to be a huge increase in AR/MR apps, that will need easy access to do heavy lifting on metal. Coincidentally, I was lucky enough to catch a quick chat with Michael Thomsen, after his talk at Coldfront recently and he mentioned that, that was indeed on the roadmap. If you guys manage to provide the easiest cross platform way to do Vulkan/Metal or whatever the next-gen iOS and Android HAL is going to be, you're definitely going to come out on top.
  - sebe 8y ago
    Michael Thomsen's Coldfront talk is up on youtube, https://youtu.be/sl5TaN7EwjQ https://youtu.be/sl5TaN7EwjQ
- com2kid 8y ago
  Funny enough it is the lack of native Google Places support that makes Flutter a no go for me. Also not having a JSX like syntax. I went into RN expecting to hate JSX, but I ended up loving it. Doing UI development with nested {} is so hideous in comparison. I am impressed at the quality of UIs Flutter can make, but the code behind them is, IMHO, much harder to read than the RN equivalent.

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.
- hasbot 8y ago
  That's a lot of negative assumptions you're making. And, IMHO, still not enough to warrant or in line with saying "that's almost the same as not having support at all."
  - ptx 8y ago
    It is very similar to having no support at all, since any language supports calling any other language by way of manually written bridges and wrappers – so if that's "support" then the set of languages without such support is empty.

coder543 8y ago

> even just getting a camera feed on Flutter isn't a built-in Why should it be built-in? That's such a C++ (or C) mindset: that using dependencies is bad, which stems from the difficulty of adding and updating dependencies in the C++ world. In a language with a rock solid package manager, it's better to have a small core and then pull in what you need. Each of these out-of-core dependencies can have separate lifecycles, which makes it a lot easier for them to be developed and updated, making them higher quality. If breaking changes need to be made, that can easily be done in out-of-core libraries, since existing projects can continue depending on their SemVer-defined compatible version of the dependency ad infinitum, and the project maintainers can continue releasing updates to any SemVer series of the package if they need to backport changes to older versions. When something is in the core, it's very hard to update it while maintaining complete compatibility, and people can only depend on one version of your core library at a time, so there's no room to be flexible. This constricts growth, since the core needs to meet everyone's needs, but it doesn't have the flexibility to do that as the world changes, so it often meets no one's needs. I don't know how good Dart's package manager is, since I haven't really touched Dart since the very earliest days of the language after it became public, but Rust's package manager is excellent, and having most things out-of-std has been great for the community. Futures and async have flourished out-of-std and gone through several very different approaches to gain real world experience. Some very small pieces of that ecosystem will be stabilized into the core language soon, but only the most bare minimum features to add the "await" keyword to the language. As much as possible will still remain in outside libraries. In general, things go to stdlib to die.[0] The main exception I've seen with this over the years is Go, where they have done a really great job of maintaining and extending their huge batteries-included stdlib to the point that most people almost always recommend starting with the stdlib before reaching for a third-party package. [0]: http://www.leancrew.com/all-this/2012/04/where-modules-go-to-die/ http://www.leancrew.com/all-this/2012/04/where-modules-go-to...

rhardih 8y ago
Disclaimer, I'm not a C++ guy. I agree that a truly solid package system, is inherently a good thing for any framework. But it has to be just that. Qt is severely lacking in that aspect; qpm isn't even close IMO. Counter to your point though, just take a look at the ecosystem around NPM for instance. What a mess... For a cross platform development framework, to truly shine, I need to be able to "trust", that my majority use case is covered within the framework itself, so I don't have to go package shopping and spend a lot of time on quality controlling vendored code. For a mobile app framework, I want the most ubiquitous device capabilities covered. That means various hardware specific things, such as networking, gps, bluetooth and yes, the camera. Whatever is to be expected present on most devices. So yeah, I guess it boils down to dependability and trust. Something which is implicit in the framework and core library for the most part.

timsneath 8y ago

One thing that's different about Flutter is that we've deliberately focused on keeping the Flutter framework small. We write many of the plug-ins ourselves to the same standard as the core framework, but keeping them separate lets us iterate on them at a different cadence. See https://github.com/flutter/plugins https://github.com/flutter/plugins for our plug-in repository. (Disclosure: I'm a PM on the Flutter team.)

rhardih 8y ago
Hey Tim. I can completely understand the reasoning behind it from a project development perspective, I'm just pointing out some of the pitfalls in doing it this way. Obviously I don't know how you've structured responsibilities internally, but what I've seen before is, that the quality of individual components, or plugins if you will, live and die by the interest of the teams and people behind them. Qt has this very same problem, often leading to some bugs ageing unacceptably long, or features never properly maturing, simply because there's little to no inside interest. NPM has a variant of the same problem as well. I'd venture a guess that a large percentage of packages on NPM right now, is downright abandonware. I will be keeping a interested eye out for the developments of Flutter and I'm hopeful you succeed in this space. There's definitely room for it. With regards to the native stuff, I'm mainly coming from a performance perspective on GPGPU and computer vision applications. I think going forward, there's going to be a huge increase in AR/MR apps, that will need easy access to do heavy lifting on metal. Coincidentally, I was lucky enough to catch a quick chat with Michael Thomsen, after his talk at Coldfront recently and he mentioned that, that was indeed on the roadmap. If you guys manage to provide the easiest cross platform way to do Vulkan/Metal or whatever the next-gen iOS and Android HAL is going to be, you're definitely going to come out on top.
- sebe 8y ago
  Michael Thomsen's Coldfront talk is up on youtube, https://youtu.be/sl5TaN7EwjQ https://youtu.be/sl5TaN7EwjQ
com2kid 8y ago
Funny enough it is the lack of native Google Places support that makes Flutter a no go for me. Also not having a JSX like syntax. I went into RN expecting to hate JSX, but I ended up loving it. Doing UI development with nested {} is so hideous in comparison. I am impressed at the quality of UIs Flutter can make, but the code behind them is, IMHO, much harder to read than the RN equivalent.