49

On April 21, 2020, Google announced that their Prettify syntax highlighter, that Stack Exchange uses, has been discontinued and is no longer being maintained. The repository has been marked read-only as well.

As such, no more languages will be added to the highlighter, and existing bugs with the highlighter will no longer be fixed.

Now that this highlighter is officially deprecated and no longer maintained, can Stack Exchange please either switch to another highlighter that is being maintained, or begin maintaining their own highlighter (possibly a fork of Prettify)?

In my opinion, the best thing to do would be to begin maintaining the syntax highlighter internally. This way, bugs and feature requests with it can be filed and tracked on meta sites, and changes to it can be made more quickly. Under the old system, bugs with it would take a long time to be resolved (since it was only maintained by random people on occasion), and when they were, it would take a lot of time for it for SE to eventually handle a feature request to deploy an updated version. The whole process would be drawn out and take 6-8 months-years. (As a matter of fact, I filed an issue with it back in 2014 and it still hadn't been resolved as of the discontinuation date.)

The best way to handle this would be to make an internal fork of Prettify, and start off with that.

I noticed some people would prefer using Highlight.js, which is actively maintained, but a prior request to change to that highlighter was declined for performance reasons.

This is not a duplicate of google-code-prettify seems dead since that was back in 2014 and the project simply languished (as opposed to being officially discontinued), and a few months after that question was posted, the project was back in action. However, that can't happen as the repository has been marked read-only, and probably won't happen anyway due to the official discontinuation.

To address animuson's comment:

I imagine that someone is simply going to fork this away and maintain it separately. To be clear: that hasn't been maintained by Google in many years. It was maintained by regular users who wanted to contribute to it and make it better. Nothing is stopping them from doing it somewhere else. [...] Some random Google employee archiving it doesn't break anything.

With the repository's archival, there is no longer a centralized effort to maintain the highlighter. It's quite possible that newer fixes might just end up in several independent forks that would have to be manually merged by SE.

Improve this question
15
  • 8
    I imagine that someone is simply going to fork this away and maintain it separately. To be clear: that hasn't been maintained by Google in many years. It was maintained by regular users who wanted to contribute to it and make it better. Nothing is stopping them from doing it somewhere else. And I see literally no reason to move away from it at this time, because what benefit does that achieve? Some random Google employee archiving it doesn't break anything.
    – animuson StaffMod
    Commented May 11, 2020 at 19:15
  • 12
    @animuson I don't see why SE should stick with a highlighter that was only being inactively maintained. Bugs with it would take a long time to resolve because only random people did so randomly, and when they were resolved, it would take a lot of time for it to eventually get deployed in SE. The whole process would be drawn out and take 6-8 months-years. Also, now, with the archival, there's no longer a centralized effort to maintain it, so new fixes might just end up in a bunch of independent forks. For those reasons, SE should switch to a highlighter that is actively maintained.
    – Sonic the Anonymous Hedgehog
    Commented May 11, 2020 at 19:19
  • 1
    And... you expect it to take less time with a different solution? It's not like we're going to hotlink to the JS file elsewhere. It would still require a dev to take the time to deploy modified files.
    – animuson StaffMod
    Commented May 11, 2020 at 19:21
  • 4
    @animuson Can't it be possible for SE to set up and maintain their own fork of Prettify, so that they don't have to switch to a different one yet can maintain it actively?
    – Sonic the Anonymous Hedgehog
    Commented May 11, 2020 at 19:28
  • 1
    I don't see why not. We do that with a bunch of other tools we use.
    – animuson StaffMod
    Commented May 11, 2020 at 19:30
  • 2
    @animuson I've edited the post to list it as a possibility. Hope this request hasn't been internally demoted as a result of not mentioning it in the initial post.
    – Sonic the Anonymous Hedgehog
    Commented May 11, 2020 at 19:33
  • 7
    @SonictheStay-HomeHedgehog As currently written, it sounds like you're asking for way more effort than SE just forking a project and using the fork. Saying things like "make the highlighter home-grown" give the impression you're asking for complete development of a new highlighter. If what you're really asking for is that SE use an existing highlighter, but you just want SE to control the repository, that's a much different ask then how I read what you've written here. Frankly, as this is currently written, I'm surprised it hasn't gotten a hard "no". I'd suggest rewriting to clarify.
    – Makyen
    Commented May 11, 2020 at 22:02
  • 1
    @animuson I've re-edited this to be a request to maintain an internal fork of Prettify. If this has already been triaged in the internal tracker, please reconsider this and re-triage it.
    – Sonic the Anonymous Hedgehog
    Commented May 11, 2020 at 22:18
  • @Makyen See above comment.
    – Sonic the Anonymous Hedgehog
    Commented May 11, 2020 at 22:18
  • Why would it go any faster with Stack Exchange? Why not a public open source project? Stack Overflow has counted 40 million software developers; it must be possible to recruit some of them (though offering stock options may no longer be "free" after Enron - I am looking at you, MDS).
    – This_is_NOT_a_forum
    Commented May 12, 2020 at 17:14
  • I agree it's long past time to move beyond Google Prettify. As animuson said, it's been effectively unmaintained for years. Even pull requests that have been submitted to fix bugs and add features have been ignored. Certainly no maintainer has been actively fixing bugs or adding features themselves. But your justification for why SE needs to maintain their own syntax highlighting engine makes no sense. It would be far better and easier for it to be maintained by the community, where SE devs could just pull the latest version. This could be a fork of Prettify or some alternative.
    – Cody Gray - on strike
    Commented May 13, 2020 at 7:38
  • 5
    I see a lot of discussion of forking here - for what it's worth that's effectively what happens every time we update our copy, hosted on our CDN...which is the case. If we did nothing, everything will continue working. Practically speaking, we'd most likely change this if and when it's a problem. I'd have a hard time saying it's a priority otherwise. Us being maintainers for not us (publicly) is a lot of weight/time (I know this far too well) - it's more likely we'd change to another project (e.g. highlight), but those have weight, perf, etc. that all needs investigation, and again: time.
    – Nick Craver
    Commented Jun 1, 2020 at 21:40
  • @YaakovEllis What are the plans? Will SE begin maintaining a fork of Prettify on their own? (As you tagged this as planned rather than as under review, I'm wondering what the plans are.)
    – Sonic the Anonymous Hedgehog
    Commented Aug 26, 2020 at 5:43
  • 2
    I would guess it would be moving to highlight.js
    – Journeyman Geek
    Commented Aug 26, 2020 at 6:34
  • 1
    @JourneymanGeek And it's done
    – Vadim Kotov
    Commented Sep 21, 2020 at 12:51

2 Answers 2

Reset to default
8

We've officially switched to highlight.js network-wide. See the announcement post for more details.

Improve this answer
12

Why not use the same stack as the one used by GitHub flavored markdown?
According to GitHub doc they use Linguist as language detector, which has a pretty long list of supported languages.

Improve this answer
1
  • 1
    I'd imagine SO purposely wants to do this rendering on the client-side rather than on their servers...
    – Josh Goebel
    Commented Oct 18, 2020 at 1:13

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .