I can't speak for Jetpack, but as far as Flutter goes: Flutter is open source, we do all our work in the open. File a bug; we look at all our incoming bugs and there are members of the Flutter team (volunteers as well as people from Nevercode and Google) who try to reproduce each issue. We don't always have the bandwidth to fix everything, but last year we fixed roughly as many bugs as were filed, so the odds are pretty good. (And of course you're welcome to try to fix the bug yourself, we accept PRs from anyone, not just Googlers. See our contributor guide on GitHub.)
We don't have an official foundation, but we are already operating more or less as openly as we would if we did. We have contributions from lots of companies and volunteers; the majority of the people who have contributor access in fact aren't from the Google Flutter team.
Many of the lessons we learn with GPay directly fed into improvements in the framework, improvements in our tooling to make this kind of debugging much easier, and better documentation to try to scale the knowledge to the whole community. Some of these have already shipped (see e.g. new features in our DevTools) and much more will continue to deploy over the coming months.
We actually did try that as our first approach, but it really didn't give you the flexibility that Flutter developers expect.
As the erstwhile editor of the HTML standard for ~10 years and the now TL of Flutter I must admit that it's weird to be creating a web framework that completely ignores all the HTML stuff I worked on before. :-)
That said, Flutter is different from Flash in some important ways. Flash used the NPAPI to "break out" of the web and was basically "native" code you could escape to, whereas Flutter really is using web APIs, like Wasm, ARIA, WebGL, JS, WebComponents, and so on, to create true web apps that just happen to not use much of the control set that HTML exposes.
I suspect that even outside of Flutter, the web in general is going to move towards this kind of framework in the coming years. It just gives you so much more control. It's basically how every other platform works -- pick your language, compile to machine code, don't need to be limited to what HTML and CSS (etc) enable.
Not really. They were not portable. NPAPI was not a web standard in any meaningful sense (hint: the first N stood for Netscape).
> That's why there has never been a UI toolkit as successful as the web.
The web's success in terms of active users and in terms of deployed content is astounding, certainly. I think I'm relatively well placed to understand why, and I don't think it's because the web restricted developers to one scripting language or one set of controls. I think it is very much _despite_ that.
Really not fair to compare against flash in this way when wasm wasn’t available and npapi was the only option. That is additionally an implementation detail, Adobe could (theoretically) revive and port flash to wasm today without breaking the majority of applications.
So this is already a pretty toasty section of comments so let me put this to you. If you've already answered this elsewhere, please let me know.
I would be surprised if someone heavily involved in the Web's development process for a long time didn't have some really sore spots about it.
That aside:
--
What do you think of the loss of opportunities for learning and customization that moving to an opaque system running "in" the web (flutter) implies?
How did you get into the Web? Was being able to easily inspect and change what was happening in apps you didn't have intentional source access for (web pages/apps) not key to that?
Have you gotten value from the ability to quickly use others' extensions of useragent behavior that seem highly unlikely to work with this approach? Or will they be able to?
Fairly loaded questions I guess, but realistic ones too, not just philosophical.
> Was being able to easily inspect and change what was happening in apps you didn't have intentional source access for (web pages/apps) not key to that?
I got into web design/programming in the 90s, and the answer is basically no. Sure you could poke around a bit, but I never found it to be a revelation. I still had to buy books, read blogs, and do a ton of trial and error. Also, it was a never-ending game of trying to testing to see what each new browser release added or broke.
> What do you think of the loss of opportunities for learning and customization that moving to an opaque system running "in" the web (flutter) implies?
Not sure what you really mean. If you mean the loss of "View Source" then I think we lost that a long time ago for anything but the most trivial of pages.
I used to say that view source was why the web was successful, and maybe it did help at the start, but I think we sailed past the point where view source stopped being useful years ago. Everything now is minified, and sites are too complicated for anyone to pick out what's going on from the original source let alone the actual served source...
> How did you get into the Web? Was being able to easily inspect and change what was happening in apps you didn't have intentional source access for (web pages/apps) not key to that?
I'm a weird case, I got into the web by reading the standards. (Then I got annoyed the browsers didn't follow them, so I got into browser QA. Then I got annoyed that the standards weren't clear enough to allow test cases to be written, and I started editing the specs.)
> Have you gotten value from the ability to quickly use others' extensions of useragent behavior that seem highly unlikely to work with this approach? Or will they be able to?
I have not. A lot of people do like extensions though.
Other platforms have managed to get concepts like extensions, e.g. on Linux (well, X really) I can replace my window manager, on Windows I can install DLLs that add features to Windows Explorer, on Android the "share" button can share to a list of applications, etc. There's lots of examples.
> Not sure what you really mean. [...] sites are too complicated for anyone to pick out what's going on from the original source let alone the actual served source...
I agree, View Source itself has become less and less useful. The Devtools in most browsers have kept up fairly well though. They provide a lot of methods to understand, debug, and modify behavior of whatever you're running using HTML/CSS/JS, even if not perfect.
Perhaps if Flutter became mainstream enough that there's theoretically nothing stopping this from eventually happening for it as well. That's an interesting thought.
--
I suppose that leaves my last question, and it leans away from what might be a practical view from your position: Do you think flutter pushing for major market share while also trying to replace the core part of the web (HTML/CSS/JS -> Canvas renderer/wasm) is a good thing for the web's health and future?
(That's a good bit more philosophical, but I hope in #CURRENTYEAR we're starting to see value asking long-term questions like that, especially from inside of the giant companies. I'll stick to one of those kinds of questions)
--
> I'm a weird case, I got into the web by reading the standards. (Then I got annoyed the browsers didn't follow them, so I got into browser QA. Then I got annoyed that the standards weren't clear enough to allow test cases to be written, and I started editing the specs.)
That is interesting, thanks for sharing that.
> I have not. A lot of people do like extensions though.
Also interesting, fair enough.
> Other platforms have managed to get concepts like extensions, e.g. on Linux (well, X really) I can replace my window manager, on Windows I can install DLLs that add features to Windows Explorer, on Android the "share" button can share to a list of applications, etc. There's lots of examples.
Perhaps a good new question is what kind of tooling is available or planned for users to interact with Flutter applications? Such as what Devtools provide, or an expansion to them directly.
As a developer, the Devtools are absolutely critical to my workflow and ability to learn from and often fix issues I have with other sites.
(It could be pointed out that native applications don't tend to have that functionality, so it shouldn't be expected.. but in this context we're talking about effectively removing it from the Web, which does)
I mean, I try to use Devtools on other sites, but I haven't really had any real success with that for years. I don't know how many of the rest of the web's ~4 billion users try to use DevTools but I can't imagine it's anything close to a majority. Or even a large minority.
FWIW Flutter isn't trying to replace the web. We're trying to offer a way of writing web apps that aren't really possible today. For example, something like the Flutter Folio demo, which works on multiple platforms including web, was written in a few weeks. I cannot fathom how I would do that without Flutter.
It's painting stuff in a canvas and not using the standard web controls.
It's the web in the sense that almost every UI toolkit also offers a canvas (for example Tk does this) and you can reimplement every control using it. That doesn't make your new toolkit in a toolkit Tk.
But why would an app that writes to a WebGL canvas be any harder to maintain than an app that uses HTML controls? If anything, it'd be likely to be easier to maintain -- we (the web standards community) are much more likely to change how a particular element is supposed to work than to change WebGL in an incompatible way.
But the framework? That will have to be updated when each OS the framework runs on changes.
The HTML controls are used by a ton of stuff, so they're quite likely to be updated. Your framework? I have to really, really trust you that you'll update them.
Look at how Motif or GTK or AWT or Swing or Tk widgets look on modern OSes. There's an entire graveyard of cross platform UI libraries out there.
We don't pull any resources from Google (or any of the other companies who contribute to Flutter, like Microsoft, Cannonical, Nevercode, etc) at runtime.
During development time we pull binaries from Google servers (for lack of a better place to put them mostly) and source from GitHub, and as Tim said there's some analytics (there's a big message saying how to opt of analytics when you first start the flutter command line tool).
I know the web site says Flutter is "made by Google" but that's really underselling how much Flutter is a group effort by lots of contributors, a (very active) minority of which happen to work for Google.
The whole project is open source, there's no closed-source component, and lots of people build their own binaries, for what it's worth. So you don't have to trust me on any of this. :-)
Does that mass-market consumer product have proper accessibility support, e.g. for blind users? If so, is that somehow implemented within the Flutter UI, or parallel to it (e.g. as a separate voice interface)?
I think the parent comment was talking about Nest Hubs / Google Homes, which are arguably voice first via the Google Assistant. I can only imagine but if I had, much more significant, vision issues then I think I'd use it even more.
Please don't hesitate to file bugs on any performance issues you see. We care very much about getting excellent performance. There are some specific hardware configurations that we are aware don't behave as well as we'd like (though nothing as bad as you're describing), but that's usually limited to pretty low-end phones where honestly even the OEM software doesn't perform that well...
It's a pretty big app. I'd be curious to see how big the equivalent app built using Web technologies directly would be.
That said, yes, if you want small download sizes on the Web then Flutter isn't the technology for you.
Concretely: our minimal overhead is about 300KB gzipped currently. We expect that to go down a bit before we exit beta, but a "hello world" in Flutter for Web will never get down to the few dozen bytes that you could get using pure HTML.
Fundamentally our approach will always have a large overhead compared to other Web technologies because we don't use most of the built-in features that browsers bring to the table like CSS and HTML and so on. We have our own layout, our own compositing, our own gesture detector, etc. We even blink our own cursor. The only features we use are the lowest-level ones like `canvas` that are needed to actually push pixels to the screen, or ARIA which is needed to expose the accessibility tree.
On the plus side that means you can do anything you want. You want the text cursor to look like a wiggling snake with eyes that follow the mouse cursor? No problem. You want a checkbox that exactly matches the Material Design spec? Or that exactly matches the iOS design language? No problem. The cost is that all that code has to ship with your app.
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.
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.
That's literally how Flutter started. "What if we don't have to be backwards compatible? Let's delete the HTML parsing quirks... and expensive CSS selectors... and... all of the DOM... and JavaScript... and why do we have markup even..."
We don't have an official foundation, but we are already operating more or less as openly as we would if we did. We have contributions from lots of companies and volunteers; the majority of the people who have contributor access in fact aren't from the Google Flutter team.