4 ms·

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 HT

by Hixie 6y ago

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.

ComputerGuru 6y ago
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.
- Hixie 6y ago
  I would have had much less of a problem with Flash if it had been a runtime built with web technologies like that.
shawnz 6y ago
> to create true web apps that just happen to not use much of the control set that HTML exposes. 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.
- Hixie 6y ago
  > Flash apps were also "true web apps" 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.
oblio 6y ago
Well, good luck maintaining all of that 10 years from now. I can bet on the web being around, well developed and maintained in 2031.
- Hixie 6y ago
  I'm not really sure what you mean by "all of that". What I described _is_ the web.
  - oblio 6y ago
    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.
    - Hixie 6y ago
      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.
      - oblio 6y ago
        The app? It won't be harder to maintain, yes. 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.
BystanderX 6y ago
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.
- Hixie 6y ago
  > 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.

by Hixie 6y ago

ComputerGuru 6y ago

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.

Hixie 6y ago
I would have had much less of a problem with Flash if it had been a runtime built with web technologies like that.

shawnz 6y ago

> to create true web apps that just happen to not use much of the control set that HTML exposes. 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.

Hixie 6y ago
> Flash apps were also "true web apps" 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.

oblio 6y ago

Well, good luck maintaining all of that 10 years from now. I can bet on the web being around, well developed and maintained in 2031.

Hixie 6y ago
I'm not really sure what you mean by "all of that". What I described _is_ the web.
- oblio 6y ago
  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.
  - Hixie 6y ago
    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.
    - oblio 6y ago
      The app? It won't be harder to maintain, yes. 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.

BystanderX 6y ago

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.

Hixie 6y ago
> 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.