Future of Engines: Will whatsapp-web.js remain supported as a first-class citizen alongside Baileys?

[lucascampodonico]

Hi everyone, and first of all, thank you to the creators and contributors of OpenWA. This is an amazing project and has been incredibly helpful for building stable API integrations.

I noticed that Baileys support has been mentioned/worked on recently. While Baileys is an absolute game-changer in terms of performance (consuming only ~20MB of RAM compared to the ~150MB+ required by Puppeteer/Chromium), it introduces a major architectural dilemma for some production use cases.

The Dilemma: Performance vs. Ban Safety

For SaaS setups where we host personal or primary corporate WhatsApp accounts for paid clients (charging a monthly fee per connected account), account safety is the absolute #1 priority:

1. Ban Risk with Baileys: Since Baileys acts as a reverse-engineered client on top of the multidisplay WebSocket protocol, minor protocol updates or suspicious packet patterns can lead to immediate phone bans. Losing a personal/business account is catastrophic for clients and can ruin a SaaS reputation.
2. Safety with whatsapp-web.js: By using a real headless Chromium instance, WhatsApp servers see the connection as a standard, legitimate "WhatsApp Web" user. Even though it is a memory hog, the ban risk is incredibly low.
3. The Business Model: At $25/month per client, paying for extra VPS RAM to support browser-based instances is highly profitable and easily justifiable to guarantee account safety.

The Question

Given this context:

• Will the whatsapp-web.js engine continue to be actively maintained and updated as a first-class citizen in this repository?
• Is there any plan to keep both engines updated in parallel, or is the future roadmap heavily shifting focus toward Baileys?

I’d love to hear the thoughts of the maintainers and other developers running similar business models!

Thank you again for this fantastic library.

[rmyndharis]

Hi @lucascampodonico,

Thank you for such a thoughtful and well-articulated post — and thank you for the kind words about the project. You've captured the performance-vs-safety trade-off really clearly, and it's exactly the kind of consideration we want OpenWA to handle gracefully rather than force users to pick a side.

So let me address the roadmap question directly: yes, whatsapp-web.js will absolutely remain a first-class, actively maintained engine alongside Baileys. This isn't an either/or decision for us. Our philosophy is that different production needs call for different engines, and we intend to support them in parallel:

• whatsapp-web.js — for reliability and ban-safety. As you noted, driving a real headless Chromium session means the connection presents itself much like a standard WhatsApp Web client. For SaaS setups hosting personal or primary business accounts, that lower risk surface is often worth the extra memory footprint, and we want to keep that path solid and well-supported.

• Baileys — for performance and efficiency. The dramatically lower RAM usage makes it ideal for high-scale or resource-constrained deployments, and we'll keep investing in it for users who prioritize throughput.

More broadly, our vision is for OpenWA to be engine-agnostic: a consistent, stable API layer on top, with the freedom to choose the engine that fits your use case underneath. If other promising engines emerge down the line, we're fully open to supporting those as well — the goal is to give you options, not lock you into one architecture.

One small but honest nuance worth keeping in mind: both engines are unofficial clients from WhatsApp's perspective, so neither is truly ban-proof. In practice, bans are often driven as much by usage behavior — message volume, messaging numbers that haven't saved you as a contact, brand-new numbers, spam reports — as by the engine itself. whatsapp-web.js meaningfully lowers the risk surface, but healthy sending patterns and proper account warm-up still go a long way toward protecting your clients' accounts.

Thanks again for raising this — it's a genuinely valuable discussion for anyone running multi-account production setups, and it helps validate that the dual-engine (and beyond) direction is the right one.