Talk:List of JavaScript engines

Inclusion criteria

As per WP:NLIST, I propose that only engines with an article be included in this list.

Other similar articles that follow the same rule include List of Python software, List of free and open-source software packages, and Comparison of integrated development environments.

I think this discussion is also of interest: Talk:List of Python software#Recommended Inclusion Criteria Uwsi (talk) 21:18, 22 September 2025 (UTC)

I propose that engines that are part of products that have articles about them (i.e. Opera, Graal, LibJS/Ladybird, etc) have to be also included, it's simply illogical otherwise (e.g. JavaScriptCore - one of the big 3 engines is currently just a section under WebKit). As well as any engines with enough third-party sources that in principle can warrant writing an article. Ivanktw (talk) 21:41, 22 September 2025 (UTC)

Also note that in contrast to countless Python software (#1 or #2 programming language today), the number of non-toy JavaScript implementations today, especially of recent standards (ES6+ is a fairly complex language) is probably a dozen or two at the most. Ivanktw (talk) 21:49, 22 September 2025 (UTC)

I see no problem with that.

But I still think the engine should be notable and have a verifiable reference, so a link to the engine's homepage or GitHub page should not be enough. Uwsi (talk) 22:00, 22 September 2025 (UTC)

I added some third-party references that I could find in my edit. I agree, if hardly anyone writes about an engine besides its own homepage/repository, it's probably not interesting/notable enough to be listed. Ivanktw (talk) 22:07, 22 September 2025 (UTC)

I'd also like to note the obvious fact that many entries on this list are developed by for-profit corporations. Wikipedia is many things, but it certainly should be more than an advertising space for corporations. Overindexing on an abstract concept of notability structurally preferences corporations whose PR teams can whip up third-party wikipedia-approved citations, and is often a form of rules lawyering employed to serve corporate interests and not the best interests of wikipedians.

To be frank, it looks bizarre to have multiple completely defunct engines on this list. Why is Brendan Eich's prototype mentioned here at all? The discussion on this talk page uses terms like "commercially viable"—keep Brendan Eich in the history section! It is incredibly unserious to be edit warring GraalJS for notability while the list itself contains several completely defunct engines.

The edit warring over individual engines (which from the page history is happening very recently, openly and repeatedly) needs to stop. It seems pretty clear from the Eich entry that the single monolithic list as it stands has no clear charter for inclusion. Would having multiple distinct lists help to diffuse the edit warring over notability?

What would the "primary" list cover? Full ESNext support? Maybe we could also have a second list for "development" engines, and a final "historical" list? There are proposals for "maintained" and "products used in" columns elsewhere on the talk page, which would be very useful info for the "primary" list, but less relevant for the "development" and "historical" lists.

I'm personally very interested in "development" stage JS engines. It's well-known that implementing javascript is a daunting task, but this page has absolutely no info about current research efforts in the area. Instead, it has Brendan Eich and v8. I think it's more likely than not that wikipedia users who go to look at this page are not interested in hearing about Brendan Eich and v8 again, but in learning about any engines that aren't already well-known or especially notable yet.

In summary:

- The edit warring needs to stop immediately. This is supposed to be a resource for wikipedians and it's impossible to use history tools with all that churn.

- I propose splitting into three lists "standards-conformant", "development", and "historical" (possibly each with their own article section). The distinction of "standards-conformant" should be relatively objective and should avoid edit warring over inclusion in the first list.

- I claim that cataloguing the development of new JS engines is a really important resource this page can provide for wikipedians. Making a new JS engine is not like corporate advertising, it's a serious effort that's difficult to get someone to write a third-party wikipedia-friendly analysis of. "Notability" is not the right metric for inclusion here.

I'm really hoping the above is clear enough to inspire wikipedians to recognize the potential for this page. Edit warring over notability while Brendan Eich's prototype is on the list is very unserious and it's polluting this shared resource. Lcdrovers (talk) 21:24, 30 September 2025 (UTC)

The number of independent JavaScript ES6+ engines is a bit more than a dozen, but yeah, it is generally true that there exist more hobbyist implementations of anything than commercially viable ones. bkil (talk) 09:34, 23 September 2025 (UTC)

Keep notable historical engines

A separate questions from notability. An encyclopedia ought to list notable facts regardless of when they had happened, otherwise we would start pruning history articles as well after 10 years or so. For example, Mozilla Mocha was the most widely used engine around the world before Gecko and SpiderMonkey came along, so you should not remove that just because it was "long ago". bkil (talk) 09:51, 23 September 2025 (UTC)

A column to specify products used in

I would prune the prose description and migrate some of the more interesting aspects into structured values. For example, many engines are used in multiple products. In some cases, the engine does not have an article itself, while the product does. bkil (talk) 11:18, 23 September 2025 (UTC)

That column would totally get dominated by the few big engines, 'nobody gets fired for choosing IBM' as the old saying goes, the list would be bigger than the description and eat precious horizontal space. For most engines in the list, description already leads with the primary product - that's probably good enough. Excess details about engine's internals should indeed be better pruned, moved to engine's page if it has one. V8's description is pretty nice I think - most of it is about products. Ivanktw (talk) 15:57, 23 September 2025 (UTC)

For an overview table, the description is too big. Almost all entries only have one or two notable products it got embedded in, with the notable outliers of Blink and Webkit. Listing these two on a chapter-footnote after each table would probably work reasonably well. Or if you insist, only list the main one in that column, and list others in the description, but again, at a very specific part of the description (probably the very end of it) bkil (talk) 10:18, 24 September 2025 (UTC)

Separate table for maintained entries

In my own, much bigger collection, I've decided to list entries separated by status for a better overview. Experimental and planned ones are not relevant for Wikipedia, but it would be worthwhile to split ones enjoying active security patches from ones of historical significance. bkil (talk) 11:20, 23 September 2025 (UTC)

Perhaps, these could be color-coded with some third color for the first column, but I'm not sure what templates exist for that besides {{rh}}/{{rh2}}. Or unmaintained/historical ones be moved to the bottom, while keeping maintained ones interspersed in the top part of the table, close to related engines/languages, with the same {{rh2}} purple highlight and add something like 'not actively developed' to its wording. Ivanktw (talk) 16:11, 23 September 2025 (UTC)

Unmaintained ones are already color coded! You see how difficult it is to see? Hence why I suggest to split the table instead of the current color coding. bkil (talk) 10:16, 24 September 2025 (UTC)

Ah so you're suggesting to split off historical/unmaintained engines into a separate second table, and color code the no-longer-developed but maintained engines (Rhino, Nashorn, maybe ChakraCore etc) in the first table? That sounds like an improvement to me. Ivanktw (talk) 01:33, 25 September 2025 (UTC)

There is nothing unmaintained in Rhino. I urge you to take inspiration from my similar comparison table I linked earlier. I consider something maintained if it received (security) patches in the past 2 years and unmaintained otherwise (especially if its repository got archived, certificate or domains expired, pull requests unmerged, issues unanswered, etc). There is no clear criteria of what would be considered "historical", especially if it still accepts contributions. You may want to introduce the artificial limitation of whether it contains unfixed vulnerabilities, but researching and maintaining that would be an unreasonable amount of effort. bkil (talk) 07:37, 25 September 2025 (UTC)