karimayachi
commented
4 years ago I wasn't really sure if I meant the first or the second. I'm not sure if Google will be as successful in pushing developers to Dart as Apple has been with Swift.
Like, you, I don't believe that it would be practical to write Native mobile applications, at least initially. You're right in that it would require a project akin to React Native. Something that might emerge in the future, but likely be led by a different team with at least one major corporate benefactor behind it. (OTOH, if Dart does win market share, someone will probably want to build a React Native analog at some point.)
So my estimation is that support for PWA is the only really viable option for mobile in the near future.
OTOH, Microsoft makes it possible to add PWA to the Windows Store, and it's possible to run them natively in Win10:
Progressive Web Apps have full access to Windows 10 feature APIs and can be installed across the entire UWP device family (including the more secure Windows 10 in S-mode devices) while still ensuring compatibility across other browsers and devices. PWAs are a natural evolution of Hosted Web Apps, but with standards-based support for offline scenarios, thanks to the Service Workers, Cache, and Push APIs.
Emphasis mine.
I would hope that Fuchsia would take a similar approach, but I don't know for sure. Given that V8 and Blink are also Google, I'd like to believe that they could optimize performance for a webview based approach. (Plus, native Fuchsia is 120fps, so hopefully much greater degradation is required before jank emerges.)
Apple is having to be dragged along kicking and screaming with the whole PWA push; but, they aren't powerful enough to thwart it--just to slow it down. If they are too slow, it will cost them market share.
So I feel like the short term solution is to try to write highly modular code, initially basically a parallel implementation of Knockdown in Dart, that could be built up into a React-like juggernaut if Dart does become the new Typescript. It would potentially have a "first mover" advantage over any attempt by the React community to follow suit. (Plus, that community seems to have already gone to TS?) But I won't be able to prioritize this, and might not even make it public. Just sort of keep it lurking as a strategic contingency.
Still, reading your email, I'm not sure how successful I believe Google will be in consolidating its community into Dart. The reason Electron, Phonegap, etc. got some traction was because it made it possible to take familiar technologies and expand their reach. "Learn this new, proprietary approach to development to write once; deploy everywhere" is a very different proposition.
Although, there are two strategic considerations:
- Becoming a thought leader in Dart-lang would probably [be very cool] [edit: karim]
- If Google wants to highlight the fact that third party frameworks exist in Dart (and they will), it could amount to millions worth of free marketing. It may be possible to benefit from their largesse indirectly. But that won't matter if no one is programming in Dart... ;) [edit: karim]
I've given your email about Google and Dart a lot of thought. First I have to admit I might have misinterpreted your message. I wasn't sure if you meant that Dart could be the underlying technique for the SoC/Composition library we have been discussing, or that you meant that you contemplated porting Knockdown to Dart, unrelated to our discussion of SoC/WC.
I assumed the first, but later started thinking you might have meant the latter. In case you did mean the latter: Go for it! Would be cool to have a binding library for Dart probably.
But for this email I'm going to assume that you meant the first: that Dart could be the basis for the thing we have been discussing. When thinking about this I went through all the emotions: Sceptical, Excited, Overwhelmed, Reluctant (maybe I could coin the acronym SEOR :-) )
I've tried to envision what it would mean to have a SoC/Composition library for Dart, to complement Flutter and AngularDart. And I couldn't...
The main problem here is that Dart doesn't have an internal declarative markup language in the way that WPF has XAML, the web has HTML, iOS has .nib layouts, etc.
So in order to do (MVVM-)bindings you would have to create your own View-system from scratch. Both the markup and the renderer. That would be an enormous task.
Sure, there are html libraries for Dart that can interpret HTML. But in order to use HTML as a view, you would either have to use it on the web (Dart Web, that basically just compiles Dart to JavaScript) or encapsulate a web view (chromium, or whatever) and thus losing the promise of native performance (remember PhoneGap, etc).
I believe in light of the above and what I've read that AngularDart can only be used on the web. I don't think it can be used natively in Android, iOS or Fuchsia. (and if it can, it will probably encapsulate a web view).
I believe AngularDart just pushes the "Dart (Google) over TypeScript (Microsoft)"-agenda of Google. But both AngularDart and AngularTS transpile to JavaScript and offer no real advantage over the other. (I think TypeScript will even be more performant, because it ís already practically JavaScript, especially with ES6 browsers).
Flutter does have native support, but it doesn't rely on a markup language. Instead it wraps the Skia engine and comes with a predefined UI library.
To have a SoC/Composition library in Dart Native we would have to have a markup language, a renderer for that language and readily available UI libraries for that language / Dart. All those don't exist...
What may be possible is imo:
Let me know what you think! Regards, Karim
Ps. some other considerations:
From the Fuchsia website: "Fuchsia's goal is to power production devices and products used for business-critical applications." Doesn't sound like UI driven apps to me...
Brrrrrrrrrrr: https://pub.dev/packages/dartins