Hacker News Reader

Comment by rhardih | Hacker News Reader

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.

View on HN

I think I can more or less say that we would not have been able to build what we have without RN. At least not with same budget. There is a large class of apps that would suck @ in a webview but can get by just fine in RN with 90% cross-platform code re-use. If you're already a team of experienced react developers the learning curve mostly just comes down to learning how to resolve build issues. And possibly expo can take care of that depending on your app. (anyone actually use expo for real stuff?)

With RN + React Web + [PaaS/FaaS] I feel like a lone dev can be dangerous theses days.

Doesn't mean Flutter or PWA's won't obsolete it eventually, and I'm optimistic about Flutter's approach. Just saying that there's a reason RN is a thing.

Could you elaborate what is the sweet spot for RN, when webview is not enough?

I think webview is rarely enough. If you already have React experience then building React Native is only marginally more difficult than a web app but the UX is much better.

I also don't believe in RN and for me Flutter is the last hope of keeping Dart relevant outside the Googleplex.

I don't see any reason to waste my time with Dart. It was a good decision to focus on JavaScript back then, and it is more so in the context of native apps.

Regarding Qt, when I tried it about 4 years ago, I was quite disappointed with their mobile support, because they only had the bare minimum, and integrating the platform APIs meant in the end the effort was bigger than just doing C++ plus native views.

Meanwhile they seem to have switched focus to customers that are actually willing to pay for their tooling, thus hardware manufactures selling medical, IoT and automobile devices, as one can easily see from the upcoming Qt World Summit schedule.

At personal level I have been using the former approach of C++ plus native views, while at work our mobile projects have been either Ionic based or plain mobile web sites.

Still weighting to switch back to Qt or adopt Xamarin for hobby projects, although with Google and Microsoft pulling their weight behind PWAs, I am starting to think that might be the future for all mobile apps that aren't performance critical, given WebAssembly and access to device APIs without additional FFI when authenticated.

How was your mobile Qt experience been?

WebAssembly on-device might be a game changer for performance critical apps. I'll happily welcome it when I see it, but I'm not holding my breath.

The thing is that most things coming from Web just moves faster, and there's so many more resources available for the 95% app. For all of that JS kinda makes sense. It just comes with a bad upbringing and poor manners, when seen through the glasses of considering a phone as an "embedded" device with resource restrictions. Performance is always seems an afterthought in most things web. And that's understandable, because even the baseline resource usage, as fast and small as you can get on a Javascript runtime, is still above what I'd consider acceptable. It just isn't for most apps out there and people have sort of gotten used to charging their phones mid-way through the day.

Qt definitely isn't perfect, and it can be a bit of a pain to work with. QtCreator is just... and there's no live reloading.

The good thing is that runs really fast on the machine you're already working on, so most of the time you just work on the Desktop windowed version anyway.

I wish there's was a bigger selection of UI frameworks available though. For mobile there's Qt Quick Controls 2, which is quite good, but not at all as expansive as what you have available on the web for instance.

I do think though, that if Qt doesn't do something about their tooling and ecosystem, that they'll get run into the ground when some of these other frameworks bridges the gap to some of the features that Qt is still unique in having.

Reactjs Architecture is very suited for mobile development. After all it's a view centric one. RN problem I assume same for Flutter is the bridge accessing native apis.

When I say architecture, I mean running a full web-runtime as your core application layer. That is a fundamentally broken paradigm in my opinion. That's also the difference between RN and Flutter.

Flutter allows the use of plugins which, through glue code, allow using native code and existing libraries. It's pretty comparable functionally to Java's JNI.

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

But, that's almost the same as not having support at all. JNI isn't really a poster-child of usability.

With Qt, since you're already on the right side of the fence, it's just a matter of "#include "whatever.h" and linking it at compile time.

I mean, even just getting a camera feed on Flutter isn't a built-in: https://pub.dartlang.org/packages/camera

> But, that's almost the same as not having support at all.

Please explain your logic here.

When the mental burden of integrating existing libraries, through tons of wrapping/boilerplating, such as it is with JNI, starts to overshadow rebuilding the same thing, at your current application layer, it's close to a zero value proposition.

That's a lot of negative assumptions you're making. And, IMHO, still not enough to warrant or in line with saying "that's almost the same as not having support at all."

It is very similar to having no support at all, since any language supports calling any other language by way of manually written bridges and wrappers – so if that's "support" then the set of languages without such support is empty.

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

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.

In this case, the camera package they linked to is being developed by the Flutter team, so... the quality controls are surely in line with the core library. Having it outside the core offers a number of benefits, as I mentioned.

You're right. I didn't actually know that was the case. That makes inclusion in a project a much easier decision.

Tim Sneath linked to the official plugins list in another comment, https://github.com/flutter/plugins, and both camera, sensors and connectivity, would be akin to the kind of ownership I'd expect. It's definitely a good start.

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

(Disclosure: I'm a PM on the Flutter team.)

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.

Michael Thomsen's Coldfront talk is up on youtube,

https://youtu.be/sl5TaN7EwjQ

Funny enough it is the lack of native Google Places support that makes Flutter a no go for me.

Also not having a JSX like syntax. I went into RN expecting to hate JSX, but I ended up loving it.

Doing UI development with nested {} is so hideous in comparison. I am impressed at the quality of UIs Flutter can make, but the code behind them is, IMHO, much harder to read than the RN equivalent.

Reply on news.ycombinator.com