Request: SVGO playground on the website about svgo.dev HOT 14 OPEN

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.

from svgo.dev.

How does this plan sound? jakearchibald/svgomg#431

from svgo.dev.

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.

from svgo.dev.

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.

from svgo.dev.

(hopefully last) Vitepress update: I made a live preview over at https://ktibow.github.io/svgo.dev/
I didn't implement all of the plugin pages and I didn't implement a playground page, but you can view the source at https://github.com/KTibow/svgo.dev

from svgo.dev.

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

from svgo.dev.

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

from svgo.dev.

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.

from svgo.dev.

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

from svgo.dev.

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.

from svgo.dev.

I won't accept a PR that changes the stack of the website

Fair enough. I'm just worried since the website itself looks to have the same dependency outdatedness problems that SVGOMG had. I originally tried to upgrade the dependencies while keeping the stack but I failed at doing that.

from svgo.dev.

have the same dependency outdatedness problems

I'd like to think that svgo.dev doesn't have a significant problem with outdated dependencies considering the site is brand new, however Docusaurus 3 did come out shortly before it was published, so that may resolve some of your concerns.

I couldn't upgrade to Docusaurus 3 when it was time to go live because one of our dependencies (@easyops-cn/docusaurus-search-local) didn't support it yet, but that's since been resolved, so I can work on the migration soon.

I can't say I can relate to any of the issues you've raised, though. I'm actually very pleased with the developer experience, user experience, and performance of svgo.dev.

Legacy module loading -> ESM

Not an immediate concern.

Outdated, deprecated dependencies -> latest dependencies

It's favorable to be up-to-date, but so long as there aren't known security vulnerabilities it's not a pressing concern either.

Slow DX -> ESM-based server with HMR

No idea where this stems from, Docusaurus is very pleasant to work with and is comparable to similar tool chains. I haven't reviewed benchmarks, but real-world usage is great.

Old UI design -> clean theme

This is subjective at best, and while I'd like to review the design of the site, I think it's already very clean.

Finally, none of these are worth completely rewriting the project. There's nothing wrong with dependencies not being the latest release. Even if that was a problem, I'd prefer to work with maintainers to update them. ^-^'

from svgo.dev.

No idea where this stems from, Docusaurus is very pleasant to work with and is comparable to similar tool chains. I haven't reviewed benchmarks, but real-world usage is great.

Have you used Vite before? It's a really great DX.
sorry for wasting space in this conversation but I felt the need to clarify

from svgo.dev.

Have you used Vite before? It's a really great DX.

I haven't used Vite or VitePress. I was comparing Docusaurus to tools like VuePress, docsify, and Jekyll.

Briefly looking into VitePress, it does look good. Something very nice, if vitepress.dev is a good reference, the network transfer for their default theme is smaller than what Docusaurus' default theme outputs. I still haven't reviewed the developer experience, though.

However, I didn't say we won't change the stack because I prefer Docusaurus. In fact, I lean towards Jekyll myself. ^-^'

It's because it's not worth changing it when we already have a functional, performant, and accessible site. Now that it's been released, I'd rather commit to Docusaurus and contribute upstream, than drop it for the next stack, and then drop that for the next stack after, and so on. That's not sustainable.

sorry for wasting space in this conversation but I felt the need to clarify

No need to worry, though this is getting a bit off-topic admittedly, but it's fine for now!

from svgo.dev.