Hacker News Reader

Comment by throwaway77384 | Hacker News Reader

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?

View on HN

> 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/ https://w3c.github.io/webcomponents/spec/shadow/

https://www.webcomponents.org/ see "Browser Support"

I would note that "ratified by W3C" does not mean much nowadays. WHATWG won that war and the W3C now essentially rubber stamps whatever WHATWG decides.

What happened there? I am not in the loop on this, so wouldn't mind getting some more details.

When W3C's XHTML 2.0 stalled WHATWG created a new "living standard" (which is subject to constant modifications and additions) to continue HTML development. W3C attempted to create fixed standards from the document (e.g. HTML 5.1, HTML 5.2, etc) that only included things that were widely supported and that met standards for accessibility and so on. However, due to the constant churn of WHATWG's document this was difficult and WHATWG were strongly against having what they saw as competing standards.

Therefore there was some conflict between the two groups until WHATWG emerged victorious. Here's the final agreement: https://www.w3.org/2019/04/WHATWG-W3C-MOU.html

It boils down to complete capitulation by W3C.

Only for HTML, not for CSS & JS. JS is handled by TC39 and CSS is still at W3C.

Interesting stuff! Thanks for sharing :)

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...

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).

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

[2] https://dev.to/richharris/why-i-don-t-use-web-components-2ci...

[3] https://dev.to/webpadawan/beyond-the-polyfills-how-web-compo... and https://dev.to/webpadawan/the-journey-of-web-components-wron...

Screen readers and accessibility software have never worked well* with arbitrary applications, and that’s what sites using the shadow dom aim to be.

Screen readers especially only do well on simple documents, and only work with apps well they’re specifically designed to interface with which for the most part are apps that are used in document creation or text communication like Word, or Skype.

*Disclaimer: “well” is in the eye of the beholder. It’s challenging to use them with arbitrary apps, and the time investment is only useful if that app is going to put food into your table.

> 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/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.

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.

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.)

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.

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

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.

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.

"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.

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.

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.

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.

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.

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.

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.

They're building some, but also killing others, like the aforementioned <style scoped>.

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.

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.

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.

Reply on news.ycombinator.com