News for hackers. Stuff that matters.
Re:Please consider not adopting Google WebComponents by tdumitrescu on Tuesday March 17, 2020 @09:53AM (#22604842)
What a weird polemic. "With Google WebComponents here we mean the use of CustomElements and Shadow DOM, especially when used in combination, and in dynamically created document structures (e.g. using module loading/unloading and/or slotted elements). ... WebComponents used "in full" (i.e. dynamically) inherently creates complex web page structures that cannot be saved, archived or even displayed outside of the designated targeted browsers (primarily Google Chrome)."

It's a web API. Browsers implement it. Including Safari and FF. If the argument is that it's hard to implement and makes it harder for new browser implementations, the same could be said of new CSS features, other APIs like Web Audio, etc. Trying to brand Web Components as Google-only may have worked in the v0 prototype days in like 2014, but it's factually not the case today.

Re:Please consider not adopting Google WebComponents by eropple on Tuesday March 17, 2020 @10:18AM (#22605024)
It's a web API, but it's a web API that requires development work to do, and Goanna (Pale Moon's pre-multiprocess, pre-all-the-things-that-make-modern-Firefox-good Gecko fork) would need to implement those APIs.
Re:Please consider not adopting Google WebComponents by lima on Tuesday March 17, 2020 @10:24AM (#22605068)
Just ran checksec on Pale Moon's Linux binary distribution - their binaries are built with no mitigations whatsoever. ASLR disabled, no stack canaries, no fortify.

This whole project appears to be a security disaster and nobody should use it.

Re:Please consider not adopting Google WebComponents by q3k on Tuesday March 17, 2020 @10:27AM (#22605088)
They're generally pretty unprofessional.

https://github.com/jasperla/openbsd-wip/issues/86

Re:Please consider not adopting Google WebComponents by oefrha on Tuesday March 17, 2020 @10:57AM (#22605428)
I feel for the OpenBSD developer who apparently expected the project lead to be a reasonable grown-up, but ended up slapped in the face.
Re:Please consider not adopting Google WebComponents by lsaferite on Tuesday March 17, 2020 @01:26PM (#22607429)
That exchange borders on unbelievable for me. How any project could be so tone deaf is beyond comprehension. And the initial message from the PM project is more than enough to set anyone off.
Re:Please consider not adopting Google WebComponents by stickfigure on Tuesday March 17, 2020 @03:44PM (#22609419)
This issue is now officially resolved. There will be no Pale Moon browser, official or not. The port has been removed. Farewell, petulant children.

Beautiful response.

Re:Please consider not adopting Google WebComponents by lonelappde on Tuesday March 17, 2020 @06:49PM (#22611441)
Petulance is independent of age.
Re:Please consider not adopting Google WebComponents by drusepth on Tuesday March 17, 2020 @03:58PM (#22609595)
This read was amazing, and I would fully recommend it for someone self-isolating with a hot cup of coffee who wants a jolly read about how not to communicate with others.
Re:Please consider not adopting Google WebComponents by tya99 on Wednesday March 18, 2020 @02:06AM (#22614061)
Then there's this one from privacytools.io where they disregard criticism as "Fake News" https://github.com/privacytoolsIO/privacytools.io/issues/375... and get all upset at people for "shitting on them". (Note mattatobin is also one of their devs).
Re:Please consider not adopting Google WebComponents by cultus on Tuesday March 17, 2020 @11:30AM (#22605792)
yikes. That's about the most insane exchange I've seen on Github.
Re:Please consider not adopting Google WebComponents by laurent123456 on Tuesday March 17, 2020 @11:18AM (#22605666)
Why was it used at all if it's basically an old fork of Firefox? Just curious as I've never heard of it before.
Re:Please consider not adopting Google WebComponents by eropple on Tuesday March 17, 2020 @11:24AM (#22605742)
"Customization." It retains the older, Firefox ~25-ish UI. They've since upgraded the backend to Firefox 52, which is still Really Old. And they've got a lot of culty behavior around their community, if that's your bag.

If you absolutely must have an XUL-based Firefox derivative: 1) you don't, 2) stop, and 3) don't use this one if you don't listen to #1 or #2.

[dead]
Re:Please consider not adopting Google WebComponents by eropple on Tuesday March 17, 2020 @12:24PM (#22606562)
Yes, I have seen your frothing Reddit posts, you don't have to repeat them here. "Leftist fascist"--can I give you a bit of free advice? If you have to modify "fascist", everyone and their dog knows it's because you have to modify your slur to make the mirror a little more palatable. Maybe find some new ones.

But I reject the square-peg premise you're trying to jam into that round hole anyway, as it's not a democracy, either. Your choices impact your neighbors without their consent. It's not about fucking over power users or whatever the weird little epistemic enclosure you come from wants to insist it is, it's about addressing technical debt both in terms of performance and security--and the latter matters quite a lot in terms of not enabling people who think they're power users to 1) blow their own leg off, and 2) blow the legs off the people next to them. That's why those "leftist fascist" evil scary Firefox people decided "hey, let's patch some of these up."

Customization, in and of itself, is fine (modulo the combinatoric explosion that leads to security holes). Few enough people would disagree with that, though I understand that the aforementioned epistemic closure holds as axiomatic that everybody just hates the tweaker types. On the other hand, customization at the expense of competent security development, which is what you get with Pale Moon, is not. And seeing as how there certainly doesn't seem to be much in the way of developer competence, to the point where "don't use the stuff that upstream has working just fine because we can't figure it out" is a legitimate attempt at "discussion", it ought to be dumpstered.

Somehow, this "power user" (god, I hate that term) gets by just fine with poor, benighted Firefox--having switched to it from Chrome/Safari after Quantum because it finally felt as pleasant to use as back in The Day. Clearly, though, that just makes me a radical-left SJW hater or something. But that's fine. Modern Firefox is heckin' great.

Re:Please consider not adopting Google WebComponents by tya99 on Wednesday March 18, 2020 @02:26AM (#22614144)
Looks like the sock puppets have arrived, quoting myself from that thread:

https://github.com/privacytoolsIO/privacytools.io/issues/375...

> There also seems to be a small group of devout followers who travel from the Palemoon forums to other parts of reddit, HN and github to spruik the project and derail criticism. I've observed (without naming names) it's the same names doing it over and over again.

They always use the same phrases too "nazi" and "fake news", "false narrative" etc. They tend to refer to themselves as "power users" with a clear tone of superiority to their comments.

I guess it must be the deep state! (sarcasm).

[dead]
Re:Please consider not adopting Google WebComponents by IAmEveryone on Tuesday March 17, 2020 @12:42PM (#22606803)
Users sure as hell didn't leave for BlueMoon or the other also-rans.

(And nobody is falling for your "leftist Nazi" shtick. It's quite telling that you can't even come up with terms for your imaginary opponents and have to fall back on misusing "fascist", "nazi", and "dictator", isn't it?

Here, in the interest of the English language, are some actual left-wing baddies you can use: Bolsheviki, Stalinist, Stasi, Politburo, Khmer Rouge, ETA (potential for puns here), (Popular|Democratic|Worker's) (Front|Army|Committee|Union) for (Liberation|Democracy|A Better Future|Legalisation)

Re:Please consider not adopting Google WebComponents by DonHopkins on Tuesday March 17, 2020 @02:17PM (#22608201)
Help. Police. Murder. Stop. Don't. Come back.

https://www.youtube.com/watch?v=W9ZD3_ppcPE

Re:Please consider not adopting Google WebComponents by superkuh on Tuesday March 17, 2020 @10:27AM (#22605091)
The real security disaster on the modern web is commercial groups taking over setting standards and turning the web browser into an OS with all the security problems that entails.
Re:Please consider not adopting Google WebComponents by lima on Tuesday March 17, 2020 @10:33AM (#22605146)
The opposite is the case - web applications are one of the best things to happen, security-wise, in a long time.

Web applications are fully isolated and sandboxed, have fine-grained permissions, are easy to inspect, and the runtime is built with a modern threat model.

ChromeOS is probably the most secure desktop OS for this reason.

I want my browser to expose more functionality to web apps, because it means that I have to run less random unsandboxed code on my underlying OS.

Re:Please consider not adopting Google WebComponents by ticviking on Tuesday March 17, 2020 @10:39AM (#22605198)
I'd like it more if my underlying OS provided these features instead of running an OS on my OS.
Re:Please consider not adopting Google WebComponents by lima on Tuesday March 17, 2020 @11:04AM (#22605521)
We need both - some kinds of applications need direct hardware access. But the kernel attack surface is huge, even with seccomp and friends.

An app on my smartphone or - much worse - an Electron app "sandboxed" in a flatpak on my desktop has access to far wider range of dangerous APIs than a web application. What's wrong with a browser as a high-level OS?

Re:Please consider not adopting Google WebComponents by ticviking on Tuesday March 17, 2020 @04:53PM (#22610292)
It's mostly the layering that bothers me.

I don't mind Chrome OS and love my chromebook.

Some of this is aesthetic so I don't really expect to change minds, but if we lived in the world of "Life and Death of Javascript" and booted to some kind of Web OS I'd be annoyed at the loss of low level hackibility and get over it.

Booting to Linux, then booting a browser to get to a normal app that doesn't need network connectivity "feels" wrong.

Re:Please consider not adopting Google WebComponents by pjmlp on Wednesday March 18, 2020 @02:24AM (#22614138)
Booting to Linux is just because Google did not want to start from scratch.

If they took a Xerox approach, ChromeOS would have a tiny mikrokernel, hypervisor type 1 style, and jump directly into Chrome.

Re:Please consider not adopting Google WebComponents by rictic on Tuesday March 17, 2020 @02:28PM (#22608332)
I agree, I'd like it if all app platforms were portable, secure, and linkable by default. Given that they aren't, my allegiance is with the web.
Re:Please consider not adopting Google WebComponents by ticviking on Tuesday March 17, 2020 @04:54PM (#22610316)
A reasonable view.

I value discoverability and comprehensibility of the underlying platform a bit more, and have recognized that isn't likely to happen any time soon.

Re:Please consider not adopting Google WebComponents by lonelappde on Tuesday March 17, 2020 @06:51PM (#22611463)
We had Java....
Re:Please consider not adopting Google WebComponents by the8472 on Tuesday March 17, 2020 @11:48AM (#22606035)
> are easy to inspect

Until they're delivery vehicles for obfuscated wasm to canvas rendering applications. Then nothing of the "web as graph of hypertext documents" will be left.

Re:Please consider not adopting Google WebComponents by floatboth on Tuesday March 17, 2020 @12:50PM (#22606926)
There's been a lot of ridiculous FUD about "DRM will be used even for text!!1" (wrt. EME especially) and nothing of that sort has materialized.

(also, wasm changes nothing here, you could always obfuscate js just as much)

Re:Please consider not adopting Google WebComponents by the8472 on Tuesday March 17, 2020 @01:07PM (#22607169)
> wasm changes nothing here, you could always obfuscate js just as much

It is a significant change because it lowers the bar to create a blackbox. wasm offers the performance, canvas provides an opaque, flexible render target. Without either you're limited to obfuscating your JS (which indeed already happens) and obfuscating your DOM (also happening). But the DOM still leaves enough surface for adblockers and other extensions to intervene. Perhaps throw in a websocket/webrtc to channel all your data over a single connection and you basically have created a single intransparent blob which extensions cannot interact with on the behalf of the user.

You turned the user agent into the site's agent.

> "DRM will be used even for text!!1" (wrt. EME especially)

I am not aware of EME offering a data path to bring encrypted text to the screen. Without such a path these claims have no merit, wasm + canvas on the other hand offer a clear path.

Re:Please consider not adopting Google WebComponents by superkuh on Tuesday March 17, 2020 @06:23PM (#22611219)
Go to nasa.gov with javascript off. Tell me how much text you can read. It doesn't have to be DRM. It just has to be ever more complex JS standards and engine implementations that only a handful of companies can actually make.

Once it's an application instead of a document the text just isn't there.

Re:Please consider not adopting Google WebComponents by basch on Tuesday March 17, 2020 @01:25PM (#22607425)
Flipboard made react canvas to render directly to canvas instead of the dom. https://github.com/Flipboard/react-canvas
Re:Please consider not adopting Google WebComponents by superkuh on Tuesday March 17, 2020 @04:24PM (#22609898)
Websites are at least supposedly are sandboxed so they are not as much of a risk as running native binaries. But this is getting worse and worse though as browsers expose more and more of their host operating system's functionality. The benefits of using a website instead of a native app are quickly disappearing, while the drawbacks have only been somewhat mitigated. We're getting to the point where browsers are worthy of the decades old criticism Emacs has received. They have eventually become an OS with many fine features - simply lacking a good web browser. For the privacy (and security) conscious user, modern web technologies will undermine you every step of the way, or simply break if you choose to stand your ground.
Re:Please consider not adopting Google WebComponents by tlbsofware on Tuesday March 17, 2020 @10:54AM (#22605392)
Sandboxes are security features that have to implemented though, and if implemented incorrectly will create vulnerabilities. I’m sure google is on top of these but these random unheard of browsers need more scrutiny
Re:Please consider not adopting Google WebComponents by eropple on Tuesday March 17, 2020 @11:03AM (#22605510)
The thing that kills me is that they forked a pretty bad (at the time) browser core to make Goanna, then the parent of the fork got way better and left them in the dust.

I would actively block Pale Moon if I thought I worked with people silly enough to use a slow single-process browser in 2020. (Instead of a moderately slow multi-process browser. But I digress.)

Re:Please consider not adopting Google WebComponents by IAmEveryone on Tuesday March 17, 2020 @11:42AM (#22605947)
Just empirically, browser security has improved dramatically over the last decade or so. When did a browser exploit last cause actual real-world damages? I remember network infrastructure compromises, social engineering, fake gmail logins, etc, but the weekly flash or PDF worm is gone, and JS seems to be holding up remarkably well given its size and complexity. Aluminium Centrifuges seem to also be more vulnerable these days than Chromium Browsers.

Somebody seems to be doing something right.

Re:Please consider not adopting Google WebComponents by smnthermes on Tuesday March 17, 2020 @04:37PM (#22610089)
> their binaries are built with no mitigations whatsoever. ASLR disabled, no stack canaries, no fortify.

Provide evidence.

Re:Please consider not adopting Google WebComponents by lima on Tuesday March 17, 2020 @04:53PM (#22610287)
Anyone can easily verify this by downloading the binaries, and running checksec themselves.

Here's the output:

    $ sha256sum palemoon-bin
    0b7f4ad73fc671e20bfb2366aa9d9ad81e82a3c8f63acde7f37063e73fda2141  palemoon-bin

    $ checksec --file=./palemoon-bin --output=json --extended | jq 
    {
      "./palemoon-bin": {
        "relro": "partial",
        "canary": "no",
        "nx": "yes",
        "pie": "no",
        "clangcfi": "no",
        "safestack": "no",
        "rpath": "no",
        "runpath": "no",
        "symbols": "no",
        "fortify_source": "no",
        "fortified": "0",
        "fortify-able": "15"
      }
    }
Notably, the binary has not been compiled with -fPIE and -fstack-protector, which disables two very basic exploit mitigations - ASLR and stack canaries. Any self-respecting Linux distribution enables these compiler flags by default nowadays. -D_FORTIFY_SOURCE is also missing, unlike Chrome or Firefox. A modern browser uses dozens of custom binary exploitation mitigations in addition to this.

Mitigations and sandboxing are the difference between an exploit a CTF player can write on an afternoon, and a multi-month expert-level endeavour.

Re:Please consider not adopting Google WebComponents by fouric on Tuesday March 17, 2020 @05:17PM (#22610559)
Which version is the `palemoon-bin` that you have there?
Re:Please consider not adopting Google WebComponents by eropple on Tuesday March 17, 2020 @05:22PM (#22610597)
It's 28.8.4 x64, downloaded straight from the website. (I duplicated his efforts; tbf, you could have, too.)
Re:Please consider not adopting Google WebComponents by oefrha on Tuesday March 17, 2020 @10:36AM (#22605170)
> It's a web API, but it's a web API that requires development work

Care to name one web API that doesn’t require development work?

Web standards evolve, new APIs are introduced. News at 11.

Re:Please consider not adopting Google WebComponents by eropple on Tuesday March 17, 2020 @11:01AM (#22605479)
Yeah, that's my point. Pale Moon's developers forked a complex project and are now asking people to not use things that the mainline project now supports just fine.

Checks written, can't cash, etcetera.

Re:Please consider not adopting Google WebComponents by oefrha on Tuesday March 17, 2020 @11:04AM (#22605515)
Fair enough, should have sensed the sarcasm.
Re:Please consider not adopting Google WebComponents by dmitriid on Tuesday March 17, 2020 @11:04AM (#22605519)
There are too many APIs released at neck-breaking speed, often poorly designed and rushed.

See Google's own Web Api tracking page [1] Chrome adds almost 1000 new APIs per year Only last year they added over 500 APIs that are not present in other browsers, and pretend they are standard and will not remove them even if other browsers are not going to implement them due to multiple explicitly voiced concerns.

So yeah, no. Your news at eleven is misleading at best.

[1] https://web-confluence.appspot.com/#!/confluence

Re:Please consider not adopting Google WebComponents by oefrha on Tuesday March 17, 2020 @11:10AM (#22605582)
> Definition: API: For the purposes of these metrics, an “API” is an interface name + attribute or operation pair.

So there aren’t 1000 new Web Component specs coming out each year, no. And fewer make it into W3C/WHATWG specs.

Re:Please consider not adopting Google WebComponents by dmitriid on Tuesday March 17, 2020 @11:15AM (#22605630)
No. But there are 1000 new web APIs that you have to implement yearly just to keep up. And Web Component specs are a part of that.

And then despite all the objections from all the other browser vendors Google releases an API in production and will not mark it as experimental. Yes, a Web Components-related API (Adopted Stylesheets).

Re:Please consider not adopting Google WebComponents by PunchTornado on Tuesday March 17, 2020 @10:21AM (#22605049)
the same can be said about any new CSS features and other new stuff that goes into the browser. browsers are evolving rapidly, either to make devs work easier or make users' work easier or just to make everything prettier or faster.
Re:Please consider not adopting Google WebComponents by smnthermes on Tuesday March 17, 2020 @04:20PM (#22609866)
> Trying to brand Web Components as Google-only may have worked in the v0 prototype days in like 2014, but it's factually not the case today.

Even Mozilla is having problems with Google WebComponents. There are 100 bugs open in Bugzilla about it.

Re:Please consider not adopting Google WebComponents by untog on Tuesday March 17, 2020 @11:49PM (#22613450)
Your comment doesn’t seem to be related to the text you’ve quoted. “It’s difficult to implement” is not related to “it is owned by Google”.
Re:Please consider not adopting Google WebComponents by smnthermes on Tuesday March 17, 2020 @05:12PM (#22610488)
YouTube uses WebComponents, and its pages are unviewable with Wayback Machine: http://web.archive.org/web/20200317150441/https://www.youtub...
Re:Please consider not adopting Google WebComponents by dathinab on Tuesday March 17, 2020 @05:51PM (#22610861)
Note sure, but doesn't AMP have "custom elements" which are not just CustomElement+Shadow DOM but google pseudo-proprietary "pre-loaded/created" elements?

Anyway it's nevertheless troublesome that google has so much influence that they can just push new web features without much discussion of other developers/browser vendors. Due to differences in internal design some features can be simple to implement for google but hard for everyone else (or the other way around, in which case google can just reject them by simply not implementing them).

EDIT: Also the non-JS web is basically dead. People should to come and accept that even if it's not perfect.

Re:Please consider not adopting Google WebComponents by SickOfSlowSites on Tuesday March 17, 2020 @08:22PM (#22612268)
> EDIT: Also the non-JS web is basically dead. People should to come and accept that even if it's not perfect.

No. I won't accept it. The JS web sucks. It's slow, bloated, provides nothing of value to me the user, and exists only to feed the maw of advertisers and platform providers who will never be satisfied with the tech we have.

HTML pages are still faster to use and 1000x easier to deploy than all this "modern" web crap that delivers less and less for more and more. Look at the site you are on!

I've never heard about this Webcomponents thing before today. I hate it already. No I'm not willing to give it a chance. I am certain, certain that it will deliver nothing but pages with 100K of actual content which need 10MB code downloads and 20s rendering times on an i5.

Web designers, developers, and especially browser developers are destroying the world wide web and replacing it with a glorified series of custom-flash apps. It's every bit as terrible as when flash was around no matter how much spin is put on these "standards". Google is the new Adobe and your website is awful again.

Re:Please consider not adopting Google WebComponents by dmix on Tuesday March 17, 2020 @08:37PM (#22612358)
You must not use any business software because that's where JS is making a killing. People rain on JS because it's abused on content sites who don't need it, but that doesn't mean it doesn't have massive utility for solving complex software problems requiring a high degree of interactivity which a static HTML form could never provide.
Re:Please consider not adopting Google WebComponents by asrt on Wednesday March 18, 2020 @04:44AM (#22614727)
>Also the non-JS web is basically dead. People should to come and accept that even if it's not perfect.

This is what it all comes to. Unparsable, terrible-to-use websites that are also not compatible with text-to-speech is the future because ad companies demand it. Users are complete non-entities in this decision.

Right now Gmail's HTML version is both faster and lighter than the regular version. The only advantage being not having to reload the entire page to load mails (which is still faster on the HTML version.)

Re:Please consider not adopting Google WebComponents by no_wizard on Tuesday March 17, 2020 @08:13PM (#22612182)
All of that is window dressing over custom elements polyfilled by document-register-element[0] and Preact[1]

Its a giant SSR machine, from what I can tell. Also web workers are leveraged to do alot of the heavy lifting when it can't be SSR'd

[0]https://github.com/WebReflection/document-register-element [1]https://preactjs.com/

Re:Please consider not adopting Google WebComponents by AnarchistNode7 on Tuesday March 17, 2020 @11:50AM (#22606067)
Even worse.. the Pale Moon guys are unskilled amateurs of the worst classification - the kind of developers which activity should be force-closed to protect others of their unintentionally spread incompetence which put tons of other people at high risks.

Not alone that, they are rude and shit into the face of a big part of the Linux community with threatening them in the worst way possible.

Then we had a server hack with compromised binary files....

People should be made aware of Pale Moon and their amateurish activity, so they can immediately uninstall this danger-ware from their systems!

Re:Please consider not adopting Google WebComponents by zamalek on Tuesday March 17, 2020 @11:59AM (#22606201)
They have blown things out of proportion (see parent comment). Only extremely minor browsers will be affected. Chromium (Chrome, Edge, Opera), Quantum (FF) will be fine. I suspect even the likes of KHTML will add support for it.

Pale Moon is a fork of Firefox made before the removal of XUL (as I believe is their selling point). They would have to back-port Web Components (which may be impossible due to Quantum) or write it from scratch. This is all really hard for them because they likely have fewer than 10 active developers.

Re:Please consider not adopting Google WebComponents by Udik on Tuesday March 17, 2020 @12:08PM (#22606327)
Can't they just ship the browser with js webcomponents polyfills?
Re:Please consider not adopting Google WebComponents by kevingadd on Tuesday March 17, 2020 @04:06PM (#22609685)
Back when I still had to support bleeding-edge web apps more than a few of my bug reports were from Pale Moon users because the devs couldn't configure their compiler properly and were always behind on bug fixes. Impossible to act on that stuff, though I tried. Once I realized how bad PM's security story was I gave up on supporting it, not gonna expose my development machines to that.
[dead]
Re:Please consider not adopting Google WebComponents by lima on Tuesday March 17, 2020 @05:09PM (#22610457)
Firefox did not have process-level sandboxing till Quantum. Exploit a JS bug in the renderer and you had code execution on the host OS.

"Fake news" accusations aren't welcome on HN, people here prefer to disagree amicably.

Re:Please consider not adopting Google WebComponents by superfist on Tuesday March 17, 2020 @10:20AM (#22605040)
Exactly, I don't understand what do they mean by Google WebComponents. CustomElements v0? v1? both?
Re:Please consider not adopting Google WebComponents by floatboth on Tuesday March 17, 2020 @12:53PM (#22606971)
Both, anything, everything. They're an ancient outdated (==insecure) fork of Firefox and they can't implement any new feature themselves.
Re:Please consider not adopting Google WebComponents by runarberg on Tuesday March 17, 2020 @02:36PM (#22608442)
Thanks for clarifying. While reading this I was under the impression that they were referring to specific web components created and hosted by Google, and I further assumed that Google denied crawlers access to the web component modules (hence closed). Thanks for making it clear that is not the case.
Re:Please consider not adopting Google WebComponents by monadic2 on Tuesday March 17, 2020 @11:33AM (#22605834)
It’s a document api that, when used, can’t be saved as a document. Pretty simple.
Re:Please consider not adopting Google WebComponents by rickcrown on Tuesday March 17, 2020 @11:30AM (#22605795)
Like it was said already... a lame excuse for "We can't successfully implement it, our browser is becoming incompatible with a large part of current web, so please do not use it to make us happy"

Without doubts - this will be Pale Moons final run - as the makers are fully unable to implement complex features on their own, as they do not have the tiniest bit of knowledge how to implement medium or highly complex Ecmascript features.

This link explains everything with all necessary details - also shared before: https://www.reddit.com/r/palemoon/comments/fk4fnl/attention_...

Re:Please consider not adopting Google WebComponents by Ajedi32 on Tuesday March 17, 2020 @12:01PM (#22606226)
Nonetheless, its still mildly concerning that smaller players in the browser space are finding it difficult to keep pace with all the new APIs being introduced to the web these days. Even Microsoft sort of gave up and killed their browser engine in favor of a Chromium fork.

It's a tricky situation with no obvious solutions. The Pale Moon dev's plea to slow down isn't going to work; devs want these new features and they're not going to stop using them just because a smaller browser developer with no significant market share can't keep up.

There is, perhaps, the beginnings of a solution with the Extensible Web Manifesto[1], which aims to shift the focus of browsers from implementation of many high-level features to instead focus on smaller, simpler low-level features which high-level features can then be built on top of. (Though ironically, web components are a part of this movement.) CSS Houdini[2] is one such feature which seems like it might be relevant in this specific situation (though whether it's helpful I have no idea; in the short term I suspect it might just translate to a lot more work).

[1]: https://github.com/extensibleweb/manifesto

[2]: https://developer.mozilla.org/en-US/docs/Web/Houdini

Re:Please consider not adopting Google WebComponents by esarbe on Tuesday March 17, 2020 @12:32PM (#22606682)
All the more reason to cherish Firefox.
Re:Please consider not adopting Google WebComponents by stjohnswarts on Tuesday March 17, 2020 @03:50PM (#22609494)
firefox is in the sites of Google, don't worry about that. They will find a weakness and exploit it to try and become the only "true" browser.
Re:Please consider not adopting Google WebComponents by SickOfSlowSites on Tuesday March 17, 2020 @08:28PM (#22612304)
> devs want these new features

Devs wanted Flash and real-player plugins pack in the day too. They wanted ActiveX plugins too. No-one else wanted them and it was ultimately the downfall of IE.

> Microsoft sort of gave up and killed their browser engine This will be the downfall of chrome. Google will ultimately be fined under anti-trust, chrome funding will dry up and browsers will stop supporting these absurd features. Have a nice time rewriting all your webcomponents in javascript in 5 years.

Re:Please consider not adopting Google WebComponents by untog on Tuesday March 17, 2020 @11:54PM (#22613464)
> Devs wanted Flash and real-player plugins pack in the day too. They wanted ActiveX plugins too. No-one else wanted them

The idea that users didn’t want Flash is laughable. It was enormously popular and enabled all kinds of multimedia presentation that the web couldn’t come close to rivalling.

> Have a nice time rewriting all your webcomponents in javascript in 5 years.

Web components are JavaScript. And it’s a standard agreed upon by all the major browser manufacturers. They aren’t going away, no matter what happens to Google.

Re:Please consider not adopting Google WebComponents by pjmlp on Wednesday March 18, 2020 @02:31AM (#22614166)
Had it not been for iPhone, and we would all still happily using Flash, instead of waiting 10 year to still catch up with what was possible in 2011 regarding 3D on the browser.
Re:Please consider not adopting Google WebComponents by jhare on Tuesday March 17, 2020 @05:16PM (#22610548)
Small players were never viable in the space. If they were people would care about, for example, Opera. Instead, probably 12-ish people care about Opera.
Re:Please consider not adopting Google WebComponents by smnthermes on Tuesday March 17, 2020 @03:49PM (#22609477)
> devs want these new features

Except that they didn't asked for them, as shown there (and note that Google removed <style scoped> from Chromium):

1. https://github.com/whatwg/html/issues/552#issuecomment-17810...

2. https://groups.google.com/a/chromium.org/forum/#!searchin/bl...

Also, even Mozilla is having problems with Google WebComponents. There are 100 bugs open in Bugzilla about it.

Re:Please consider not adopting Google WebComponents by lonelappde on Tuesday March 17, 2020 @12:52PM (#22606952)
But what are they afraid of?

I can run Firefox or whatever for modern websites, and Pale Moon or 10 year old sites running deprecated technology.

No one will ever build a website using WebComponents and NPAPI, so what's the problem?

The only possible explanation I see is that Pale Moon team desires and thinks that Pale Moo can become more popular than Firefox or Chrome simply by hoarding their discarded old tech. It's delusional, like selling computers with parallel ports and VGA cables and begging people not to use DislayPort monitors.

Re:Please consider not adopting Google WebComponents by smnthermes on Tuesday March 17, 2020 @03:51PM (#22609506)
> No one will ever build a website using WebComponents

WebComponents is adopted by Chromium (and with difficulty by Firefox).

Re:Please consider not adopting Google WebComponents by AgentME on Tuesday March 17, 2020 @04:01PM (#22609627)
I think they meant that no one will ever build a site using WebComponents and NPAPI together, since NPAPI has already been discontinued before WebComponents has taken off.
Re:Please consider not adopting Google WebComponents by eropple on Tuesday March 17, 2020 @04:04PM (#22609666)
I think you missed an association there. (WebComponents AND NPAPI)
Re:Please consider not adopting Google WebComponents by DonHopkins on Tuesday March 17, 2020 @01:46PM (#22607738)
Imagine they started working on hypermedia browsers 30 years ago, and were now admonishing everyone for not sticking with standard SGML. Yes, I'm sure DSSSL had a way of doing scoped styles. Scheme has scopes, right?
Re:Please consider not adopting Google WebComponents by int_19h on Tuesday March 17, 2020 @06:00PM (#22610971)
Side note: from reading the comments on that Reddit, it sounds like there's some weird affiliation with the 8chan alt-right crowd in the Pale Moon community?
Re:Please consider not adopting Google WebComponents by eropple on Tuesday March 17, 2020 @06:51PM (#22611455)
I don't know if it's 8chan, but there's a really weird cryptofascist--barely even "crypto", tbh--strain in that community. And I can see why. The community that huddles around outdated and bad tech for the reasons they do is going to skew regressive and is going to get progressively (ha!) more upset and resentful over time. That self-selects for the kinds of toxicity that share significant comorbidities with the "alt-right" and worse groups on that axis.
Re:Please consider not adopting Google WebComponents by tya99 on Wednesday March 18, 2020 @02:41AM (#22614225)
I've noticed this too, and I've also noticed it stems from their team members. https://news.ycombinator.com/item?id=22614144
Re:Please consider not adopting Google WebComponents by mandraphone on Wednesday March 18, 2020 @06:57AM (#22615273)
Ahh Good ol guilt by association https://en.wikipedia.org/wiki/Association_fallacy
Re:Please consider not adopting Google WebComponents by IAmEveryone on Wednesday March 18, 2020 @07:10AM (#22615323)
I had never heard of PaleBla before today. After seeing the BSD issue mentioned above, a short visit to their forum, and what’s being said by their supporters here I can unequivocally say it’s the most toxic and incompetent community in tech I’ve ever seen.

It’s weird and cult-like, but without drugs, dancing, or women. It’s sort of alt-right, hating gays and foreigners just as much as post-2008 JavaScript, but there just isn’t any reasonable model explaining how that connects.

Re:Please consider not adopting Google WebComponents by newsletterguy on Tuesday March 17, 2020 @11:02AM (#22605499)
Simply an excuse for "We can't successfully implement it, our browser is becoming incompatible with a large part of current web, so please do not use it to make us happy"!

Result - they are going to die and losing hope and faith, like the link here describes. Read especially the IRC link where they discuss things like that with their "ecmascript guy" Gaming4JC - who has the task... WITHOUT ADDITIONAL HELP" to make Pale Moon "COMPATIBLE WITH TODAYS WEB" - honestly... what a joke....

More here: https://www.reddit.com/r/palemoon/comments/fk4fnl/attention_...

Why is this the truth? They failed in the past with implementing stuff on their own, and they had to use new Firefox variants to re-base their UI towards them.

As there is not a way of going forward anymore without losing all their customization abilities, they are screwed as webcomponents is such a breaking point in time again where they can't succeed on their own because of their team missing guys who successfully would be able to implement stuff like this - uses Rust/Stylo/Servo - and that is way too complicated to them and they miss all the necessary knowledge how to convert it to their current codebase of Firefox 52!

Re:Please consider not adopting Google WebComponents by Wowfunhappy on Tuesday March 17, 2020 @11:12AM (#22605603)
Even if that reddit post is 100% correct, the author's behavior strikes me as the epitome of trolling. So I'm not inclined to take their words particularly seriously.

The author basically walked into a community of Pale Moon enthusiasts and shouted: "Hey Palemoon fans! Y'know that thing you love? It's going to die! Sorry!".

The legitimately-concerned version of this post would go something like: "If Palemoon can't implement web components, does the browser have a future?"

Re:Please consider not adopting Google WebComponents by newsletterguy on Tuesday March 17, 2020 @11:16AM (#22605639)
Well, it COULD mean the end of this browser, which i would not call a big loss, as it was always outdated and the makers ripped out vital security features like sandboxing or they have been unable to implement Mozilla implemented tor based privacy fixes!

It is better that the fans are learning WHAT COULD HAPPEN - because if they would not learn the truth, they are suddenly sitting around with a dead and even more outdated browser.

This is too important than to ignore it or not to post about it.