![]() It's an entirely different story when the developer basically throws up his hands and tells their users they give up because xxx is too hard. It's one thing when a developer moves on from a project and leaves it in an unfinished state. I choose the applications in my workflow for specific reasons or for some unique value that they offer. The fact that Web Components specifically makes it harder to parse content (for archival or indexing purposes, etc.) is a separate issue, and for it, it doesn't matter if it's standard. It's a step backwards from gaining a more diverse browser ecosystem. It gets harder and harder to make a new web engine from scratch. > The more additional "features" are tacked on to these components, the less likely it is for non-Google clients to be able to display sites in full or properly. This is what I believe Pale Moon is getting at when they say: ![]() Isn't the point of a standard to help foster a rich ecosystem of diverse, interoperable implementations? I feel that a standard that evolves too fast (as made possible by an implementation monoculture) fails at fostering one. ![]() With Firefox's 4.5%, I don't think they can do anything but chase after the Chrome guys to wherever they decide to take the web. Indeed, with Chrome's 64% in market share, anything they do becomes "standard" automatically. Multiple implementations exist.Īre you sure it's not Google that's controlling what's to become "standard" and Firefox that chases after them? And I say Firefox specifically, because, besides Safari, they seem to be the only other implementation on the market. There are comments right in this same thread that confirm Pale Moon's statements about the inability to save or archive pages. What exactly are you saying is untrue? Can you quote the part? > It takes away from the point when it's untrue Why does it matter that it was Pale Moon that brought it up this time? If I or anyone else would have written the post instead of them, would then people focus on the issue instead of on who brought it up? This isn't the first time the topic of browser monoculture has been brought up. So, in the absence of some huge population of skilled developers volunteering to pitch in for free, their project is kind of stuck between a rock and a hard place. They could rebase onto a newer version of Firefox that did have that muscle, but they'd lose support for all the legacy technologies they forked away to keep in the first place and re-implementing all those APIs on their own would be just as prohibitively large a project as tuning up their engine on their own would be. My suspicion is that, when Pale Moon asks you not to use Web Components, they're doing so because their engine is old, it doesn't have the necessary muscle to deal with things like shadow DOM in a performant fashion, and they don't have the resources necessary to give it that muscle. (Pale Moon last rebased itself on mainline Firefox circa Firefox 52, which shipped three years ago.) As a result, Pale Moon doesn't include all the performance improvements that shipped with Firefox Quantum, along with various other "modern Firefox" improvements like not running all tabs in a single process. If keeping up support for those old technologies and keeping up with the latest improvements in Firefox sounds like a lot of work for a small team to tackle, that's because it is. The purpose of the fork was to retain support for various legacy technologies that mainline Firefox was abandoning, such as NPAPI plugins, XUL/XPCOM, and old-style themes. ![]() Some context that could possibly make the reasoning behind this more clear.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |