But yeah it's not grabbing market share that's for sure.
You're right -- we do render the controls, so that existing Flutter code (that might itself include custom styling or matrix transforms) just runs without change or surprise, but we integrate with the underlying browser support for things like text autofill and accessibility.
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.
That is exactly defeating the point. Flash apps were also "true web apps" that only happen to use the "limited control set" of just <embed>.
> It's basically how every other platform works
That's why there has never been a UI toolkit as successful as the web.
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.
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 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.
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.
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)
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.
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.
We are in infinitely better position today thanks to open source. The "View Source" of today is GitHub. Want to write a high-performance dynamically typed language VM? Here: https://github.com/v8/v8 Build an operating system? OK: https://github.com/torvalds/linux Build a database? Here you go: https://github.com/postgres/postgres
If the accessibility story isn't rock-solid, frankly this is a non-starter for a lot of applications. Web apps suck in a lot of ways but regular HTML has pretty great accessibility properties.
The labyrinthine rats nest of absolute hot garbage to beat a document rendering engine into a windowing toolkit with widgets is horrible. It's a testament to front-end devs that with enough effort you really can squeeze water from a stone.
And then imagine being so comfortable navigating that maze that you want your windowing toolkits to behave more like document rendering engines pretending to be windowing toolkits.
And you're like "why not just have a windowing toolkit for the web and sites can choose their rendering engine basically so all the SPAs get all the nice features of stack-based GUIs and document people get documents. Surely that would be less work!" And I think you're right but I doubt anyone would agree on a single toolkit so now you can just bundle your own compiled to wasm and rendered to canvas. Woooo.
If you're trying to create a classical website, it's not the right tool. Use html and css. If you're trying to make a rich app, I'd bet on Flutter.
I'd be interested in seeing it become easier to make a combination of the two -- flutter apps embedded in classical websites.
Sounds like Java applets.
Accessibility is actually a really big deal here on Flutter (Ian Hickson and I both worked on Accessibility in browsers for years). AX is something I feel we've done pretty well with on iOS and Android. Web is still pretty early days, but many AX features should work already. We have more AX work to do on web yet. We've not yet taken any Flutter Web apps through Google's accessibility testing processes similar to how we've done on the mobile side, but I expect we will soon.
In general Flutter for Web is _amazing_ if you want to deploy an app.
after seeing this thread, pretty clear to me its almost a perfect nerdsnipe - makes perfect sense if you're already building a Flutter codebase, sounds bonkers if you build web apps.
The "Create account" link isn't popping up the right-click menu because it doesn't use the Link widget. You'd get the same thing in plain HTML if you used a <div> with a custom click event listener instead of <a>. It's a simple bug to fix; totally up to the app developer. I think issues like that will inevitably pop-up as we have developers coming to the web from other platforms, where "open in new tab" isn't part of the toolkit. Perhaps it's fixable via education and platform-specific guidelines.
We're aware of the input blur issue. I think the bug is in the TextEditable. You can write your own, of course, but since we offer it as part of the Flutter framework, it's on us to fix.
I think this is right, but I also think it should be clear to everyone (i.e. in the first tutorial) that not using a Link widget will make this work wrong for all sorts of accessibility and UX reasons. And the Link widget should work across platforms and implement the equivalent of page history correctly.
Maybe it's worth writing down somewhere what the equivalent of each tag from HTML is; what is the canonical way to create an h2, input, textarea, button, a, img, etc.
This is the issue. Instead of having one codebase that works the same on all platforms (ios, android and web), you get (as a developer) the blame for not implementing things correctly across the different platforms.
Instead of a cross-platform development environment doing that for you.
I think its because we might be seeing it from two different points: i.e. you see Flutter Web using Skia is not consistent with _other websites and thus traditional webapps_, I see that Flutter Web using JS/HTML made it _not consistent with deployments of the same Flutter code to Android/iOS/Mac_
Definitely see that viewpoint and why it's problematic, would argue as an independent dev, would care much more about 100% self-consistency across my product line up for ease of support than whether people open the app in a web browser, you can right click on anything that looks like an image and download it.
Understand that viewpoint _also_ sounds like sacrilege, but as someone raised on iOS dev, reminds me of when Mac devs being upset over years as "iOS-isms" made their way to the desktop. I love that this approach is an example of solving hard problems over years, fixing a industry-wide yak shave that ended with you having 50 copies of chromium. solves the same problem Electron is solving with none of the downsides
dstaley just said that those issues happen now. " I just tried a few samples, and ..."
I just tried the demos over at https://flutter.github.io/samples/#?platform=web and I concur, Flutter is utterly horrible for everything the web stands for. So not amazing and seems to actively make everything worse.
We certainly don't think Flutter should replace HTML or other frameworks. We hope Flutter will work well for many use-cases, but the web is huge. There's room for multiple approaches. If it's not working for your use-case it's totally fine with us if you use something else. We welcome constructive feedback on what's not working so we know where to focus our efforts.
I love the idea, but this sounds like it's going to be unpleasant for me. Hopefully they figure out these UX things.
* The page takes about 20s to load.
* After pressing Run, nothing happens for 10s, then Click me! text appears.
* On clicking the text, nothing happens.
* On clicking it a few times, the page crashes and reloads.
As timsneath mentioned above, Dartpad is the dev environment. That means we ship the full Dart and Flutter SDK ahead of time as you can type/change anything in the code box. We also ship debug metadata to give better errors.
In production mode, we do a much more expensive compile to remove the parts of Dart, Flutter, and packages you don't use and to optimize/minify the rest.
It is working in Safari for me, but we've definitely appreciate bug reports if it's breaking for you (https://github.com/dart-lang/dart-pad in this case).
There's no difference between CanvasKit and HTML as far as interactions are concerned. The differences are in pixels and performance. If there are issues with interactions, we'd like to hear about them. Please file issues on Github.