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.
To be fair they're not always that easily accessible on React Native either. A lot of the times they seem to break stuff in weird ways, if they work at all.
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.
We don't really "emulate" the UI on Android, FWIW. We have one of several implementations of Material design, another of which is designed for the Android View hierarchy, another is designed for JS on the Web, and so on. In some respects Flutter's implementation is actually ahead of the others, so if anything, they're "emulating" us. :-)
You're not using native UI. You're emulating the UI by re-painting it. No matter what you call it, it's an emulation of the native UI, which means it can become out of sync.
Currently React Native can bridge with all Windows platforms, MacOS, Android, iOS. Web can be targeted via React Native Web fork or a wrapper like ReactXP.
That is a more attractive option than an emulated UI. It's similar to wxWidgets vs QT. I much prefer bridging to emulation.
Flutter has been introduced in 2015 while Dart has been around since 2011. Since Google seems to have bold plans for their Fuchsia operating system to replace Linux for mobile, laptop and smart home devices and is using the framework for actual devices they already ship to customers, I'd say it's safe to assume that Flutter and Dart won't be abandoned anytime soon.
Not sure if it is counter-intuitive, but I was deciding between React Native and Flutter for a project and this announcement nudged me to decide on React Native.
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.
This reads like someone who had already made their mind, and looked for anything to support their prior bias...
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:
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.
Didn't know about the RN build for TV stuff, will do some research to check if they have the same vision. If they do, back to square one.
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.
>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.
Or "ambient computing" is just marketing fluff, and in the end it will just be the same typical set of libs, and APIs and tools as in RN and other such frameworks, just with some extra UI widgets and libs for smaller devices.
This seems a little odd, like refusing to use a programming language that's too portable. There are C libraries for various embedded devices you've never heard of, but you don't have to use them.
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.
Is building plugins faster/easier than building apps (using Flutter)? Looking to learn flutter so wondering if I should build a plugin or app when going beyond hello world.
Build an app. There are many things in the plugin api that you don’t interact with in the app. The plugin api is the bridge between the front-end and native iOS / Android apis.
Over 5 years ago, I created a background-geolocation plugin for Cordova. I later ported it to React Native and now flutter. It’s not every plugin that could be monetized. Geolocation, especially in the terminated state, is a special case.
We specifically evaluated both RN and Flutter in a lot of depth. We ended up going with Flutter and could not be happier. I agree with other commenters, it seems like you had your mind made up because this is a very weak reason to use one over the other.
Am I the only one who sees all these Electrons, React Natives, Flutters, etc. as mostly middle-management-pleasing technologies made for crunching cookie-cutter apps with the least amount of outsourced developers as possible?
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.
Using Flutter has been extremely helpful for us in a startup environment, getting apps built for both iOS and Android in half the time (or less) compared to doing both. Our team has plenty of native mobile experience and has built separate native apps that mirror functionality in the past.
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.
I don't think the majority of end users care much. They have gotten used to web apps more than anything, a unified web-like UI across platforms might even been seen as a positive by them.
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.