Request: SVGO playground on the website

[KTibow]

SVGOMG doesn't get any updates anymore. Add a playground to svgo.dev so that you can minify an SVG with SVGO there.

[TrySound]

Or we could just contribute to svgomg. It's not like completely unsupported.

[KTibow]

Its dependencies are out of date. Despite there being PRs that bring it back to up to date, it hasn't been updated for half a year.

It would make sense to use svgo.dev as it would make it more official, and we already have an architecture in place with things like a modern design and build stack and dark mode.

[TrySound]

Those deps do not affect user in any way. SVGO itself was not actively maintained for some time. Thanks to @SethFalco for bringing it back to life.

[KTibow]

Fair enough. However I still think that it would be better to transition to svgo.dev for the same reasons as before. I'm going to be away from my computer but I might try to implement this when I get back

[SethFalco]

I was exploring if we should do something like this, but opted against it because there are other clients already. However, it's true for SVGOMG at least that maintenance is lacking.

• SVGOMG, which was already discussed here
• OhMySVG

For now, I'll transfer this to svg/svgo.dev, but we can't commit to maintaining a playground yet. We can open room for discussion once svg/svgo has it's pending issues and pull requests back on track, though.

In other words, SVGO should perform it's current objectives well before introducing additional maintenance burden.

[KTibow]

I'll transfer this to svg/svgo.dev

I would've put this here but issues are disabled

but we can't commit to maintaining a playground yet

The site already has a playground for each plugin. This would just be as simple as making an explicit page.

update: I ended up trying to convert the site to VitePress and will send a PR once done

[SethFalco]

I would've put this here but issues are disabled

My bad! I made a mistake when creating the repository health files. Thanks for noting that.
I'll resolve this today!

This would just be as simple as making an explicit page.

Those demos would be a horrible experience for a playground, so we won't do that. When or if we take this on, it'll be something comparable with SVGOMG, or at least SVGR's playground.

You shouldn't call anything simple, though. Especially when it'll mostly take up another person's time.

Good software is planned, designed, and aims to provide value over alternatives, which we're not prepared to do for a playground right now. We could minimally fulfill the requirements… but that would be wasted effort compared to redirecting the user to SVGOMG, OhMySVG, or even Runkit if it's just going to be a text box with no visual options or code completion anyway.

If this is actually intended to supersede SVGOMG, then it's bound to grow in features and maintenance. That will introduce the burden I alluded to before, when we should be focused on maintaining SVGO. SVGO doesn't have many active maintainers right now, so now is a bad time to spread us thinner.

You're welcome to create your own third-party client, ofc. But you can't expect us to maintain it when we've struggled to find time to keep up with SVGO itself.

I ended up trying to convert the site to VitePress

I won't accept a PR that changes the stack of the website. You're welcome to contribute using Docusaurus and React, though.

At the point you're willing to put in that much work, I'd recommend you create your own client or fork SVGOMG yourself, though.

[SethFalco]

Or we could just contribute to svgomg.

I'm discussing this with Jake Archibald, the maintainer of SVGOMG, to see if I can join as a collaborator to help keep SVGOMG up-to-date.

No promises, but we'll hopefully be able to collaborate with SVGOMG! If this goes well, rather than maintain our own playground, I'd much rather put a link to SVGOMG in our navigation and recognize SVGOMG as the recommended browser client.

[jakearchibald]

How does this plan sound? jakearchibald/svgomg#431