search

Automattic / juice

Juice inlines CSS stylesheets into your HTML source.
MIT License
3.07k stars 216 forks source link

Maintainer Wanted #399

Open jrit opened 2 years ago

jrit commented 2 years ago

I've been maintaining juice and web-resource-inliner for about ~six~ seven years now. I took over as maintainer because the package needed a lot of work to do what I needed to do for my job at the time. But, I just don't use juice much anymore and I think it makes more sense for someone who is an active user and contributor to take over as maintainer.

If you'd like to take over as maintainer or have an opinion about who you'd like to maintain this repo please comment below.

@TrySound maybe?

titanism commented 1 year ago

@jrit we'd be happy to help maintain it (we maintain email-templates already)

jrit commented 1 year ago

@titanism your github activity is private, can you provide some verifiable background?

titanism commented 1 year ago

Hey there @jrit! We're the team behind https://forwardemail.net and maintain a lot of npm packages, e.g. https://github.com/ladjs/superagent!

jrit commented 1 year ago

@titanism I know you said that, but your github profile doesn't establish that so I'm unable to verify who you are.

husseinalhammad commented 3 months ago

This could be of interest to:

husseinalhammad commented 6 days ago

I am trying to discuss this with a few that I think care and understand the importance of Juice in the current email ecosystem. It will help to understand where Automattic stands on this, @jrit. It sounds like you took this on personally, but the repo is owned by Automattic.

revelt commented 6 days ago

To add 2p., sorry I can't take on the responsibility. If I did, I'd at least rebase it to be modular, split into many packages; ideally, all infra should be compiled, written in Rust.

There are different schools of thought on how to build email templates. In some, juice fits in, in others, it would be frowned upon. Moreso, the type of templates, transactional vs. promotional, completely changes the infra requirements and coding style — for example, on one end, you might have a "slice-PNG-send-daily" fashion newsletter; on another end of the spectrum, fifty similar-looking, component-based transactional templates consuming five static img assets in total. All these business factors affect the technology setup choices, and juice is fitting one narrow band in the spectrum.

Personally, for small projects I'd simply code by hand leveraging code editor snippets but retain full control over head styles; for large transactional projects I'd use a capable templating engine (like nunjucks) plus atomic CSS ( generation plus unused class removal ). For large promotional projects, having some CMS is more important as clients brief campaigns daily, why waste time filling Word briefs when client's input can be tapped in the template directly.

For the record, I never used juice or similar inliner in my whole career (nearly 10 years before I moved on to Web Dev) — all agencies and ISP's Professional Service departments I've been with would code all <head> CSS by hand.

PS. Love and hugs to fellow email developers, I hope you've found the beauty in the email craft, the money is not everything.

husseinalhammad commented 6 days ago

Appreciate the response, @revelt.

I don't think using a CSS inliner is uncommon at all. I believe Juice is essential to many in the email space (including commercial products). It gets 900K - 1M weekly downloads via npm. This is similar to Svelte and more than nunjucks, Astro and Eleventy - all of which are popular, have much bigger target audiences and a lot broader use cases. I realise this is not a fair comparison, but it is not a bad indicator.

I know not everyone uses it. And not everyone wants or needs to use it. But I think a lot more than a narrow band in the spectrum does.

jrit commented 6 days ago

Automattic has never had any role as an organization in maintaining Juice, it just lives under their org for historical reasons. I have also never worked for Automattic. I'm committed to continuing to merge PRs and be a generally good steward until someone else steps in, but I feel a maintainer that has more day to day use of the package would be preferable.