Talk:Comparison of browser engines/Archive 2

Archive 1

Archive 2

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)

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)

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)

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)

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)

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

NetFront

Just here to highlight that NetFront pre-version 3.5 ran on an original rendering engine, titled "NetFront". It didn't switch to WebKit until version 4.0. This is clear in the Dreamcast browser, Sony PSP browser, early versions of the PS3 browser (anything before system software 4.10), NetFront 3.5 and below for Windows Mobile, and the PS2 browser.

The rendering engine isn't even from that long ago considering that Tasman is listed, which ended long before the NetFront rendering engine did. — Preceding unsigned comment added by Lucid00 (talk • contribs) 21:12, 12 December 2019 (UTC)

Do you have a valid source for this info? Otherwise it shouldn't be added to the table. -Pmffl (talk) 18:26, 13 December 2019 (UTC)

Quirks Mode article on Mobile browsers [1] This highlights the Linux mobile version and that it was using it's own rendering engine. Access Company History [2] Mentions when NetFront was first developed (long before WebKit existed), and when it switched over to using WebKit. -Lucid00 (talk) 13:30, 15 December 2019 (UTC)

I don't consider either a valid source for claiming that the original NetFront browser had a distinct rendering engine. How was its rendering any different than Dillo or other lightweight browsers without a distinct engine? They're relatively-small, monolithic browser codebases. (Contrast that with NetSurf that lists all of its unique internal components on its homepage. That's why it was added to the table, as discussed in a prior section here.) -Pmffl (talk) 21:37, 15 December 2019 (UTC)

"They're relatively-small, monolithic browser codebases." I wouldn't say any of that applies to NetFront. I honestly can't be sure because that rendering engine was proprietary, but ending off at 3.5 it supported SVG, plug-ins (namely Adobe Flash Player), a JavaScript spec that for it's time was up to date. The browser even went out of it's way to simulate Internet Explorer. Also here's a PDF file from Sony that shares what the PS3 version of NetFront was capable of back on system software 3.10 (this used to be linked to from the PlayStation website) [3]. On PSP it was even expanded to power the Internet Radio feature, sporting AJAX functionality and audio streaming (via non-standard APIs).

Also off of this topic, you edited my listing of Tasman to say it's a "Trident counterpart for Mac OS". It's not, the two are entirely different codebases. They're not even compatible with the same content. At the time it was released, Tasman followed web standards more to spec than Trident did. -Lucid00 (talk) 00:01, 17 December 2019 (UTC)

Servo is dead, right? Everyone was laid off in August...

should we mark as discontinued?

No, it's still maintained. I recently rewrote the Servo article to explain this. -Pmffl (talk) 18:36, 3 May 2021 (UTC)

Is KHTML really "discontinued"?

The table on this page lists KHTML as "Discontinued", but KHTML states that it is still actively maintained, and it appears to still be the engine for Konqueror. What exactly does it mean to be discontinued here, and does that apply to KHTML?

Yes, based on lack of releases in several years. That's a long time for a browser engine. -Pmffl (talk) 21:40, 8 May 2019 (UTC)

Note: I've expanded the Status critera in the article and the template at the bottom of the page. It's now properly granular. -Pmffl (talk) 18:37, 3 May 2021 (UTC)

WebKit platform support

There is no browser for Windows that uses WebKit. But WebKit itself is available as nightly builds from Apple, so I guess it's fair to say that it is "supported". EDIT: Actually Windows has been removed from the Webkit Download section. On Github they now say you have to build it yourself. Not sure if that counts as "supported"?

However, I don't think there is any browser for Android that uses WebKit? The WebKit Wiki page also doesn't list Android as a supported platform. I'm sure it would be easily possible to port WebKit (it runs on Linux after all) but still - it's not really supported is it? — Preceding unsigned comment added by 86.17.94.33 (talk) 16:02, 16 June 2022 (UTC)

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 [4]https://eylenburg.github.io/browser_engines.htm there was an update in 2015). 86.17.94.33 (talk) 09:49, 2 January 2024 (UTC)

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)

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)