Google’s Flutter = React and Java Swing(codeburst.io)
codeburst.io
Google’s Flutter = React and Java Swing
https://codeburst.io/googles-flutter-react-java-swing-8174c8d9d402
155 comments
> Flutter is an amazing project. It feels like an futuristic version of the Android SDK.
This is how I would like to have seen ChromeOS being implemented, a fresh revisit of the Smalltalk experience but using Dart instead.
Instead they created a browser window manager.
This is how I would like to have seen ChromeOS being implemented, a fresh revisit of the Smalltalk experience but using Dart instead.
Instead they created a browser window manager.
At least that "browser window manager" came with lots of useful tools to solve problems with the computer, based on a wide ecosystem.
"Smalltalk Revisited" doesn't solve any problems per-se, and would be firmly stuck in the chicken and egg corner that produced way too many stillborn projects in IT.
So, Chrome OS implementing Dart might have been interesting, but on the other hand, as soon as there was talk about adding Dart to the web platform, there were all those rants about "Google is monopolizing the web!!!!11". I guess it's hard to please everyone.
(disclosure: I'm on the Chrome OS firmware team. Although while "Chrome", there's definitely no Javascript or Flutter involved. My team's code needs to run in the absence of arbitrary amounts of RAM [edit-to-add: which means I have no stake in the game of which language has a hipster-compatible garbage collector])
"Smalltalk Revisited" doesn't solve any problems per-se, and would be firmly stuck in the chicken and egg corner that produced way too many stillborn projects in IT.
So, Chrome OS implementing Dart might have been interesting, but on the other hand, as soon as there was talk about adding Dart to the web platform, there were all those rants about "Google is monopolizing the web!!!!11". I guess it's hard to please everyone.
(disclosure: I'm on the Chrome OS firmware team. Although while "Chrome", there's definitely no Javascript or Flutter involved. My team's code needs to run in the absence of arbitrary amounts of RAM [edit-to-add: which means I have no stake in the game of which language has a hipster-compatible garbage collector])
So let me tell you that I don't see any value spending money on ChromeOS as it is, and there is hardly any computer store in Europe selling Chromebooks.
When they try to sell them, it is a single model on a corner of the shop with increasing discounts until someone finally takes it away, or they return the unit back.
So from European point of view those "lots of useful tools to solve problems with the computer, based on a wide ecosystem." are nowhere to be seen.
> My team's code needs to run in the absence of arbitrary amounts of RAM
Chrome's memory usage on the process system monitor shows a different reality about that code.
When they try to sell them, it is a single model on a corner of the shop with increasing discounts until someone finally takes it away, or they return the unit back.
So from European point of view those "lots of useful tools to solve problems with the computer, based on a wide ecosystem." are nowhere to be seen.
> My team's code needs to run in the absence of arbitrary amounts of RAM
Chrome's memory usage on the process system monitor shows a different reality about that code.
I think I missed the real meat in this comment in my other response, so here's attempt #2:
> So from European point of view those "lots of useful tools to solve problems with the computer, based on a wide ecosystem." are nowhere to be seen.
These "useful tools" are web sites (and web apps). By providing excellent support for these, the devices are immediately useful. Much better than hoping that another ecosystem like Android's can be jumpstarted.
The average user buys a (hypothetical) Dartbook: Looks for some Dart app. Gets frustrated by the lack of choice. Returns the device.
The average user buys a Chromebook: Browses their favorite websites (and face it: 90% of contemporary computer use is _just_ _that_). Reasonably happy customer (unless they insist on installing "TuneUp Utilities" because they always do that).
That's what I meant with the availability of lots of useful tools to solve problems with the computer (in that case, a Chromebook), repurposing a wide ecosystem (the entire web, basically).
From your other comments on this site (eg about the Atom editor), you seem to be fundamentally opposed to html/js as a platform and with that sentiment, Chromebooks must look anathema to you. Alright, that's one position to take. But what use would be a Dartbook to you? You'd probably complain (with full reason!) about its inability to run emacs just the same.
> So from European point of view those "lots of useful tools to solve problems with the computer, based on a wide ecosystem." are nowhere to be seen.
These "useful tools" are web sites (and web apps). By providing excellent support for these, the devices are immediately useful. Much better than hoping that another ecosystem like Android's can be jumpstarted.
The average user buys a (hypothetical) Dartbook: Looks for some Dart app. Gets frustrated by the lack of choice. Returns the device.
The average user buys a Chromebook: Browses their favorite websites (and face it: 90% of contemporary computer use is _just_ _that_). Reasonably happy customer (unless they insist on installing "TuneUp Utilities" because they always do that).
That's what I meant with the availability of lots of useful tools to solve problems with the computer (in that case, a Chromebook), repurposing a wide ecosystem (the entire web, basically).
From your other comments on this site (eg about the Atom editor), you seem to be fundamentally opposed to html/js as a platform and with that sentiment, Chromebooks must look anathema to you. Alright, that's one position to take. But what use would be a Dartbook to you? You'd probably complain (with full reason!) about its inability to run emacs just the same.
> These "useful tools" are web sites (and web apps).
Web browser app....
> The average user buys a Chromebook:
And returns it back after discovering it cannot install his/her favorute software and requires a permanent internet connection to make anything useful with the device.
> The average user buys a (hypothetical) Dartbook: Looks for some Dart app. Gets frustrated by the lack of choice. Returns the device.
The return rate of those devices running Android is quite big apparently.
> But what use would be a Dartbook to you?
The same as my tablet and mobile phone running Android.
Web browser app....
> The average user buys a Chromebook:
And returns it back after discovering it cannot install his/her favorute software and requires a permanent internet connection to make anything useful with the device.
> The average user buys a (hypothetical) Dartbook: Looks for some Dart app. Gets frustrated by the lack of choice. Returns the device.
The return rate of those devices running Android is quite big apparently.
> But what use would be a Dartbook to you?
The same as my tablet and mobile phone running Android.
eh, I own an Acer Chromebook R11 and am pretty happy with it...
The battery life is wonderful for that price bracket (~8-10 hours, <300€). I used crouton for a few month, which enabled me to install Ubuntu 14.04 in dual-boot. you could switch between ChromeOS and the chosen Linux window manager (i first used unity but switched to i3wm eventually).
At some point, i removed it again because I hardly used the Linux environment anymore. There a pretty fine text editors as offline chrome-extensions available (i.e. Caret) and that was the only two use-cases I had for the laptop... browsing the internet and making text notes.
BTW, a lot of webapps, or "Web browser app" as you call them, have offline support. So no, you don't need an internet connection to use them.
The battery life is wonderful for that price bracket (~8-10 hours, <300€). I used crouton for a few month, which enabled me to install Ubuntu 14.04 in dual-boot. you could switch between ChromeOS and the chosen Linux window manager (i first used unity but switched to i3wm eventually).
At some point, i removed it again because I hardly used the Linux environment anymore. There a pretty fine text editors as offline chrome-extensions available (i.e. Caret) and that was the only two use-cases I had for the laptop... browsing the internet and making text notes.
BTW, a lot of webapps, or "Web browser app" as you call them, have offline support. So no, you don't need an internet connection to use them.
Also have a R11 Chromebook and love it. I do use Crouton but been also using GNUroot as does not require developer.
What I love is being able to do cloud development (Linux) on a commercial laptop.
I wish Google would push this harder as a great dev solution. My biggest gripe is small storage on most CBs. Plus no sdcard access from containers on the R11. Also all Android runs in same container.
What I love is being able to do cloud development (Linux) on a commercial laptop.
I wish Google would push this harder as a great dev solution. My biggest gripe is small storage on most CBs. Plus no sdcard access from containers on the R11. Also all Android runs in same container.
It's a mistake to look at Chromebooks as consumer products.
I have bought Chromebooks for my employees. They can access business resources without me having to worry about them getting hacked and leaking proprietary information and passwords to production systems. Chromebooks are cheap, unsexy, and can't run fancy games. These are all pluses.
Chromebooks are the 3270 of the present day. They're for the average customer service representative, not for the home user.
I have bought Chromebooks for my employees. They can access business resources without me having to worry about them getting hacked and leaking proprietary information and passwords to production systems. Chromebooks are cheap, unsexy, and can't run fancy games. These are all pluses.
Chromebooks are the 3270 of the present day. They're for the average customer service representative, not for the home user.
I don't agree. Chromebooks are wonderful for the elderly and folks who don't need a traditional OS. They can browse the web, read email, watch videos, without worrying about drivers, virus, downloading gigs and gigs of update every years for features they don't care about.
Not really. There's a reason why Chromebooks are so popular on Amazon. People just want a device that is free from viruses and malware and something that doesn't need constant maintenance or an on call support person from their family.
> there is hardly any computer store in Europe selling Chromebooks.
Very different reality in the US. My local best buy and Target have at least 4 high end chrome books each for sale.
> Chrome's memory usage on the process system monitor shows a different reality about that code.
?? I'm a bit confused by this, his team writes chrome os firmware code, nothing to do with the browser.
Very different reality in the US. My local best buy and Target have at least 4 high end chrome books each for sale.
> Chrome's memory usage on the process system monitor shows a different reality about that code.
?? I'm a bit confused by this, his team writes chrome os firmware code, nothing to do with the browser.
> there is hardly any computer store in Europe selling Chromebooks
That's a sad reality of Google products that aren't free ("monetized through ads" if you prefer) web services: Unless you're in the US, they might as well not exist.
It's just impossible to sign up for them legitimately (ie. without using a VPN, US credit card and a forwarding mail address in the US.)
Personally I think that a plethora of the "paid" Google products (including Chromebooks!) could do pretty well in Europe if given the chance, but for reasons good or bad they never get the chance to prove themselves in the market in the first place.
> When they try to sell them, it is a single model on a corner of the shop with increasing discounts
Nevertheless, _when_ they are available, they're doing a bit better than you describe it: https://geizhals.de/?phist=1461289 https://geizhals.de/?phist=1483242 https://geizhals.de/?phist=1564920 https://geizhals.de/?phist=1378869 https://geizhals.de/?phist=1439976 are a sample of devices for the German market (limited the search to the set of devices with a DE keyboard to avoid imported models, whose prices fluctuate wildly and aren't what people typically consider regular market availability), both low-end and high-end, and the development of those price indexes looks pretty normal for notebooks.
> Chrome's memory usage on the process system monitor shows a different reality about that code.
"Chrome OS firmware team". My team's code doesn't ever show up on the process system monitor.
That's a sad reality of Google products that aren't free ("monetized through ads" if you prefer) web services: Unless you're in the US, they might as well not exist.
It's just impossible to sign up for them legitimately (ie. without using a VPN, US credit card and a forwarding mail address in the US.)
Personally I think that a plethora of the "paid" Google products (including Chromebooks!) could do pretty well in Europe if given the chance, but for reasons good or bad they never get the chance to prove themselves in the market in the first place.
> When they try to sell them, it is a single model on a corner of the shop with increasing discounts
Nevertheless, _when_ they are available, they're doing a bit better than you describe it: https://geizhals.de/?phist=1461289 https://geizhals.de/?phist=1483242 https://geizhals.de/?phist=1564920 https://geizhals.de/?phist=1378869 https://geizhals.de/?phist=1439976 are a sample of devices for the German market (limited the search to the set of devices with a DE keyboard to avoid imported models, whose prices fluctuate wildly and aren't what people typically consider regular market availability), both low-end and high-end, and the development of those price indexes looks pretty normal for notebooks.
> Chrome's memory usage on the process system monitor shows a different reality about that code.
"Chrome OS firmware team". My team's code doesn't ever show up on the process system monitor.
> Nevertheless, _when_ they are available, they're doing a bit better than you describe it:
I am describing computer stores where people walk into, not online stores.
> "Chrome OS firmware team". My team's code doesn't ever show up on the process system monitor.
So, nothing that would have a major impact on using a more productive operating system, and wouldn't forbid the use Dart instead of the JavaScript/HTML/CSS triumvirate.
I am describing computer stores where people walk into, not online stores.
> "Chrome OS firmware team". My team's code doesn't ever show up on the process system monitor.
So, nothing that would have a major impact on using a more productive operating system, and wouldn't forbid the use Dart instead of the JavaScript/HTML/CSS triumvirate.
> I am describing computer stores where people walk into, not online stores.
There are two major issues that make them a worse source for data points on hardware popularity than online stores:
1. Availability: it's hard to get the numbers in an aggregate form, while I just skimmed a search engine for 5 minutes.
2. Shelf space: brick and mortar stores can only ship 2 devices of a small set of major OEMs. With such constraints, they'll limit themselves to what they belive will be block busters in their (brick&mortar) market, creating a reinforcing loop.
Before the iPhone (say 2003), many stores didn't even carry Apple computers because they were "niche" and incapable of running Magix Video Deluxe.
It's too expensive to keep "one of everything" around when you pay $$$ for every square meter of shop space. That's a market distortion, not a hyper-realistic representation of customer intent.
There are two major issues that make them a worse source for data points on hardware popularity than online stores:
1. Availability: it's hard to get the numbers in an aggregate form, while I just skimmed a search engine for 5 minutes.
2. Shelf space: brick and mortar stores can only ship 2 devices of a small set of major OEMs. With such constraints, they'll limit themselves to what they belive will be block busters in their (brick&mortar) market, creating a reinforcing loop.
Before the iPhone (say 2003), many stores didn't even carry Apple computers because they were "niche" and incapable of running Magix Video Deluxe.
It's too expensive to keep "one of everything" around when you pay $$$ for every square meter of shop space. That's a market distortion, not a hyper-realistic representation of customer intent.
Not sure of you can trust the best sellers list on amazon to indicate true sales, but #2, 6, 12, 15, 17, 20, 21, 22, 23, 30 are chromebooks. That's pretty significant if not marketing dollars
Fuchsia is using Flutter for applications.
Yes, but we still don't know what will actually happen to Fuchsia.
Hopefully it will be something like that, a nice micro-kernel OS, using a mix of C++/Rust and Dart.
But given how Google projects go, it might just be canceled or pivot into something else, e.g. Brillo vs Android Things.
Hopefully it will be something like that, a nice micro-kernel OS, using a mix of C++/Rust and Dart.
But given how Google projects go, it might just be canceled or pivot into something else, e.g. Brillo vs Android Things.
The source code is out there updated heavily through the week - http://fuchsia.googlesource.com
I see that C++, some C, go, rust, python, yes dart and possibly other languages are being used. First I was thinking this is crazy, but then I'm reminded of how much each modern Operating System is more or less "C" based, where any non-C language has to make bindings, ffi connections, etc. to get to the low-level.
Instead, use something like mojo (called fidl), which is like protobuf, but only for IPC - e.g. much more lightweight (but doesn't support endianess handling), and use it for communication between the systems. Make fidl generate bindings for each languages, and wire everything together with it.
(mojo to my knowledge is what the chrome browser uses to communicate with it's isolated instances).
I see that C++, some C, go, rust, python, yes dart and possibly other languages are being used. First I was thinking this is crazy, but then I'm reminded of how much each modern Operating System is more or less "C" based, where any non-C language has to make bindings, ffi connections, etc. to get to the low-level.
Instead, use something like mojo (called fidl), which is like protobuf, but only for IPC - e.g. much more lightweight (but doesn't support endianess handling), and use it for communication between the systems. Make fidl generate bindings for each languages, and wire everything together with it.
(mojo to my knowledge is what the chrome browser uses to communicate with it's isolated instances).
True, but given the reports that Andromeda (their ChromeOS/Android mashup OS) was shelved in favor of Fuchsia, it's more likely they'll stick with this.
I would argue that it's more likely that they'll kill that too. Evidence you stated suggested they already killed one OS
Does anyone feel a tinge of guilt using the amazing technology that Google provides?
I think Google is overall a pretty "evil" (I use quotes because the term is loaded, and the reasoning is too long to easily state) company. IMO Google is, at best, hard-to-trust, and at worst adversarial in many of the decisions they make. But I sure am excited when it produces technology like Android, Golang, Flutter etc and makes it free to use.
Personal opinions aside, what they've done here is managed to create a full-measure cross platform mobile application, and they have the resources that warrant taking them seriously. All the other options are either half measures or require such a drastic shift/ongoing support that I hesitate to use them, to list a few:
- Cordova/Phonegap (half-measure)
- React Native (Facebook is your benevolent dictator)
- Lambda Native (convince the team to go full lisp, and hope/build support as the platforms change under you)
- Native (learn all the ins and out of 2+ different platforms, and hope to be prolific, because you'll likely not be expert in either one)
I just wanna know if anyone else has this dilemma/thinks about this.
IANAL, but the license (https://github.com/flutter/flutter/blob/master/LICENSE) is basically MIT + don't put google's name in your product... Maybe I'm thinking about this too much
I think Google is overall a pretty "evil" (I use quotes because the term is loaded, and the reasoning is too long to easily state) company. IMO Google is, at best, hard-to-trust, and at worst adversarial in many of the decisions they make. But I sure am excited when it produces technology like Android, Golang, Flutter etc and makes it free to use.
Personal opinions aside, what they've done here is managed to create a full-measure cross platform mobile application, and they have the resources that warrant taking them seriously. All the other options are either half measures or require such a drastic shift/ongoing support that I hesitate to use them, to list a few:
- Cordova/Phonegap (half-measure)
- React Native (Facebook is your benevolent dictator)
- Lambda Native (convince the team to go full lisp, and hope/build support as the platforms change under you)
- Native (learn all the ins and out of 2+ different platforms, and hope to be prolific, because you'll likely not be expert in either one)
I just wanna know if anyone else has this dilemma/thinks about this.
IANAL, but the license (https://github.com/flutter/flutter/blob/master/LICENSE) is basically MIT + don't put google's name in your product... Maybe I'm thinking about this too much
I feel like Google generally takes the right side of things. Defensive patents, tight security, easy to use, friendly products. Their stuff is mostly open source and free. TBH Google are relative angels. Microsoft before them had shitty products and strongarmed other corps to get what they wanted. Actively sued based on dumb patents. And Apple only turned "privacy" into a thing they supposedly cared about when people started being concerned about Google's powers. They're not actually sincere about it, it's marketing like everything else.
Sometimes I think people forget the history of how and why Google got where it is. They've had some snafus, but for the most part just been a freaking awesome company from the start who puts out amazing, free things, and push OS and CS research forward.
No, I have no guilt using anything they make.
Sometimes I think people forget the history of how and why Google got where it is. They've had some snafus, but for the most part just been a freaking awesome company from the start who puts out amazing, free things, and push OS and CS research forward.
No, I have no guilt using anything they make.
> They're not actually sincere about it, it's marketing like everything else.
Really? How do you explain Secure Enclave, end-to-end iMessage encryption and lots more? Not to mention the tough stance they publicly took against FBI wanting special OS version to crack terrorist phones?
Really? How do you explain Secure Enclave, end-to-end iMessage encryption and lots more? Not to mention the tough stance they publicly took against FBI wanting special OS version to crack terrorist phones?
To play the devil's advocate:
> Secure Enclave
ARM TrustZone. My 2005-era low-end devices have that. Hardly Apple's idea.
Microsoft did ground work in that space for ~2 decades by now. It's called TPM and has a bunch of advantages by being a discrete component. It's also an industry-wide initiative and open to all.
> end-to-end iMessage encryption
Perfect for locking down the ecosystem.
> tough stance they publicly took against FBI
Posturing (on both sides: The FBI knows that they're SoL on getting such favors, with or without writing whiny op-eds on how they're incompetent).
You'd have already seen leaked versions of the "special OS versions to crack" had the other vendors budged to such demands. They might just discuss matters with the Feds without inviting the press.
> Secure Enclave
ARM TrustZone. My 2005-era low-end devices have that. Hardly Apple's idea.
Microsoft did ground work in that space for ~2 decades by now. It's called TPM and has a bunch of advantages by being a discrete component. It's also an industry-wide initiative and open to all.
> end-to-end iMessage encryption
Perfect for locking down the ecosystem.
> tough stance they publicly took against FBI
Posturing (on both sides: The FBI knows that they're SoL on getting such favors, with or without writing whiny op-eds on how they're incompetent).
You'd have already seen leaked versions of the "special OS versions to crack" had the other vendors budged to such demands. They might just discuss matters with the Feds without inviting the press.
The Secure Enclave is not ARM TrustZone. The SEP is a discrete component.
You seem to be easily deceived.
> push OS and CS research forward.
I think you have mistaken Google for Microsoft Research, in what concerns pushing OS research forward.
I think you have mistaken Google for Microsoft Research, in what concerns pushing OS research forward.
Perhaps it is you that are mistaken. In terms of OS research, I'm aware of Singularity and Midori, but these were all flawed projects that were subsequently discontinued.
No, they were projects killed by management, they were only flawed on the eyes of MS haters.
They had a huge impact on .NET AOT compiler for Windows 8, .NET Native for UWP, Linux subsystem, Windows containers and secure kernel. Including asynch/await, .NET TPL, concepts now spread to other languages.
You are missing Drawbdrige, Singularity's sucessor, where pico-processes where researched and are the basis of the Linux subsystem.
Or the P language, a type dependent language, used to write the new USB stack.
And many other findings, easy to track down at their website.
They had a huge impact on .NET AOT compiler for Windows 8, .NET Native for UWP, Linux subsystem, Windows containers and secure kernel. Including asynch/await, .NET TPL, concepts now spread to other languages.
You are missing Drawbdrige, Singularity's sucessor, where pico-processes where researched and are the basis of the Linux subsystem.
Or the P language, a type dependent language, used to write the new USB stack.
And many other findings, easy to track down at their website.
Well, of course they were killed my management. And they were killed because their performance was so bad that it wasn't worth investing additional time, resources and money into. As for the impact of their research on AOT compilers in their runtimes, what exactly did they revolutionize in AOT compiler design or technology that wasn't already known?
Their stuff is not mostly open source.
> Does anyone feel a tinge of guilt using the amazing technology that Google provides?
I do and the same with a few other big company technologies and frameworks. It's not so much the support but more the fact that in the past a single person / small team could make a technology that became a staple of the industry. I always liked that it was one of the few things left that big corporations didn't have a strangle hold upon. Now however it seems that it is no longer the case and all the new frameworks, libraries and other such things are coming out of the big corporations - I guess I just enjoyed supporting the little guys.
I do and the same with a few other big company technologies and frameworks. It's not so much the support but more the fact that in the past a single person / small team could make a technology that became a staple of the industry. I always liked that it was one of the few things left that big corporations didn't have a strangle hold upon. Now however it seems that it is no longer the case and all the new frameworks, libraries and other such things are coming out of the big corporations - I guess I just enjoyed supporting the little guys.
Well I'd argue that the little guys are still plenty powerful in this space. Some of the largest JavaScript libraries we're only a few people (some we're hired by big companies, but they were alone for a long time).
>some we're hired by big companies, but they were alone for a long time
I would imagine they would've been happy with staying alone rather than being managed by a boss, but sadly no one bothers to donate to most projects.
I'm not talking about your average software developer, but large companies that save hundreds of man hours that would've gone into creating and maintaining the projects they use.
I would imagine they would've been happy with staying alone rather than being managed by a boss, but sadly no one bothers to donate to most projects.
I'm not talking about your average software developer, but large companies that save hundreds of man hours that would've gone into creating and maintaining the projects they use.
The platform they run on (web browser) is written by Apple, Microsoft, and Google.
And Mozilla.
But the platform the other tools that the GP is talking about would probably run on an OS, of which I don't think there are many which are written and maintained by small independent teams of a few developers.
Still, I was just pointing out that there are still areas that the major player is an independent developer without any backing. I'd bet that with the ease of publishing in something like NPM it's easier than ever for someone to make a good piece of software and become a dominating force in a niche area than ever before.
But the platform the other tools that the GP is talking about would probably run on an OS, of which I don't think there are many which are written and maintained by small independent teams of a few developers.
Still, I was just pointing out that there are still areas that the major player is an independent developer without any backing. I'd bet that with the ease of publishing in something like NPM it's easier than ever for someone to make a good piece of software and become a dominating force in a niche area than ever before.
> Does anyone feel a tinge of guilt using the amazing technology that Google provides?
Why?
> I think Google is overall a pretty "evil" (I use quotes because the term is loaded, and the reasoning is too long to easily state) company.
I disagree, but even if I didn't why would that make me guilty about using libre technology from them?
Why?
> I think Google is overall a pretty "evil" (I use quotes because the term is loaded, and the reasoning is too long to easily state) company.
I disagree, but even if I didn't why would that make me guilty about using libre technology from them?
> Does anyone feel a tinge of guilt using the amazing technology that Google provides?
I certainly do. I asked this question before, but I get the feeling that most people here just want to take what's good from Google, and still question all their evil doings. I think that's hypocritical.
I certainly do. I asked this question before, but I get the feeling that most people here just want to take what's good from Google, and still question all their evil doings. I think that's hypocritical.
Disclaimer: I work at Google.
I don't see that as hypocritical. I just want the 'good parts' of my relationship with my wife while still being able to criticize her sometimes. I want the useful parts of government while still being allowed to criticize them frequently. It's not that unusual a state, really.
Personally I think it's great that people who use Google's products are still willing to take us to task. User/civic feedback is an important mechanism to keep big companies like Google in line.
I don't see that as hypocritical. I just want the 'good parts' of my relationship with my wife while still being able to criticize her sometimes. I want the useful parts of government while still being allowed to criticize them frequently. It's not that unusual a state, really.
Personally I think it's great that people who use Google's products are still willing to take us to task. User/civic feedback is an important mechanism to keep big companies like Google in line.
> I just want the 'good parts' of my relationship with my wife while still being able to criticize her sometimes.
But I hope you don't take it as an offense when I say that I wouldn't want to be married to the devil, no matter how good looking she is ;)
Also, I'm curious: how do you feel about banking with a financial institution that has a favorable interest rate but trades in weapons of war?
> User/civic feedback is an important mechanism to keep big companies like Google in line.
Sadly, all too often communication with Google is a one way street, from user support questions to ethical issues.
But I hope you don't take it as an offense when I say that I wouldn't want to be married to the devil, no matter how good looking she is ;)
Also, I'm curious: how do you feel about banking with a financial institution that has a favorable interest rate but trades in weapons of war?
> User/civic feedback is an important mechanism to keep big companies like Google in line.
Sadly, all too often communication with Google is a one way street, from user support questions to ethical issues.
> how do you feel about banking with a financial institution that has a favorable interest rate but trades in weapons of war?
Depends, who are they trading with? Our democratic allies? Fine. North Korea? I'd have a problem with that.
That said, I'm not as hostile to big tech companies in general as your average HN commenter, as I see a bunch of advantages in having them around, and things like companies using anonymized user data for ads don't bother me as long as they're handled competently.
Depends, who are they trading with? Our democratic allies? Fine. North Korea? I'd have a problem with that.
That said, I'm not as hostile to big tech companies in general as your average HN commenter, as I see a bunch of advantages in having them around, and things like companies using anonymized user data for ads don't bother me as long as they're handled competently.
No dilemmas on my side.
My approaches are C++ using a MVVM architecture with native views, Xamarin, or just focus on a single platform.
Depending on what I want to implement.
My approaches are C++ using a MVVM architecture with native views, Xamarin, or just focus on a single platform.
Depending on what I want to implement.
>Does anyone feel a tinge of guilt using the amazing technology that Google provides
How's TypeScript working out?
How's TypeScript working out?
Xamarin?
Qt?
Only if you want to have fun writing your own bindings for the majority of OS APIs.
Qt for mobile devices requires the use of QML (not C++ widgets) and many APIs aren't wrapped, or even fit into the OS application lifecycle.
It is easier to use standard C++ and do your own bindings to Java and Objective-C, than QML (one version for each device) + Qt/C++ + wrappers into not support APIs.
Xamarin teams take the effort to create .NET bindings for all new iOS and Android APIs, on each OS release.
Qt for mobile devices requires the use of QML (not C++ widgets) and many APIs aren't wrapped, or even fit into the OS application lifecycle.
It is easier to use standard C++ and do your own bindings to Java and Objective-C, than QML (one version for each device) + Qt/C++ + wrappers into not support APIs.
Xamarin teams take the effort to create .NET bindings for all new iOS and Android APIs, on each OS release.
Not sure what you are referring to here. The benefit of Qt for me is that it wraps more APIs on more OS's than anything else I have come across. You can run your app on Qnx even Windows CE. It's incredible. You write your view in QML and logic in C++ with libraries that are so much saner than e.g. Boost. Then communicate between the two with signals and slots which integrate seamlessly with the dataflow property system. It couldn't be neater from my point of view and I have used a lot of gui frameworks.
From your answer I take you never tried to use Qt across iOS, Android and UWP.
Hint, the overall experience isn't like on the desktop.
Hint, the overall experience isn't like on the desktop.
I like Qt, especially the desktop part. I haven't used QML at all, but started using Flutter. Killer feature in Flutter is sub-second update times preserving the same state app was running as before. Is this doable with QML?
(Juce, a C++ ui framework, has also been a contender, and to a degree Lispworks, possibly others, but these are the ones I'm a bit familiar).
(Juce, a C++ ui framework, has also been a contender, and to a degree Lispworks, possibly others, but these are the ones I'm a bit familiar).
Regardless of which route you take, you’re gonna need to learn the ins and outs of the platforms you’re running on.
Dart? Sorry I'll have to pass. On top of Elixir, Go, and JS fatigue, I don't think I have any more room left for another language to "try".
But if it was Polymer with native iOS/Android support, now then this would've been a different story! When I compare all the recent front-end frameworks, Polymer still is the most appealing to me, I wish it had a bit more steam behind it.
But if it was Polymer with native iOS/Android support, now then this would've been a different story! When I compare all the recent front-end frameworks, Polymer still is the most appealing to me, I wish it had a bit more steam behind it.
Dart is quite similar to Java. If you are already familiar with Java I believe it will take you very little time to get started with Dart.
FWIW, I was able to write two small but useful program in Dart in one day, without any experience with the language at all:
- A script to convert CSV file to SELECT ... UNION ALL SELECT ... statements
- A script to parse my timesheet (in Emacs' org-mode) & insert it into my client's timesheet database
I just used these 3 resources:
[1] Dart language tour https://www.dartlang.org/guides/language
[2] Standard library introduction https://www.dartlang.org/guides/libraries
[3] Standard library reference (like JavaDocs) https://api.dartlang.org/stable/1.24.2/index.html
[4] And the pub package manager https://www.dartlang.org/tools/pub
FWIW, I was able to write two small but useful program in Dart in one day, without any experience with the language at all:
- A script to convert CSV file to SELECT ... UNION ALL SELECT ... statements
- A script to parse my timesheet (in Emacs' org-mode) & insert it into my client's timesheet database
I just used these 3 resources:
[1] Dart language tour https://www.dartlang.org/guides/language
[2] Standard library introduction https://www.dartlang.org/guides/libraries
[3] Standard library reference (like JavaDocs) https://api.dartlang.org/stable/1.24.2/index.html
[4] And the pub package manager https://www.dartlang.org/tools/pub
It's really easy to get started with almost any language, the problem is becoming an expert in it. How can somebody become an expert on the nuances of JS, Typescript, Dart, etc not to mention libraries and APIs of each? And that's just for the frontend.
Polymer with native iOS/Android support would be… Not Polymer.
Polymer is a thin layer of sugar on top of the web platform, it's 100% web, it doesn't make sense outside of the browser because it doesn't have its own special component model, it literally just directly subclasses HTMLElement to provide sugar, that's it.
Polymer is a thin layer of sugar on top of the web platform, it's 100% web, it doesn't make sense outside of the browser because it doesn't have its own special component model, it literally just directly subclasses HTMLElement to provide sugar, that's it.
> Dart? [...] JS fatigue
I think you might like working with Dart. The entire ecosystem is standardized. And if you do Flutter stuff, Flutter is the only framework.
Learning the language isn't a big deal. You already know most of the syntax and its semantics are straightforward.
You can try doing some Hello World stuff over at DartPad:
https://dartpad.dartlang.org/
I think you might like working with Dart. The entire ecosystem is standardized. And if you do Flutter stuff, Flutter is the only framework.
Learning the language isn't a big deal. You already know most of the syntax and its semantics are straightforward.
You can try doing some Hello World stuff over at DartPad:
https://dartpad.dartlang.org/
Google IO sessions sometimes feel a bit schizophrenic, if you watch all tracks, you will see Android, Web and Flutter teams kind of taking jabs at each other about the right way of doing apps.
I love Polymer too, but if you are like me the parts you like most about Polymer are the beautiful widgets and the ability to create new widgets. Flutter provides that for mobile apps. As someone else said, Polymer itself is just a web implementation of user-defined HTML elements and makes no sense for mobile apps.
As for not wanting to learn Dart, if you are currently developing mobile apps for one platform (say Android) and you want to port your apps to the other platform (say iOS) then unless you already know the languages and libraries used by that other platform (say Swift or Objective-C) then you already have to learn a new language. Wouldn't it be better to learn something like Dart that compiles natively on both platforms? Then you can just write one program. In particular, maintenance is much easier.
(disclaimer, I like Flutter so much I just joined the Flutter team)
As for not wanting to learn Dart, if you are currently developing mobile apps for one platform (say Android) and you want to port your apps to the other platform (say iOS) then unless you already know the languages and libraries used by that other platform (say Swift or Objective-C) then you already have to learn a new language. Wouldn't it be better to learn something like Dart that compiles natively on both platforms? Then you can just write one program. In particular, maintenance is much easier.
(disclaimer, I like Flutter so much I just joined the Flutter team)
Dart is Java/C# like - you will be fluent in one day
I understand where you are coming from - however, Dart is super easy to start using, you will feel at home in no time. Solid, though-out standard library, everything just works out of the box. Honestly, it's a very refreshing experience compared to JS / TypeScript. I bet you'll love it after a day or two.
I think learning a new language is more acceptable when you're also using it on a new platform. I was sceptical about picking up Swift, but I was up and running within a few hours.
> On top of Elixir, Go, and JS fatigue, I don't think I have any more room left for another language to "try".
Not to mention Elm.
Not to mention Elm.
[deleted]
It is very exciting to see more people write frameworks using "React" ideas. This will make React and similar frameworks better!
It seems like one of the biggest ideas that flutter brings to the table is a different approach to component libraries. It makes sense that there is a need for this given that larger companies that invest in React tend to have their own tailored component library that people outside of those companies generally don't get to take advantage of. The startup costs to developing your own library of React components and their CSS/Native wrappers are high.
That being said, when I think of prebuilt component libraries (eg, bootstrap, swing) I generally think of components that are too familiar for users and a crutch for developers to allow them to quickly develop interface code where they may not be an expert. In a high quality app, I would expect widgets to follow the patterns that other apps on the platform follow. Won't this be difficult for a framework like Flutter which will have to re-create each of these native widgets (as apposed to React native where they are just wrapped in a JS layer)?
Regardless of these qualms, I'm excited to see more well funded frameworks enter this space because I'm sure that all users of frameworks in this space will benefit. I will be on the look out for more complex uses of this framework to see how people overcome these types of issues!
It seems like one of the biggest ideas that flutter brings to the table is a different approach to component libraries. It makes sense that there is a need for this given that larger companies that invest in React tend to have their own tailored component library that people outside of those companies generally don't get to take advantage of. The startup costs to developing your own library of React components and their CSS/Native wrappers are high.
That being said, when I think of prebuilt component libraries (eg, bootstrap, swing) I generally think of components that are too familiar for users and a crutch for developers to allow them to quickly develop interface code where they may not be an expert. In a high quality app, I would expect widgets to follow the patterns that other apps on the platform follow. Won't this be difficult for a framework like Flutter which will have to re-create each of these native widgets (as apposed to React native where they are just wrapped in a JS layer)?
Regardless of these qualms, I'm excited to see more well funded frameworks enter this space because I'm sure that all users of frameworks in this space will benefit. I will be on the look out for more complex uses of this framework to see how people overcome these types of issues!
The biggest problem with Flutter is that of developer reluctance - primarily because of Dart. And ever more so now because Android adopted a small, scrappy company's homegrown language (Kotlin) instead of Google's own.
I'm kind of wondering what are the political fault lines inside Google around the Dart, Flutter and Android ecosystem.
If Kotlin gets adopted server side at Google as well (which is fairly likely considering Google is already using the JVM), then why would people bet on Dart ?
Is Dart 10x better than Kotlin ?
I'm kind of wondering what are the political fault lines inside Google around the Dart, Flutter and Android ecosystem.
If Kotlin gets adopted server side at Google as well (which is fairly likely considering Google is already using the JVM), then why would people bet on Dart ?
Is Dart 10x better than Kotlin ?
> Is Dart 10x better than Kotlin
For many, it is. The consistency and the well-thought out API and syntax is a huge boost, and while they have similar roots, Dart is much better in these regards. Disclaimer: developed in Kotlin only for a few months, did a lot more in Dart.
I encourage you to try it and evaluate it for yourself. Your speculation about the politics in- or outside Google are just that: speculations, while a fair evaluation shows way more nuanced view of what is better and what has better chances in the long term.
For many, it is. The consistency and the well-thought out API and syntax is a huge boost, and while they have similar roots, Dart is much better in these regards. Disclaimer: developed in Kotlin only for a few months, did a lot more in Dart.
I encourage you to try it and evaluate it for yourself. Your speculation about the politics in- or outside Google are just that: speculations, while a fair evaluation shows way more nuanced view of what is better and what has better chances in the long term.
Search trend comparison of Dart vs Kotlin vs React Native:
https://trends.google.com/trends/explore?q=%2Fm%2F0h52xr1,%2...
Interesting that there's heavy kotlin searching mainly in Russia
https://trends.google.com/trends/explore?q=%2Fm%2F0h52xr1,%2...
Interesting that there's heavy kotlin searching mainly in Russia
Not really that surprising to me, Kotlin is named after a Russian island, so naturally their non-developer populace will use the term more than the rest of the world and the programming language was created by JetBrains, a Russian company, so I'd also assume there's probably some elevated interest for Russians in something successful that's also "home grown".
Technically, JetBrains is a Czech company with offices in Russia, among a half dozen or so counties.
Kotlin is the name of an island in Russia.
> So they can look like iOS native widgets or Android native widgets. This is basically the exact same approach as JavaSwing.
Hang on, he's saying it's like Java Swing as if that's a good thing?
Hang on, he's saying it's like Java Swing as if that's a good thing?
Anyone that bothered to read "Filthy Rich Clients" or followed the respective Sun blog, knows how to take advantage of Swing APIs and make it a Good Thing.
Not to mention that I rather do Swing than web development, if given the option.
Not to mention that I rather do Swing than web development, if given the option.
This has come up several times. I had to buy a used copy to check it out.
Compared to the entire JS world of UI frameworks that come bundled with a 200M "runtime" for desktop applications? Yes, yes it definitely is a good thing.
How big is the Android runtime?
For comparison, the entire JVM for Desktop, including Swing, AWT, Themes, JavaFX, the entire stdlib, three separate optimizing JITs, profilers, graphical tracers, etc, combined, is below 64MB.
The entire Android OS, every part of it, including all toolings required to build apps, is still below 200MiB. This includes libraries, default apps, UI, compilers, tools, stdlib, firmware, etc.
The entire Android OS, every part of it, including all toolings required to build apps, is still below 200MiB. This includes libraries, default apps, UI, compilers, tools, stdlib, firmware, etc.
And a browser?
My point is that if Electron was provided by default just like .NET or one of the apple frameworks you would not mind it that much and you will think apps built with it are lean when in fact to create a UI rich standalone executable you will require a lot of things to get up and running.
My point is that if Electron was provided by default just like .NET or one of the apple frameworks you would not mind it that much and you will think apps built with it are lean when in fact to create a UI rich standalone executable you will require a lot of things to get up and running.
PalmOS, FirefoxOS, ChromeOS are good examples how those rich UIs actually are in regard to UI/UX.
Probably bigger, but it is already installed.
Unless you meant the Flutter runtime? It's about 6 MB apparently.
Unless you meant the Flutter runtime? It's about 6 MB apparently.
Back in the days I was against frameworks not using native widgets. So I tend to use wxWidgets where I can (say instead of MFC). I shied away from Qt only for that petty reason. I'm not visually/hearing impaired, but thought for a long time that unless you use the native widgets, your apps won't be accessible to people with such conditions. So maybe I was half-right, but then I've found out that Windows provides API for one to expose widget contents in a way that the system can assist with reading the text, enhancing this and that, etc.
Same with Eclipse, which relies on native toolkit, vs. Swing.
But then if you compare Eclipse and IntelliJ - the difference is huge. Eclipse is clumsy, the widgets even though they are supposed to be native - somehow look baroque, oversized, while in IntelliJ/CLion things can be customized (Darcula+font settings) and look pretty sweet.
Same with Qt. With good stylesheet you can make an artist, a game scriptor, or level builder happy. They won't even care that you haven't used the native toolkit.
Then as it goes, it's more easier to expose/subclass/customize non-native toolkit compared to native, or even native which was wrapping internal widgets and exposing them other way. In a previous company I worked, we ported our game level editor (Radiant) from MFC -> Qt and saw burst of development going on, as people from all backgrounds were able to add more things in the UI. Collaboration was thriving, while with MFC you had to spent years learning how to do bits and pieces. Same with wxWidgets btw, as we also used in projects.
And at last, some rather specific story about wxWidgets on Windows - I think we had an editor, or a launcher of sorts, and it was tracking/showing log of operations. If you wanted to jump/search to a line it was rather slow, and limited... Turns out wxWidgets on Windows would use some native control, and the implementation of "give me the current line" in the editor would scan the log from begining to end, counting all \n\r, until it came to your buffer position and tell you the number. The GTK version, which someone else used for other tool did not had this problem... TL'DR'... Leaky Abstraction!
nuff' with ranting...
Same with Eclipse, which relies on native toolkit, vs. Swing.
But then if you compare Eclipse and IntelliJ - the difference is huge. Eclipse is clumsy, the widgets even though they are supposed to be native - somehow look baroque, oversized, while in IntelliJ/CLion things can be customized (Darcula+font settings) and look pretty sweet.
Same with Qt. With good stylesheet you can make an artist, a game scriptor, or level builder happy. They won't even care that you haven't used the native toolkit.
Then as it goes, it's more easier to expose/subclass/customize non-native toolkit compared to native, or even native which was wrapping internal widgets and exposing them other way. In a previous company I worked, we ported our game level editor (Radiant) from MFC -> Qt and saw burst of development going on, as people from all backgrounds were able to add more things in the UI. Collaboration was thriving, while with MFC you had to spent years learning how to do bits and pieces. Same with wxWidgets btw, as we also used in projects.
And at last, some rather specific story about wxWidgets on Windows - I think we had an editor, or a launcher of sorts, and it was tracking/showing log of operations. If you wanted to jump/search to a line it was rather slow, and limited... Turns out wxWidgets on Windows would use some native control, and the implementation of "give me the current line" in the editor would scan the log from begining to end, counting all \n\r, until it came to your buffer position and tell you the number. The GTK version, which someone else used for other tool did not had this problem... TL'DR'... Leaky Abstraction!
nuff' with ranting...
I did four years of Swing development and while it has it's difficulties, it was possible to deliver on every feature the client required. It was flexible and (if you pay attention) performant as well.
It can be difficult to find the right place to insert your code to get what you want done, but that's the case with most UI toolkits. The easy stuff is easy and the custom stuff can be a real headache.
It can be difficult to find the right place to insert your code to get what you want done, but that's the case with most UI toolkits. The easy stuff is easy and the custom stuff can be a real headache.
Yeah, funny, isn't it?
I wish we had a variation of Deplhi's VCL for web/java/etc. instead of all these monstrosities that make life miserable instead of taking 5 minutes to make a solid UI.
I wish we had a variation of Deplhi's VCL for web/java/etc. instead of all these monstrosities that make life miserable instead of taking 5 minutes to make a solid UI.
Can you elaborate on which part of Delphi's VCL you are looking for?
For real. Cakewalk to do these sort of "responsive" applications in Swing, and Swing is hardly the most elegant native GUI framework (though well known).
If you ignore the look-and-feel and performance of Swing and just work with the API, Swing is pretty awesome.
Link: https://flutter.io/
The floating 'open in app' on this page is really bad. Please stop doing that. For fucking crying loud, don't mix text with bullshit.
It looks fantastic, but with Google I always wonder about their long term commitment to stuff like this.
Well, they state that they are using it in their own production apps. They did the same with Angular from basically day 1. And it started as a 20% project for Igor(sorry if I'm remembering that wrong). Nearly seven years later and here we are at Angular 3, I'm sorry 4. It all depends on adoption.
>Well, they state that they are using it in their own production apps. They did the same with Angular from basically day 1.
This reminds me of a question I've had before: exactly what production apps does Google use Angular for? Have they rewritten Gmail to use Angular? Or Calendar? Or Docs? I'm too lazy to dig into the obfuscated source of any of these to figure it out for myself. Does anyone know what apps Google actually uses Angular for?
This reminds me of a question I've had before: exactly what production apps does Google use Angular for? Have they rewritten Gmail to use Angular? Or Calendar? Or Docs? I'm too lazy to dig into the obfuscated source of any of these to figure it out for myself. Does anyone know what apps Google actually uses Angular for?
I can answer this for AngularDart. That one is used for AdWords, AdSense, AdMob — these 3 alone bring 75%+ of Google's revenue —, a company-wide CRM, Fiber, Shopping Express, Wing, ...
No Gmail, Calendar, Docs, or any other consumer app so far.
Disclaimer: I work on the Dart team.
No Gmail, Calendar, Docs, or any other consumer app so far.
Disclaimer: I work on the Dart team.
Aren't those the same apps that claim to use GWT?
> It all depends on adoption.
That sounds about right. I guess the conservative approach would be to wait and see if it gains any traction.
That sounds about right. I guess the conservative approach would be to wait and see if it gains any traction.
in which prod app are they using it ?
One month ago a flutter member told me it was only used for internal apps at the moment.
One month ago a flutter member told me it was only used for internal apps at the moment.
Is Flutter tied to Dart, or are there good C bindings so I can use whatever language I want?
I've never understood the obsession with creating a whole language around a library (R, Matlab, Magma, Javascript, Wolfram...) so that I'm essentially forced to use that.
I've never understood the obsession with creating a whole language around a library (R, Matlab, Magma, Javascript, Wolfram...) so that I'm essentially forced to use that.
Bravo, you just discovered how language adoption works.
Also as an addendum, C is a language designed around an operating system.
If it wasn't for UNIX's adoption, C would have been a footnote in the history of systems programming languages.
Also as an addendum, C is a language designed around an operating system.
If it wasn't for UNIX's adoption, C would have been a footnote in the history of systems programming languages.
Well, yeah, but wouldn't you agree this is a sad state?
Also, C as a "portable assembler" kind of make sense as a lingua franka, because every language has to go through assembler before being executed at some point.
Also, C as a "portable assembler" kind of make sense as a lingua franka, because every language has to go through assembler before being executed at some point.
No, because adoption needs to be driven by an actual need of some sort.
A programming language doesn't get adopted just for its grammar and semantics alone.
Regarding the benefits of C as portable Assembly, I advise you read about the programming languages and operating systems designed in the 60's, 10 years before UNIX was created.
A programming language doesn't get adopted just for its grammar and semantics alone.
Regarding the benefits of C as portable Assembly, I advise you read about the programming languages and operating systems designed in the 60's, 10 years before UNIX was created.
Any idea when this will be in beta? That looks way more interesting than React Native to me.
While it's labeled alpha, AFAIK it's fully available for public use and it's fairly functional.
Functional but fairly buggy still. For example it misses a lot of button taps because there is a universal move threshold of about 2mm. And if you want to do anything other than display widgets in the app (e.g. display notifications), you're going to have to write a plugin for it.
Performances are really far off still.
120 fps ? it can't do 30 at the moment.
(and fps is a pretty awful metric on mobile, what matters is the number of frame dropped)
(and fps is a pretty awful metric on mobile, what matters is the number of frame dropped)
Looks very nice. Any indications that is or will be possible to make non mobile apps? Or that it will have bindings to other languages?
Dart is a huge step up from JS, but I can see how other languages would be a nice fit too.
Dart is a huge step up from JS, but I can see how other languages would be a nice fit too.
My first problem with Flutter is that it doesn't unify web and native development, so it fails to solve the big problem immediately. If you can deliver web and mobile from the same codebase, you can deal with the "long tail" of users (and web users too). React Native (not that I have any great love of React) and its clones are working towards supporting all platforms.
My second problem with Flutter is the writer's apparent biggest positive feature — Dart. (I love how he naively states that Dart was conceived as a language to transpile to Javascript; it was conceived as a replacement for Javascript with transpilation as a stopgap.) I think Javascript is a fine ("good enough") language that (a) works almost everywhere and (b) is evolving at a more-than-sufficient rate. I have no desire to drink Google's Kool-aid. (Go, OTOH, I am fine with.)
But then I get to "Building Layouts with Flutter":
https://flutter.io/tutorials/layout/#step-1
This makes the articles I've read on "thinking the React way" seem mild in comparison. In exchange for having to restrict your layout ideas to the stuff that will work in Flutter (which first entails somehow grokking what works in Flutter), you have to go from visual concept to hierarchical breakdown and then translate that into code in less than intuitive ways, and then when your graphic designer decides that such-and-such needs to be 2 pixels lower or the stars should get bigger in the middle, you're still going to be hosed or inserting fixed height shims all over the place (and how will that look on a tablet?)
This API seems too high level to produce polished products. Of course it's alpha so blah blah blah but being able to quickly produce generic stuff is not a proof of concept, especially if you can't then refine the generic stuff to the nth degree.
My second problem with Flutter is the writer's apparent biggest positive feature — Dart. (I love how he naively states that Dart was conceived as a language to transpile to Javascript; it was conceived as a replacement for Javascript with transpilation as a stopgap.) I think Javascript is a fine ("good enough") language that (a) works almost everywhere and (b) is evolving at a more-than-sufficient rate. I have no desire to drink Google's Kool-aid. (Go, OTOH, I am fine with.)
But then I get to "Building Layouts with Flutter":
https://flutter.io/tutorials/layout/#step-1
This makes the articles I've read on "thinking the React way" seem mild in comparison. In exchange for having to restrict your layout ideas to the stuff that will work in Flutter (which first entails somehow grokking what works in Flutter), you have to go from visual concept to hierarchical breakdown and then translate that into code in less than intuitive ways, and then when your graphic designer decides that such-and-such needs to be 2 pixels lower or the stars should get bigger in the middle, you're still going to be hosed or inserting fixed height shims all over the place (and how will that look on a tablet?)
This API seems too high level to produce polished products. Of course it's alpha so blah blah blah but being able to quickly produce generic stuff is not a proof of concept, especially if you can't then refine the generic stuff to the nth degree.
(I work on the Flutter team.)
> This API seems too high level to produce polished products.
You can target whichever level of Flutter's APIs that you want. Almost the entire stack is in Dart, from the compositor, to the layout engine, to the animation logic, to the composition (widgets) layer, to the material widgets. If one layer is too high level, you can go down one level and work directly there instead.
The lowest level (the C++ layer) is literally just the Skia API, the Dart core APIs, a text rendering API, and a message-passing API for talking to your Java/Kotlin or ObjectiveC/Swift code. Everything else is layers you can directly poke at from Dart, written in Dart.
> This API seems too high level to produce polished products.
You can target whichever level of Flutter's APIs that you want. Almost the entire stack is in Dart, from the compositor, to the layout engine, to the animation logic, to the composition (widgets) layer, to the material widgets. If one layer is too high level, you can go down one level and work directly there instead.
The lowest level (the C++ layer) is literally just the Skia API, the Dart core APIs, a text rendering API, and a message-passing API for talking to your Java/Kotlin or ObjectiveC/Swift code. Everything else is layers you can directly poke at from Dart, written in Dart.
Thanks for addressing this specific issue (and hey, Hixie!) Obviously, I don't know much about the APIs so I'll take your word for it.
I guess my first objection (doesn't unify web development) stands, but that can be addressed in future (and presemably Dart will work just dandy with Web Assembly).
I assume my other objection can be addressed by simply building layouts directly and not using the autolayout stuff if you don't want.
I guess my first objection (doesn't unify web development) stands, but that can be addressed in future (and presemably Dart will work just dandy with Web Assembly).
I assume my other objection can be addressed by simply building layouts directly and not using the autolayout stuff if you don't want.
Concerning your point about graphic designers, I recommend that people watch this talk about a designer and programmer working on a Flutter project -- https://youtu.be/BJCqRpvvTrM
One last comment about Dart. If you want to see the big benefit of Dart yourself, just go start up the sample Flutter app, modify it and do a (stateful) hot reload. Or introduce an error on purpose, and see how you can fix the error and then continue on from the same place in less than a second. The normal response I've seen from people who try this is to exclaim that this "is a game changer".
[disclaimer: I liked Flutter so much I recently joined that project]
One last comment about Dart. If you want to see the big benefit of Dart yourself, just go start up the sample Flutter app, modify it and do a (stateful) hot reload. Or introduce an error on purpose, and see how you can fix the error and then continue on from the same place in less than a second. The normal response I've seen from people who try this is to exclaim that this "is a game changer".
[disclaimer: I liked Flutter so much I recently joined that project]
> I liked Flutter so much I recently joined that project
How can you do that?
How can you do that?
Finally a cross platform framework that makes sense! Writing your own UI elements using the platforms graphics primitives makes a lot of sense.
It will be interesting to see how it works in practice.
It will be interesting to see how it works in practice.
My years of toil with Java Swing makes me shudder every time i hear its wretched name.
I wonder about accessibility of flutter widgets though, since they aren't just wrappers for native widgets.
Looks like it's still not accessible https://github.com/flutter/flutter/issues/10562 The issue was brought up a year ago too https://groups.google.com/forum/m/#!topic/flutter-dev/xwUJ7D...
Looks like it's still not accessible https://github.com/flutter/flutter/issues/10562 The issue was brought up a year ago too https://groups.google.com/forum/m/#!topic/flutter-dev/xwUJ7D...
Adam Barth from the flutter team responded last time this came up:
https://news.ycombinator.com/item?id=14433320
https://news.ycombinator.com/item?id=14433320
(I'm on the Flutter team)
We're actively working on accessibility right now. It's one of our top priorities for the next few months.
We're actively working on accessibility right now. It's one of our top priorities for the next few months.
> There are no external UI DSLs (i.e. html or xml files).
> The entire UI is written in Dart. This, for me, is a
> big win.
This view amuses me. It is obviously held as an opinion, and isn't one I disagree with; but goes heavily against what everyone was aiming for with the likes of HTML. To the point that it is kind of hard to believe I'm seeing it.
I give it about 4 months before there is a UI language that is not "code" that is usable here. Pushed by the other side.
This view amuses me. It is obviously held as an opinion, and isn't one I disagree with; but goes heavily against what everyone was aiming for with the likes of HTML. To the point that it is kind of hard to believe I'm seeing it.
I give it about 4 months before there is a UI language that is not "code" that is usable here. Pushed by the other side.
HTML was designed to create documents, though - not UIs. That also happens to be the core of a lot of problems with it (that, IMO, are overblown).
A lot of the struggle/difference between JS frameworks is this disagreement about where things fit on the document vs app scale, IMO.
A lot of the struggle/difference between JS frameworks is this disagreement about where things fit on the document vs app scale, IMO.
And to an extent, I fully get what you are saying. However, the entire push of HTML/CSS is not much different than the push of LaTeX over TeX. Or any number of other examples. (You can almost draw the line at people wanting a fully declarative language for content being the problem. I'm sympathetic to that view. I haven't explored it enough, yet.) People want to find a very hard separation of presentation from content.
And to an extent, this makes sense. However, ditching HTML and similar tech seems excessive to me. The largest problem with HTML is so many people try to appease the flow and native layout of the elements. This leads to a massive bloat of markup to create what is actually easy to describe using minimal markup and liberal usage of absolute/relative positioning.
And to an extent, this makes sense. However, ditching HTML and similar tech seems excessive to me. The largest problem with HTML is so many people try to appease the flow and native layout of the elements. This leads to a massive bloat of markup to create what is actually easy to describe using minimal markup and liberal usage of absolute/relative positioning.
> React Native uses native widgets. This means you have to create separate apps for Android and iOS.
I've never used any native widgets in React Native. Didn't even know they existed. I create and style all widgets I want from scratch so they obviously look the same on both Android and iOS. I thought that was how everyone did it. What am I missing?
I've never used any native widgets in React Native. Didn't even know they existed. I create and style all widgets I want from scratch so they obviously look the same on both Android and iOS. I thought that was how everyone did it. What am I missing?
All of the built-in React Native components are wrappers around the corresponding native widgets: https://facebook.github.io/react-native/docs/components-and-...
You can also integrate other native widgets not designed first and foremost for React Native https://facebook.github.io/react-native/docs/native-componen...
You can also integrate other native widgets not designed first and foremost for React Native https://facebook.github.io/react-native/docs/native-componen...
Thanks. What's the benefit of using the built-in Button component? The only reason I could see is that you actually want them to look differently on Android and iOS. I've heard the sentiment before but I don't fully understand it. For example, when I build an app I want it to look like my app, with its own distinct graphics, and not like a generic system app. Why go through the hassle of making two different UIs when you can just go with your own?
Games and apps like Snapchat can go that route, making the user learn a completely different UI. But for practically every other app type, going with a new UI and discarding the platform defaults for navigation, buttons, etc. is only going to hurt you in the long run, both from a user perspective (no one has the patience to learn a new UI with every app), and from a effort standpoiont (it takes way longer to develop your own UI than it does sticking with platform defaults).
That has been my experience at least, every time we changed something from "our" way to a more default platform way, we've seen better metrics and retention across the board. We even try to avoid platform specific things like swipe to delete etc., because the general user does not use those features, even if you "teach" them in the onboarding.
This doesn't mean that you shouldn't style your app etc to give it an identity, and there's actually a lot of room you have even when sticking to default elements.
That has been my experience at least, every time we changed something from "our" way to a more default platform way, we've seen better metrics and retention across the board. We even try to avoid platform specific things like swipe to delete etc., because the general user does not use those features, even if you "teach" them in the onboarding.
This doesn't mean that you shouldn't style your app etc to give it an identity, and there's actually a lot of room you have even when sticking to default elements.
Accessibility is a big one. When your buttons are actual UIButtons, they get treated as such by the iOS accessibility system.
Most developers don't consider accessibility at all because they don't need it themselves. But there are millions of iOS and Android users who do need it, and they might be thankful that you've made their life easier with your app.
Following platform standards makes things easier for users. Users don't care if your app has distinct graphics.
Most developers don't consider accessibility at all because they don't need it themselves. But there are millions of iOS and Android users who do need it, and they might be thankful that you've made their life easier with your app.
Following platform standards makes things easier for users. Users don't care if your app has distinct graphics.
Thanks. Is that's really what's happening with React Native's built-in button though?
https://github.com/facebook/react-native/blob/master/Librari...
https://github.com/facebook/react-native/blob/master/Librari...
if (color && Platform.OS === 'ios') {
textStyles.push({color: color});
} else if (color) {
buttonStyles.push({backgroundColor: color});
}
Sorry, I don't know how React Native does it, although my understanding is that Button components do end up as real platform buttons.
Generally speaking, UIButtons have important semantics that are easy to miss if one just reproduces the appearance using custom graphics. The same applies to other standard controls too.
Generally speaking, UIButtons have important semantics that are easy to miss if one just reproduces the appearance using custom graphics. The same applies to other standard controls too.
> when I build an app I want it to look like my app, with its own distinct graphics, and not like a generic system app. Why go through the hassle of making two different UIs when you can just go with your own
As a user, I don't want your app to look different from all my other apps. Your app is not special enough (probably). Why go through he hassle of dealing with widgets that look and behave differently all the time, when you can just find a different app that doesn't do that?
Now, I'm not saying that everyone is going to be that irked by it... but it's definitely not an unpopular sentiment.
As a user, I don't want your app to look different from all my other apps. Your app is not special enough (probably). Why go through he hassle of dealing with widgets that look and behave differently all the time, when you can just find a different app that doesn't do that?
Now, I'm not saying that everyone is going to be that irked by it... but it's definitely not an unpopular sentiment.
You have a point but then my whole app will need to look generic. As soon as I add my own elements I will need to start thinking "how will it look with Android button vs iOS button". It's much easier to just add my own button.
I don't think anyone will have a hard time understanding how to press a button just because it looks different than system default.
I don't think anyone will have a hard time understanding how to press a button just because it looks different than system default.
It depends. Have you ever sat down with an older person and tried to explain to them how tablets work, with them having minimal prior experience with desktop PCs? Of course, that might not be your target audience in any case...
But for the most part, it's not about the difficulty. It's just an eyesore. Kinda like that one house in the neighborhood that has bright red fences, when everyone else has green. It might even be a very pretty bright red, but...
But for the most part, it's not about the difficulty. It's just an eyesore. Kinda like that one house in the neighborhood that has bright red fences, when everyone else has green. It might even be a very pretty bright red, but...
[deleted]
There are "few" components that needs platform specific implementations in React Native. But I've never had to create separate projects entirely - just add some build tweaks.
> I create and style all widgets I want from scratch
This is what I hate about React Native. I don't like the custom boilerplate that goes into every new project. But NativeBase kind of solves this problems - to some extent. Using standard React Native components is like using raw HTML without a CSS framework
> I create and style all widgets I want from scratch
This is what I hate about React Native. I don't like the custom boilerplate that goes into every new project. But NativeBase kind of solves this problems - to some extent. Using standard React Native components is like using raw HTML without a CSS framework
> so they obviously look the same on both Android and iOS
I'm going to be a bit pedantic with this one: this is valid to some extent. You might want to make small adjustments to accommodate for platform UX paradigms - slightly different icons, relying (or not) on the hardware back button, etc...
I'm going to be a bit pedantic with this one: this is valid to some extent. You might want to make small adjustments to accommodate for platform UX paradigms - slightly different icons, relying (or not) on the hardware back button, etc...
Or even bigger things like size of buttons. iOS and Android have different default sizes of touch targets.
Most notably, touch targets seem smaller by default on iOS which makes ported designs then problematic on Android because all buttons are too small and hard to hit.
Most notably, touch targets seem smaller by default on iOS which makes ported designs then problematic on Android because all buttons are too small and hard to hit.
Something i don't get : does this mean the flutter team will have to redevelop all the gui features and new components of every single new version of cocoa touch, every year, within the timeframe of the beta and the actual release of the new sdk ? And do the same with android sdk ?
Or, will you end up with old looking interfaces and wait anxiously for someone to update the gui component library ?
Because except for creating its own ui paradigm, that will look different from both ios and android, i don't see another option.
Or, will you end up with old looking interfaces and wait anxiously for someone to update the gui component library ?
Because except for creating its own ui paradigm, that will look different from both ios and android, i don't see another option.
At this point we should probably make a framework for implementing the native features in these systems, so the next Cordova/Ionic/Xamarin/React Native/Flutter doesn't have to start from scratch every time and take 2 years to re-build nearly the exact same ecosystem for native features.
As a plus we could consolidate all that brainpower spread across different cross platform native feature libraries to make these native features less buggy, more featureful and more maintained.
As a plus we could consolidate all that brainpower spread across different cross platform native feature libraries to make these native features less buggy, more featureful and more maintained.
how's flutter's interop with java/kotlin/swift/etc? Would I be able to use existing libraries from those lang.s?
AFAIK : not at all :(
On Android, Flutter uses its own C++ runtime totally separate from the Android framework.
hm... is it something like IPC? By 'message passing', would it be ok to use a java image-processing/video-processing library?
(I'm on the Flutter team.)
IPC is "inter-process communication". This message passing is same-process.
We haven't yet proved that it's sufficiently performant for extremely latency-sensitive work, and we currently copy the bytes for the messages when switching so it's not very suitable for high-bandwidth work like video where you're sharing the bytes between Dart and Java.
IPC is "inter-process communication". This message passing is same-process.
We haven't yet proved that it's sufficiently performant for extremely latency-sensitive work, and we currently copy the bytes for the messages when switching so it's not very suitable for high-bandwidth work like video where you're sharing the bytes between Dart and Java.
A lot of the praises of Flutter in the article can be said about Tk. I guess I ought to have a look.
The title led me to believe this is about a java.awt.geom and Swing port to Android.
Right now the weak point of Flutter is that there aren't many plugins for utilizing platform specific features. This always the fault line with these cross-platform frameworks. These will come I'm sure of. It's relatively easy to write a plugin which is a great plus.
I've done native development on both Android and iOS. Tried Cordova-based development. Lastly React Native. Out of all these I like Flutter the most. You will make a beautiful app with much less work compared to native development and other alternatives. The performance is also fantastic. Flutter uses its own high-performance rendering engine to draw widgets. Almost the entirety of Flutter is written in Dart; also the lower parts. This is important for development because nothing is closed off. With everything being written in Dart it gives you a high degree of control.
My early work so far using Flutter;
https://play.google.com/store/apps/details?id=org.me.tvligen... (Danish television listings)
https://play.google.com/store/apps/details?id=dk.kjeldsen.et... (Ethereum blockchain explorer)