Wow, talk about burying the lede. I'm not sure how I feel about Google's so-called "ambient computing" idea that they were all about at this year's Google I/O, but Flutter being championed for desktop and web are huge! Does this mean the end of Electron, finally? They say it runs on macOS, I hope they get to Windows and Linux soon.
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.
Microsoft's team for "React Native for Windows" and now "React Native for macOS", keep showing benchmarks how resource hungry Electron is versus C++, C# and React Native.
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.
Last year I was able to get a simple HN browser app running on both desktop Linux (Ubuntu) and Windows 10 as well. They weren't perfect, but I'm certain support is even better now.
I doubt flutter will be significantly leaner for real world, full featured apps, like slack. After all flutter is reusing Chrome's building blocks, with Skia and many other render related libraries, with similar IPC architecture for security, etc. They've replaced the js run-time with dart.
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
Another thing is that Flutter is Dart's Rails, and I learned several times not to be stuck with a framework specific language.
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.
Bizarre reading the vision for this "ambient computing" platform given that the web platform has already been doing that for years and you could imagine the Chrome team using nearly identical terms to describe what their mission is.
You'd be surprised how many popular and widely used mobile apps run a significant portion of their experience with web tech. Depending on who you ask it is a great platform for mobile apps (not that it can't be improved of course!)
If you haven't done so, you should spend some time watching the tracks from Google IO.
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.
31 years late, Google attempts to re-brand "Ubiquitous Computing" (aka "Calm Technology") as "Ambient Computing". At least it sounds more mellow, less intrusive, unwelcome, penetrative, and phallic than the other attempt at rebranding UbiComp as "Pervasive Computing" in order to sell it to the military.
>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.
What are people's impression of Dart as a language, compared to e.g. Typescript? Reviews so far seems lackluster. Does Dart have anything that sets it apart from JS, like immutable data structures out of the box? How's the support for functional programming, e.g. first order functions, closures, higher order functions like map, filter, reduce, etc?
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]
As a programmer with experience in C++, Java, Ruby, and Javascript, and someone who just wants to get things done, I love Dart.
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.
I've used both recently, deciding between them. Dart is better.
* 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.
> Typescript has `interface` and `class` which is needlessly confusing
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.
I don't really like Dart, but I put up with it in order to use Flutter, which is awesome.
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.
They're inherently similar. Both highly verbose and quite object oriented. Dart is less flexible and arguably less advanced, but unlike Typescript, it's sound (as in type soundness). For a very specific target (mobile) being a bit less advanced is completely fine, it has all the abstractions needed for mobile development.
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.
I think it is really comparable to TypeScript. I do miss (sometimes) Union operators (I know there are some ways to add that to Dart). And as a JS/TS dev first, some things about Dart drive me a bit bonkers - like their array methods and how some of them return void and some of them return a new array. Like forEach vs. map, but at least those two make sense. Some of the ones in Dart don't feel like they make sense, at least to me.
It's been ok for me, feels a bit half-baked in many places (i.e. enums, serialization, constructors, collection manipulation), especially coming from a well thought-out language like Swift or Kotlin. Apparently null safety and extensions are coming which is good. On the other hand it's surprisingly straightforward and simple, more so then Typescript. It has basic OOP, type system, generics, closures & co, all the things you know and need, nothing too fancy, just a good subset for productivity.
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.
Any language/toolchain that compiles to both native Android and native iOS is going to be a blessing, regardless of the features at the language-level.
Dart always seems to lag behind TypeScript, for example a lot of the built-in functions return dynamic type because they don't have utility types yet.
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.
Scanned the whole article, still don't know what "ambient computing" is. I suppose they mean writing apps that run on the little microphones they want us to put all over our houses. Seems like I remember there being a platform that was built in the '90s to run on any device. What was it called..
>Scanned the whole article, still don't know what "ambient computing" is.
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...
It's not called out in this blog post, but back at Google I/O earlier this year, they did say Fuchsia is powering the Nest Hub and Nest Hub Max. So those smart displays Google is making are Fuchsia + Flutter.
Actually, both Nest Hubs run on the Chromecast-platform, not on Fuchsia[1]. However their UI is actually made with Flutter[2]. However, both devices (as Sherlock and Astro respectively) exist in the Fuchsia repo and so it's safe to assume that they're developing Fuchsia on them and since Flutter is multi-platform they can replace the OS underneath via software update, if they chose to.
It would be really nice if Google would get something going for dart on the server-side. I personally would make the switch to using dart full time for my side projects if I got the same benefits as I do with using node / react.
Readit News
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...
https://flutter.dev/web
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...
[3]: https://github.com/GoogleChromeLabs/carlo
[4]: https://github.com/zserge/lorca
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.
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.
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.
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.)
Dead Comment
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.
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...
[1] https://www.reddit.com/r/Fuchsia/comments/blyutb/the_nest_hu... (See top comment)
[2] https://twitter.com/timsneath/status/1125868510645669888?s=2...