5 ms·

I mean, with the dawn of webassembly, I feel as though things are going to get closed off more and more. We've had this with flash and java applets too. Ultima

I mean, with the dawn of webassembly, I feel as though things are going to get closed off more and more. We've had this with flash and java applets too. Ultimately I hope an open internet will prevail. Otherwise we will not be able to archive things effectively. Don't get me started on accessibility also. While I'll happily jump on the let's-bash-google-train, is there any effort to do the same thing in a non-scoped way? I feel a set of 'web-components' would in fact be a super useful thing to have for everyone. Why does it have to be google-chrome / whatever-specific and locked down?

timw4mail 7y ago
Google essentially has the same role Microsoft did at the height of the browser wars...majority market share and lazy developers. So new shiny things tend to be Chrome-only. Webcomponents exist as a loose set of standards that are marginally cross-browser, but Google has the biggest/most popular framework using web components.
- lima 7y ago
  The big difference is that Google is building well-specified new web standards which are quickly adopted by other browser vendors, rather than adding a heap of poor proprietary browser extensions that become de-facto standards. They even deprecated Chrome Apps in favor of the PWA standard. Google has nothing to gain from hurting the open web ecosystem.
  - throwaway77384 7y ago
    "Google has nothing to gain from hurting the open web ecosystem." I really want to believe this. But how does AMP fit into this? I feel it is quite counter to the idea of an open web. Please do not take this as an attack or criticism, I would like to, in fact, learn some better arguments in favour of why Google would support, rather than suppress an open web ecosystem.
    - eropple 7y ago
      From the perspective of a service connecting eyeballs with the thing they're looking for (and some ads along the way), AMP is a relatively anodyne amplification on top of caching strategies. "Hey, build good, easily parsed and managed pages and we'll make everything Way Way Faster" is the argument. To be clear, I'm not saying that it is necessarily representative of reality, but that's the idea.
      - throwaway77384 7y ago
        Interesting. It would appear I have been downvoted by someone for asking a question, which is a strange thing to do. Anyway, I thank you for your comment. I now feel I understand the matter / intent behind AMP a little better.
    - lern_too_spel 7y ago
      AMP is a federated web alternative to closed apps and ecosystems like Apple News and FB Instant Articles. It's a specification built using existing web standards that allows anybody to build FB IA or Apple News without integrating directly with publishers.
    - themacguffinman 7y ago
      Depends on what you mean by "an open web". If you consider "an open web" to be a publicly accessible network of documents and applications, it's practically absurd to suggest that Google - a company that makes almost all of its money from services that need to crawl everything it can find on the public internet - might want to hurt this. The more websites and applications that join the open web ecosystem and open themselves to public crawling and searching, the better it is for Google. Walled gardens like Apple News and Facebook Instant actually run counter to this open web. They can't be publicly indexed or crawled or searched, yet they have the valuable advantage of being really fast. I see AMP as an aggressive optimization designed to bring web performance up to par with native platforms like Apple News and Facebook Instant. When a publisher chooses AMP instead of exclusively using those closed platforms, it's a win for the open web when their content uses web standards (AMP is merely a strict subset of web standards) accessible by anyone, not just Apple or Facebook users. I think nowadays "the open web ecosystem" has come to mean something different in discussions like this, closer in meaning to "the distributed web" or "a less corporate web". Google obviously doesn't care for that.
  - admax88q 7y ago
    That's true, however the new standards are often poorly designed and require Google level resources to keep up with the pace of change. They've basically ensured that another Netscape/Chrome cannot happen, they've pushed the complexity of the web so quickly that only the biggest most well funded companies can afford to keep up.
    - true_religion 7y ago
      Browsers are now about as complicated as operating systems were in the 1980s. It’s not impossible to create a new one, but it’s certainly not low hanging fruit anymore.
  - int_19h 7y ago
    They're building some, but also killing others, like the aforementioned <style scoped>.
- IAmEveryone 7y ago
  This is such a common misconception... Internet Explorer was terrible because they would drop some binary blob (ActiveX, Flash Player) into the interpreter. And those binaries were neither standardised, nor cross-platform, nor OSS. None of that is true for Chrome. Google's additions tend be useful, which is why "too fast" and "bloated" is the only (generic and subjective) criticism people can come up with. With Safari on Mac and especially iOS, Google also doesn't quite own the same position that MS did. Nor do they have any incentives to harm other browsers: their competitors are Facebook and iOS native apps, i. e. the walled gardens that can't be crawled and searched.
  - int_19h 7y ago
    There were far more issues with IE than just ActiveX and Flash (especially since Flash was also available for all other browsers). It was the difference in how it handled HTML/CSS/JS, compared to other browsers, that was the biggest pain point by far.
  - timw4mail 7y ago
    ActiveX was never as big an issue as weird CSS rendering and JScript weirdness. Even VBScript was a minimal issue. In some ways, it's for the best that Microsoft basically stopped development in the days of IE6, as it didn't lead to the exponential feature bloat that has been the case the last few years.
lima 7y ago
> I mean, with the dawn of webassembly, I feel as though things are going to get closed off more and more. This is already possible today - many Qt applications, for example, compile to WebAssembly with minimal changes required. Look at this nice Qt rich text editor demo, rendered in a canvas: https://s3.eu-west-2.amazonaws.com/wasm-qt-examples/last/index.html https://s3.eu-west-2.amazonaws.com/wasm-qt-examples/last/ind... Even copy&paste works! But except for use cases like porting existing niche enterprise applications, I don't see why anyone would prefer this over standard web development. Performance is worse, it's very slow compared to the DOM, accessibility is nil, it requires arcane tooling and the ecosystem is so much smaller.
- chrismorgan 7y ago
  And that the very simplest examples have to download 12MB of code before they can do anything. (OK, so it’s probably more like a 4.5MB download. Still waaay bigger than you should require for most purposes.) And you don’t seem to be able to enter astral plane characters at all (though that’s just an implementation bug that they haven’t dealt with yet, and shouldn’t be a fundamental problem of the approach). And controls are all wonky and non-native in look or feel. And keyboard control slips badly in many places so that you lose your place within the window easily. Recompiling desktop apps to the web (and specifically Qt, but also excluding games, which live somewhat in a space of their own) is very niche.
  - deleted 7y ago
    [deleted]
dfabulich 7y ago
> is there any effort to do the same thing in a non-scoped way? It's already done! Web Components (Custom Elements + Shadow DOM) are web standards, ratified by W3C, and they already work great in Firefox and Safari. This whole article is simply incorrect. http://w3c.github.io/webcomponents/spec/custom/ http://w3c.github.io/webcomponents/spec/custom/ https://w3c.github.io/webcomponents/spec/shadow/ https://w3c.github.io/webcomponents/spec/shadow/ https://www.webcomponents.org/ https://www.webcomponents.org/ see "Browser Support"
- dmitriid 7y ago
  They... don't work great. They cannot be serialized, they break accessibility, they break screen readers (AFAIR), they are not lazy loaded, they do not participate in form events, they...
  - dfabulich 7y ago
    They require JS, which is definitely a drawback. But they work fine in screen readers, (you can screw this up with JS, just like any other HTML) and they "participate" in form events just like other HTML. Since they require JS, you can lazy load them if you want (it's just JS).
    - dmitriid 7y ago
      I don't know the state of it today, but even in summer last year custom components with Shadow DOM were still excluded from Form Submission. Form-associated custom elements proposal was enabled in Chrome, no idea if Safari or Firefox went and implemented it, too. Shadow DOM also throws off accessibility IIRC if aria-labeledby and similar cross shadow dom boundaries [1] but I do agree they should be largely accessible to assistive technologies. You can't truly lazy-load them. See Rich Harris' (author of Svelte) take on Web Components [2] And these two articles by a Web Components proponent listing the many issues they still have [3] [1] See for example this tweet https://twitter.com/sarahmei/status/1198069119897047041 https://twitter.com/sarahmei/status/1198069119897047041 [2] https://dev.to/richharris/why-i-don-t-use-web-components-2cia https://dev.to/richharris/why-i-don-t-use-web-components-2ci... [3] https://dev.to/webpadawan/beyond-the-polyfills-how-web-components-affect-us-today-3j0a https://dev.to/webpadawan/beyond-the-polyfills-how-web-compo... and https://dev.to/webpadawan/the-journey-of-web-components-wrong-ways-lacking-parts-and-promising-paths-1d5a https://dev.to/webpadawan/the-journey-of-web-components-wron...
throw_m239339 7y ago
Web Assembly changes nothing to the issues described in the post. Web Assembly still relies on WebAPI in the browser.
pas 7y ago
It doesn't work that way. Technology almost always can be used for more than one purpose. WebAssembly will grow the web a lot. Sure, it might replace some existing parts, but that's not because WebAssembly is "evil" or "closed", but because some publishers/sites/folks want to go into that direction. They are probably already doing a lot of "closed" stuff. DRM? IP restriction? Continuous connection checking or the site stops working? Idiotic session timer? Restricting registration to certain users for no real legal reason at all? Obfuscated HTTP API? The list goes on. Worrying about dumb technology is irrelevant. (If you want to worry about tech, worry about AI, that has the potential to really cause problems.)
dathinab 7y ago
WebAssembly is not more closed of as normal minnified JavaScript. Sure you could combine WebAssembly with some DRM thinks to close it off. But so can you do for normal JavaScript. At the same time WebAssembly does open the web for more programming languages, more programs/use-cases (due to more close to hardware performance). Lastly WebAssembly turned out to be very usefull for having a standartized cross platform, cross architecture sand-boxing system. I.e. what Java tried but failed to do.

timw4mail 7y ago

Google essentially has the same role Microsoft did at the height of the browser wars...majority market share and lazy developers. So new shiny things tend to be Chrome-only. Webcomponents exist as a loose set of standards that are marginally cross-browser, but Google has the biggest/most popular framework using web components.

lima 7y ago
The big difference is that Google is building well-specified new web standards which are quickly adopted by other browser vendors, rather than adding a heap of poor proprietary browser extensions that become de-facto standards. They even deprecated Chrome Apps in favor of the PWA standard. Google has nothing to gain from hurting the open web ecosystem.
- throwaway77384 7y ago
  "Google has nothing to gain from hurting the open web ecosystem." I really want to believe this. But how does AMP fit into this? I feel it is quite counter to the idea of an open web. Please do not take this as an attack or criticism, I would like to, in fact, learn some better arguments in favour of why Google would support, rather than suppress an open web ecosystem.
  - eropple 7y ago
    From the perspective of a service connecting eyeballs with the thing they're looking for (and some ads along the way), AMP is a relatively anodyne amplification on top of caching strategies. "Hey, build good, easily parsed and managed pages and we'll make everything Way Way Faster" is the argument. To be clear, I'm not saying that it is necessarily representative of reality, but that's the idea.
    - throwaway77384 7y ago
      Interesting. It would appear I have been downvoted by someone for asking a question, which is a strange thing to do. Anyway, I thank you for your comment. I now feel I understand the matter / intent behind AMP a little better.
  - lern_too_spel 7y ago
    AMP is a federated web alternative to closed apps and ecosystems like Apple News and FB Instant Articles. It's a specification built using existing web standards that allows anybody to build FB IA or Apple News without integrating directly with publishers.
  - themacguffinman 7y ago
    Depends on what you mean by "an open web". If you consider "an open web" to be a publicly accessible network of documents and applications, it's practically absurd to suggest that Google - a company that makes almost all of its money from services that need to crawl everything it can find on the public internet - might want to hurt this. The more websites and applications that join the open web ecosystem and open themselves to public crawling and searching, the better it is for Google. Walled gardens like Apple News and Facebook Instant actually run counter to this open web. They can't be publicly indexed or crawled or searched, yet they have the valuable advantage of being really fast. I see AMP as an aggressive optimization designed to bring web performance up to par with native platforms like Apple News and Facebook Instant. When a publisher chooses AMP instead of exclusively using those closed platforms, it's a win for the open web when their content uses web standards (AMP is merely a strict subset of web standards) accessible by anyone, not just Apple or Facebook users. I think nowadays "the open web ecosystem" has come to mean something different in discussions like this, closer in meaning to "the distributed web" or "a less corporate web". Google obviously doesn't care for that.
- admax88q 7y ago
  That's true, however the new standards are often poorly designed and require Google level resources to keep up with the pace of change. They've basically ensured that another Netscape/Chrome cannot happen, they've pushed the complexity of the web so quickly that only the biggest most well funded companies can afford to keep up.
  - true_religion 7y ago
    Browsers are now about as complicated as operating systems were in the 1980s. It’s not impossible to create a new one, but it’s certainly not low hanging fruit anymore.
- int_19h 7y ago
  They're building some, but also killing others, like the aforementioned <style scoped>.
IAmEveryone 7y ago
This is such a common misconception... Internet Explorer was terrible because they would drop some binary blob (ActiveX, Flash Player) into the interpreter. And those binaries were neither standardised, nor cross-platform, nor OSS. None of that is true for Chrome. Google's additions tend be useful, which is why "too fast" and "bloated" is the only (generic and subjective) criticism people can come up with. With Safari on Mac and especially iOS, Google also doesn't quite own the same position that MS did. Nor do they have any incentives to harm other browsers: their competitors are Facebook and iOS native apps, i. e. the walled gardens that can't be crawled and searched.
- int_19h 7y ago
  There were far more issues with IE than just ActiveX and Flash (especially since Flash was also available for all other browsers). It was the difference in how it handled HTML/CSS/JS, compared to other browsers, that was the biggest pain point by far.
- timw4mail 7y ago
  ActiveX was never as big an issue as weird CSS rendering and JScript weirdness. Even VBScript was a minimal issue. In some ways, it's for the best that Microsoft basically stopped development in the days of IE6, as it didn't lead to the exponential feature bloat that has been the case the last few years.

lima 7y ago

> I mean, with the dawn of webassembly, I feel as though things are going to get closed off more and more. This is already possible today - many Qt applications, for example, compile to WebAssembly with minimal changes required. Look at this nice Qt rich text editor demo, rendered in a canvas: https://s3.eu-west-2.amazonaws.com/wasm-qt-examples/last/index.html https://s3.eu-west-2.amazonaws.com/wasm-qt-examples/last/ind... Even copy&paste works! But except for use cases like porting existing niche enterprise applications, I don't see why anyone would prefer this over standard web development. Performance is worse, it's very slow compared to the DOM, accessibility is nil, it requires arcane tooling and the ecosystem is so much smaller.

chrismorgan 7y ago
And that the very simplest examples have to download 12MB of code before they can do anything. (OK, so it’s probably more like a 4.5MB download. Still waaay bigger than you should require for most purposes.) And you don’t seem to be able to enter astral plane characters at all (though that’s just an implementation bug that they haven’t dealt with yet, and shouldn’t be a fundamental problem of the approach). And controls are all wonky and non-native in look or feel. And keyboard control slips badly in many places so that you lose your place within the window easily. Recompiling desktop apps to the web (and specifically Qt, but also excluding games, which live somewhat in a space of their own) is very niche.
- deleted 7y ago
  [deleted]

dfabulich 7y ago

> is there any effort to do the same thing in a non-scoped way? It's already done! Web Components (Custom Elements + Shadow DOM) are web standards, ratified by W3C, and they already work great in Firefox and Safari. This whole article is simply incorrect. http://w3c.github.io/webcomponents/spec/custom/ http://w3c.github.io/webcomponents/spec/custom/ https://w3c.github.io/webcomponents/spec/shadow/ https://w3c.github.io/webcomponents/spec/shadow/ https://www.webcomponents.org/ https://www.webcomponents.org/ see "Browser Support"

dmitriid 7y ago
They... don't work great. They cannot be serialized, they break accessibility, they break screen readers (AFAIR), they are not lazy loaded, they do not participate in form events, they...
- dfabulich 7y ago
  They require JS, which is definitely a drawback. But they work fine in screen readers, (you can screw this up with JS, just like any other HTML) and they "participate" in form events just like other HTML. Since they require JS, you can lazy load them if you want (it's just JS).
  - dmitriid 7y ago
    I don't know the state of it today, but even in summer last year custom components with Shadow DOM were still excluded from Form Submission. Form-associated custom elements proposal was enabled in Chrome, no idea if Safari or Firefox went and implemented it, too. Shadow DOM also throws off accessibility IIRC if aria-labeledby and similar cross shadow dom boundaries [1] but I do agree they should be largely accessible to assistive technologies. You can't truly lazy-load them. See Rich Harris' (author of Svelte) take on Web Components [2] And these two articles by a Web Components proponent listing the many issues they still have [3] [1] See for example this tweet https://twitter.com/sarahmei/status/1198069119897047041 https://twitter.com/sarahmei/status/1198069119897047041 [2] https://dev.to/richharris/why-i-don-t-use-web-components-2cia https://dev.to/richharris/why-i-don-t-use-web-components-2ci... [3] https://dev.to/webpadawan/beyond-the-polyfills-how-web-components-affect-us-today-3j0a https://dev.to/webpadawan/beyond-the-polyfills-how-web-compo... and https://dev.to/webpadawan/the-journey-of-web-components-wrong-ways-lacking-parts-and-promising-paths-1d5a https://dev.to/webpadawan/the-journey-of-web-components-wron...

throw_m239339 7y ago

Web Assembly changes nothing to the issues described in the post. Web Assembly still relies on WebAPI in the browser.

pas 7y ago

It doesn't work that way. Technology almost always can be used for more than one purpose. WebAssembly will grow the web a lot. Sure, it might replace some existing parts, but that's not because WebAssembly is "evil" or "closed", but because some publishers/sites/folks want to go into that direction. They are probably already doing a lot of "closed" stuff. DRM? IP restriction? Continuous connection checking or the site stops working? Idiotic session timer? Restricting registration to certain users for no real legal reason at all? Obfuscated HTTP API? The list goes on. Worrying about dumb technology is irrelevant. (If you want to worry about tech, worry about AI, that has the potential to really cause problems.)

dathinab 7y ago

WebAssembly is not more closed of as normal minnified JavaScript. Sure you could combine WebAssembly with some DRM thinks to close it off. But so can you do for normal JavaScript. At the same time WebAssembly does open the web for more programming languages, more programs/use-cases (due to more close to hardware performance). Lastly WebAssembly turned out to be very usefull for having a standartized cross platform, cross architecture sand-boxing system. I.e. what Java tried but failed to do.