How advanced is the typing system, are we talking Java level or significantly more powerful?
As an engineer that's written a lot of (old-skool) JS, Java, Obj-C, C++, and PHP, it is a real pleasure to develop web frontends with Dart.
Immutable Data Structures: Not out-of-the-box but we use the BuiltValue[0]/BuiltCollection[1] libraries extensively internally Functional Programming: Dart's Iterable[2] and Stream[3] classes have all the standard higher-order functions, like map, filter/where, reduce, fold, etc. Type System: With Dart 2.0[4], the type system is really great. Expressive with good type-inference, support for generic types, mixins, & typedefs. It's actually better than Java, IMO.
Also, the async story is fantastic! JS has caught up with Dart in some areas recently but Futures, Streams, async/await, & async*/yield, have long been first-class members of the Dart language.[5]
[0]: https://github.com/google/built_value.dart [1]: https://github.com/google/built_collection.dart [2]: https://api.dartlang.org/stable/2.7.0/dart-core/Iterable-cla... [3]: https://api.dartlang.org/stable/2.7.0/dart-async/Stream-clas... [4]: https://dart.dev/dart-2 [5]: https://dart.dev/codelabs/async-await
In its syntax, its very similar to classic languages like C++ and Java. It's very easy to pass functions around, like Javascript/Ruby. I didn't really need to 'learn' it, it all seemed familiar from the beginning. It also has some nice little shortcuts, like null-safe member function calls.
As for the typing system, it is definitely compiled/typed, which I like, but it does not feel overbearing. I find it to be in a nice sweet spot between hard to refactor/you need unit tests for everything (ruby/javascript) and hard/wordy to write because the type system is too strict (C++/Java).
It also has a nice packaging system (like ruby/javascript), and it has been thoughtful about how you reference packages.
Overall, I like it a lot.
* Typescript is much more popular, and integrates with other Javascript things better. There are way more libraries available for Typescript.
* Typescript has proper support for non-null types, whereas in Dart everything is nullable (though they are fixing it, as announced here).
* Typescript has pretty nice support for anonymous sum types (i.e. `number | string`).
However:
* Typescript doesn't actually fix any of the insanity of Javascript - it just describes it. So you can still do insane things like using `var` or `==`. In Dart all of that nonsense has been removed.
* Typescript has `interface` and `class` which is needlessly confusing (it has no choice because Javascript).
* It's way too easy to give up on typing in Typescript. It has a setting "no implicit `any`" but it doesn't seem to be comprehensive. You can do still stuff like just omitting the return type of functions and then they instantly lose all type information. In Dart you have to explicitly opt in to `dynamic`.
* Because types are added to Javascript libraries (via DefinitelyTyped), there's nothing that really checks that they are correct and very often they are just wrong. It's pretty annoying to fix when that happens and even harder to know what the correct fix is because obviously the underlying Javascript library has no types! You basically have to ask the authors what they meant.
* A lot of libraries aren't fully typed. For example Vue has very minimal typing - lots of things are just strings. As a concrete example, AngularDart gives you compile errors if the types in your HTML template are incorrect. With Vue they are runtime errors.
* The Dart VSCode extension is literally amazing. It gives you perfect errors and completion and it does it instantly. Nothing else I've used comes close.
When I first started using Typescript I was kind of under the impression that it was a better language built on top of Javascript. That's not really the case - it's still Javascript, it's just a slightly less insane way of using Javascript.
Dart, on the other hand is a better language.
Java and C# have had a distinction between `interface` and `class` for decades. It shouldn't be that confusing? One describes a shape or a contract of an object and the other an implementation of a kind of object (which in turn might support multiple interface shapes/contracts). It's not something unusual to OOP languages with type systems. Perhaps the only thing to complain about Typescript interfaces is that they are far more on the shape side of things than the contract side of things, and it is tough to rely on them if you want more of the contract semantics (because the language can't enforce that contract).
> It's way too easy to give up on typing in Typescript. It has a setting "no implicit `any`" but it doesn't seem to be comprehensive
Typescript gets as comprehensive as you want it to be. It's set of checks is an onion design to allow for various control needs, especially because projects may need to opt-in to only some of the checks in order to ease migration. If you want all the checks the flag to pass isn't `--noImplicitAny` it is `--strict` (or in tsconfig.json, "strict": true). I recommend that for all greenfield projects and most brownfield projects if they don't mind fixing lots of compile errors (for the betterment of their project).
> Because types are added to Javascript libraries (via DefinitelyTyped), there's nothing that really checks that they are correct
Not all type information is from DefinitelyTyped anymore, and in many ways DT is smaller than it was at its peak. More and more libraries on npm themselves are written in Typescript and provide their own type information fresh out of the Typescript compiler itself. Even libraries that aren't written in Typescript are taking maintenance ownership of their Typescript types themselves and sometimes the JS authors are right there critiquing their own types.
There will always be a mismatch between untyped JS and what Typescript types represent of that world, but it is better than it used to be, and better all the time.
That's not the case: http://www.typescriptlang.org/play/#code/GYVwdgxgLglg9mABFAp...
Dart is basically ES6&(TypeScript|Flow), but randomly slightly different, and usually in a way that makes it slightly weaker or more Java-eque, neither of which I prefer.
Basically it's not different enough from ES6 (plus a typing system) to be useful, just different enough to be annoying.
Immutability is leveraged extensively in Flutter. That said, functional programming is a struggle with Dart. Although it's not particularly well suited to Typescript either. Some specific things like async stuff are better in Dart/Flutter. As Dart adheres more strongly to classes/inheritance its facilities for that are more extensive.
Dart is perhaps more Java-ish while Typescript is more C#-ish, if that makes sense.
Flutter's strength is certainly not the language, it's the SDK/platform. It's miles ahead React Native in my experience.
Take a look at some samples to get a grasp on how it looks like: https://dart.dev/guides/language/language-tour
The real magic is Flutter though, and outside of that, not sure if Dart has many applications. Dart on Node could be a thing, but seems like more of a hassle right now.
(Also, Xamarin and C# wave hello from the other room.)
Personally I'm frustrated Google is investing so much in Dart/Java platform while Rust is far more promising but has a small fraction of manpower dedicated to it.
I built a little Android/iOS app in Flutter and it was a real delight. I didn't especially like Dart at first, but it was easy enough to pick up and then got out of the way more or less. I'd love to be able to easily run an app like that on the web. I know Dart's original vision was to replace JS but it seems they backed off that a bit. But it sounds like it's back on the menu!
I don't know if this changes anything exactly, in terms of what Flutter can do right now. I think web/desktop have always sort of been there. But what's new for me is this perspective that they intend to support other devices beyond mobile. I wasn't really sure about that before, since it seemed mostly tailored to just iOS/Android when I was working with it.
More than "a bit" - replacing JS hasn't been the goal for several years now.
So I keep hoping that they could eventually trigger a move from Electron to React Native for VS Code, the only Electron app I care to waste my time on.
If it's a much smaller footprint, memory and CPU wise, it could be. Also depends on how easy it is to learn the language/framework and how easy it is to deploy to multiple platforms. That lack of friction is what makes Electron so devilishly popular.
https://medium.com/dartlang/a-brand-new-dartpad-dev-with-flu...
See download sizes here [1], if they remind you electron app sizes [2], it's because flutter is a slimmer (not by much) Chrome.
Flutter will suffer from huge update sizes like electron, but may be faster out of the box, and slimmer (not by much) in RAM. However, using Carlo [3] or Lorca [4] can yield similar benefits, without learning dart, or dealing with brand new flutter edge cases solved years ago elsewhere. In my opinion, flutter is not yet a better mouse trap for desktop apps, and even for mobile, ionic 4 is plenty performant
[1]: https://github.com/flutter/samples/releases/tag/gallery-v2.0
[2]: https://central.github.com/deployments/desktop/desktop/lates...
On the other hand, I bet JetPack Composer, and the app reloading reboot, would never had happened if the Android team wasn't continuously being asked about what they think about Flutter on Q&A sessions.
I am pretty sure I just want my app to run on Android, iOS, and web. If Flutter's vision is making it possible to also design to TVs, smartwatches, thermostats, doorbells, fridges, etc it means that there will be trade-offs, added complexity, overhead, design choices to support that "ambient computing" vision.
I don't want any of that, and it is good to know that in advance. RN it is.
For starters, who said RN is not having work done to run on "TVs, smartwatches, thermostats" and so on? Here's a post about work done for smart TVs from the official RN blog:
https://facebook.github.io/react-native/docs/building-for-ap...
Second, who said those concerns aren't orthogonal? Given a good modular design work done for the framework to work on a TV should not impact work done for the framework to play well on the Web or mobile.
About your second point, I imagine it could be totally orthogonal. But I am especulating that it won't be. At some point there will be design decisions to be made around trade-offs and I'm sure Google's necessity to push "ambient computing" into the world will prevail over any modularity concerns.
Flutter is targeting a lot of platforms. Part of this is that Google has a lot of hardware projects that need a UI, and the duplication from building a new UI stack each time was getting tedious.
But this doesn't mean that Flutter apps are doing the same. You can just target the platforms you want. It's not going to run anywhere else if you don't deploy it there.
FWIW, one of our driving values is to specifically _not_ compromise in this way. We actively avoid having a "lowest common denominator" approach. I learnt about the risks of such an approach when I was the HTML spec editor. It's one of the reasons that we have been only adding new platforms very carefully, and it's why we've been focusing so much on mobile first. The vast majority of the team is focused on mobile, with a small team on Web and an even smaller team (1-4 people depending on how you count it) working on desktop.
You should do a hello world at least.
Just like many games that people play on the train, which are yet another variation of matching stuff, are easily doable with WebGL.
The way some presenters speak, it seems that other OS or framework groups are competition that belongs to another company, instead of teams that work for the same employer.
There are still a lot of older api's that web browsers have to support.
[1] https://www.reddit.com/r/Fuchsia/comments/blyutb/the_nest_hu... (See top comment)
[2] https://twitter.com/timsneath/status/1125868510645669888?s=2...
As TFA says:
"In this emerging world, the focus starts to move away from any individual device towards an environment where your services and software are available wherever you need them. We call this ambient computing".
In other words, going from devices as siloes you use one at a time, each with each own apps, accounts, data, and so on, into using a plethora of devices that play together, can run appropriate versions of the same apps, give you access to your data from wherever you are, switch your workflow from one to another, and so on.
So like multi-platform apps + cloud storage + what Apple calls "Handoff / Continuity" or MS calls "Timeline" + IoT...
Whenever I see Slack, Spotify, VS Code, or any other "universal" app, it always strikes me as a completely out of place it looks and behaves, no matter what OS it's running on. Yes, it's relatively easy to make a multiplatform app with these technologies, ticking all the boxes specified by bean-counters, but in the process it usually completely sacrifices all the little details, integrations, patterns, etc. that make platform-specific apps such a pleasure to use. If you're used to apps behaving in a predictable manner, e.g. having similar shortcuts, similar icons having the same meaning (and other way round - similar actions having the same icon), then e.g. seeing a Material Design on macOS is just weird and looks completely out-of-place, not mentioning event UX aspects.
I know it's hard to quantify this in an Excel spreadsheet, but in my opinion following interface guidelines of the target platform and properly using its native technologies makes for a much better user experience (I'm talking here about the basic meaning of this phrase). For example, just look at Google Docs app for iPad - for sure it's written using some Google's weird "universal" technology, but every time Apple announces new iOS (now iPadOS) features, like split screen, multiple windows, etc. it taks Google months to provide support for them. At the same time, developers that follow Apple's guidelines and recommendation, they usually get these features in their apps "for free" or with relatively small amounts of work required.
I'm simplifying the whole situation here, of course, but I think trend of making all apps in Flutter et al. might be good for some people, but end-users are usually not one of them.
Flutter was so much more efficient, it actually lives up to the promise of write-once, build to multiple platforms.
As for design, we have a very custom design and in Flutter you are in no way locked into Material design.
https://en.wikipedia.org/wiki/Ubiquitous_computing
https://en.wikipedia.org/wiki/Calm_technology
https://www.researchgate.net/post/What_is_differents_between...
https://internetofthingsagenda.techtarget.com/definition/per...
>The term pervasive computing followed in the late 1990s, largely popularized by the creation of IBM's pervasive computing division. Though synonymous today, Professor Friedemann Mattern of the Swiss Federal Institute of Technology in Zurich noted in a 2004 paper that:
>Weiser saw the term 'ubiquitous computing' in a more academic and idealistic sense as an unobtrusive, human-centric technology vision that will not be realized for many years, yet [the] industry has coined the term 'pervasive computing' with a slightly different slant. Though this also relates to pervasive and omnipresent information processing, its primary goal is to use this information processing in the near future in the fields of electronic commerce and web-based business processes. In this pragmatic variation -- where wireless communication plays an important role alongside various mobile devices such as smartphones and PDAs -- ubiquitous computing is already gaining a foothold in practice.
You say pervasive, I say perversive. Let's call the whole thing off.
