Jump to content

Talk:Comparison of browser engines

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
This is an old revision of this page, as edited by Pmffl (talk | contribs) at 18:05, 10 January 2024 (Presto still used in Opera Mini). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

Adding Eww (Emacs web browser and engine)?

Eww_(web_browser) is a rendering engine integrated in Emacs since version 24.4. — Preceding unsigned comment added by ArneBab (talkcontribs) 07:11, 7 July 2017 (UTC)[reply]

A little while ago I reverted the addition of Eww here. I hadn't heard of it before and seeing a few minutes of it on Youtube shows that it's an extremely limited browsing capability baked into Emacs. (It's early 1990s style browsing.)
Here's the current problem with Eww as it's classified on Wikipedia: it's categorized as a web browser and written about as such (and is in the web browser template). If it's a stand-alone browser (albeit with extremely limited capabilities) then it cannot also be classified as an engine too. It would have to be one or the other. As it stands, it's a browser here on Wikipedia, not an engine. --Pmffl (talk) 19:17, 20 October 2022 (UTC)[reply]

I revisited this today and just rewrote the Eww article. It is indeed a lightweight browser, and is certainly not a browser engine. (There are underlying libraries in Emacs required for it to run.) So that should settle this issue here. --Pmffl (talk) 19:53, 22 October 2022 (UTC)[reply]

Also, for reference, see this edit. -Pmffl (talk) 01:58, 1 September 2023 (UTC)[reply]

Inclusionist vs deletionist

These are completely subjective preferences. But User:Pmffl claims to be able to explain why these points are "wrong" on the talk page so I'll bite.

  1. Links to Comparison of layout engines (XML), Comparison of layout engines (DOM). Comparison of layout engines (ECMAScript) and Comparison of layout engines (SVG) are at least as relevant here as they are on Comparison of web browsers.
  2. Category: Layout engine comparisons should appear beside Category: Browser engine comparisons unless you want Comparison of layout engines to no longer redirect to Comparison of browser engines.
  3. Dillo is not actively developed but that doesn't matter. Since the project is open source, it doesn't immediately stop working on all the platforms listed here as soon as someone decides to stop adding new features.
  4. Hubbub is actively developed and NetSurf is modular enough for it to be called an engine so it should clearly be here. If you think it's not well known, all the more reason to put it in Wikipedia.
  5. Sourced facts about the selection of browser engines also give us a chance to teach people something new. Judging by other types of software, people could easily be surprised to learn that all the engines they've ever used are written in C++ and forked from either KDE, Netscape or MS.

Connor Behan (talk) 02:41, 5 February 2019 (UTC)[reply]

No, not completely subjective. Point 3 is irrelevant because Dillo is a lightweight browser, not a browser engine. Hubbub is a parsing library (as stated on its launchpad page), so not a full-fledged layout and rendering engine.
For point 5, programming language is a minor detail for this page. I don't think it merits inclusion. It's really only relevant to browser devs, whereas this article should be suitable for the lay public.
As for layout engine comparisons, the page had nothing but browser engines before which is why it redirects here now. This is not to say other types of layout engines couldn't have comparison pages, but that's new content that would have to be created on separate page(s). -Pmffl (talk) 23:47, 5 February 2019 (UTC)[reply]
I take back the request for Dillo because indeed there is not an engine that can be cleanly separated. But for NetSurf there is one. It's called "Hubbub + LibCSS + LibDOM". The only difference I can see compared to "Xul + Xpcom + Thebes" is that there's no marketing name like "Gecko" to encompass the whole thing.
You mean the lay public who just wants a browser to work and doesn't care what engine it uses or even realizes that a browser engine is a thing? No, the audience of a software comparison page is on the technically savvy end. They may not be browser devs but it's fine if a page has something for everyone. A language column and a simple note about forking history does not take up anywhere near as much space as a niche tag-by-tag list at Comparison of browser engines (HTML support). Connor Behan (talk) 20:17, 6 February 2019 (UTC)[reply]
After posting yesterday I actually took a closer look at NetSurf to verify its claim of having its own engine. Since the homepage lists all of their custom libraries, I agree their homebrew combination contitutes a distinct browser engine. So I added it to the table now, and will add it to the template.
But I still disagree about adding the programming language. That info is readily available at each engine page. By "lay public" I don't just mean clueless users, but non-technical folks who are curious to learn more about how browsers work. A Language column is TMI for them. -Pmffl (talk) 04:35, 7 February 2019 (UTC)[reply]
Thanks. The piece I just added mentions that some of these engines have a shared history. Connor Behan (talk) 23:11, 8 February 2019 (UTC)[reply]
"Dillo is a lightweight browser, not a browser engine." We need some strict rules for this article, because by this criteria Netscape Navigator 0.9 - 4 aren't running a real browser engine, despite being the groundwork for Gecko an engine listed here. Gecko is either valid or it isn't. - Lucid00 (talk) 19:07, 15 December 2019 (UTC)[reply]

Criteria for being an 'engine'

This is in response to Lucid00 (at the end of the thread above) about the criteria for what should be considered an engine. In principle it's not that hard to define. The browser engine article already does a good job of this, though what's covered there is most applicable to the mainstream engines (which collectively account for over 99% of actual browser usage).

It's a bit trickier for the tiny niche hobbyist projects, like NetSurf and LibWeb. The consensus reached above on NetSurf is a good guideline, in that the set of libraries and components that can be called an "engine" could, in theory, be used by another group of hobbyists to make a different browser. This is, after all, at the heart of what a software engine is: a large component that can be reused for a different software project. However, the nature of these types of hobby projects is heavily DIY: the lure of designing and implementing their own new thing is what tends to motivate them. But this doesn't invalidate the design of the software to feasibly be reused by a different project (even if that never actually happens). --Pmffl (talk) 02:17, 1 September 2023 (UTC)[reply]

Support for Irrelevant standards

I'm writing this because an IP editor has twice added JPEG 2000 to the image format table. I've removed it both times because it's irrelevant to the real Web; only Safari supports it, so nobody uses it. I'm of the opinion that only relevant stuff should be in those tables. -Pmffl (talk) 14:07, 22 July 2023 (UTC)[reply]

I also removed JPEG XL for the same reason. Google decided not to support it in Chrome, so therefore it's irrelevant to the real Web. -Pmffl (talk) 18:32, 24 July 2023 (UTC)[reply]
I would argue that JPEG XL should be included. This was big news when Google removed it - most likely due to conflict of interest of the relevant employees - and again when Apple added it. It's also supported by Pale Moon, Firefox Nightly and various Chromium and Firefox forks.
It's arguably the best and most versatile image format we have at the moment, strictly superior to Webp and mostly superior to Avif, with a wide industry backing from companies such as Meta and Adobe, and the unique ability to losslessly compress legacy JPEGs.
I would strongly suggest adding JPEG XL back, even if it's just to show how Blink is the one engine holding us back. Isnt that the point of the engine comparison? Right now it just shows that every engine supports every format. Pointless.
Besides, APNG and BMP are arguably less relevant than JPEG XL. I've never seen them used anywhere on the web. 86.17.94.33 (talk) 08:00, 4 August 2023 (UTC)[reply]
None of those arguments matter compared to lack of Blink support and thus doomed to irrelevance on the Web. And I disagree with the "Pointless" opinion. The point of an encyclopedia is to be informative for a wide range of readers (some with little or no technical background). So in this article's Support section, listing what actually matters on the Web is the point.
(In that vein, I agree that APNG is likely irrelevant too. I never heard of it outside of this article, but since the major engines all support it, it's possible that a website could use it.) -Pmffl (talk) 19:49, 6 August 2023 (UTC)[reply]
Just deleted APNG from the table, as discussed above. Having regular PNG is enough to be listed there. -Pmffl (talk) 19:55, 6 August 2023 (UTC)[reply]
And removed BMP too. I recall them long ago on the Web, but just another tiny niche format on the Web these days. -Pmffl (talk) 22:13, 6 August 2023 (UTC)[reply]
It occured to me today that an explanatory note about Blink dominance would be a helpful addition. So I added one. This seems like a good compromise on this matter. -Pmffl (talk) 17:41, 7 August 2023 (UTC)[reply]

Presto still used in Opera Mini

I added a comment that the Presto engine is still used in Opera Mini when the data savings mode is enabled and set to "extreme". First, the browser will warn you that this might break some websites. Then, the user agent is changed from the usual OPR/Blink one to, in my case, Opera/9.80 (Android; Opera Mini/77.0.2254/191.334; U; en) Presto/2.12.423 Version 12.16

I suspect that this is server-side rendering using the Presto engine, because that's how Opera Mini used to work in the olden days and e.g. use the Presto engine on iOS. Also, because just changing the browser engine won't magically save data.

There's also a version of Opera for basic phones (not Android or iOS) and I am quite sure that this also uses server-side Presto rendering.

Nevertheless I believe it's fair to say that the engine itself is discontinued and they're just using the last version from 2013 to render websites. (Actually according to [1]https://eylenburg.github.io/browser_engines.htm there was an update in 2015). 86.17.94.33 (talk) 09:49, 2 January 2024 (UTC)[reply]

That's interesting. It's now a footnote explaining the server-side Presto usage on feature phones. -Pmffl (talk) 22:42, 8 January 2024 (UTC)[reply]

Since Presto is still used commercially for some people's actual browsing (on low-end phones), it should be classified as Maintained here. I'm making that change now. -Pmffl (talk) 18:05, 10 January 2024 (UTC)[reply]