RFC: Remove Polyfill Support from react-speech-recognition

[smorimoto]

Introduction

The react-speech-recognition library currently provides polyfill support for several speech recognition services such as Microsoft Azure Cognitive Services. With the emergence of remarkably accurate and performant speech-to-text (STT) services like ElevenLabs' Scribe, this RFC proposes removing all polyfill support to minimise the package and refocus its purpose.

Proposed Changes

This RFC proposes modifying react-speech-recognition to:

• Remove all polyfill support completely
• Focus solely on providing React hooks and components that handle the Web Speech API lifecycle

Reason

The primary value of react-speech-recognition is not in providing alternatives to the Web Speech API, but rather in its management of:

• Recognition lifecycle within React components
• Proper cleanup when components unmount
• State management for recognition results
• Browser compatibility detection

By focusing exclusively on these aspects, the library can reduce its footprint, simplify maintenance, and provide a clearer API.

Implementation Details

The implementation would involve:

1. Removing all polyfill-related code and dependencies
2. Simplifying the API to focus on Web Speech API integration
3. Updating documentation to reflect the new focus

Advantages

1. Smaller package size: Significantly reduced bundle size without polyfill code
2. Simplified maintenance: Focus on one API rather than multiple services
3. Clearer responsibility boundaries: Specialise in React integration with Web Speech API
4. Flexibility for developers: Freedom to choose and integrate preferred STT services
5. Future-proofing: Independence from needing updates for new STT services

Potential Concerns

1. Breaking changes: Existing implementations using polyfills would need updating
2. Learning curve: Developers would need to learn third-party service integration 3. Fragmentation: Different projects might implement integrations differently

Conclusion

By focusing exclusively on providing an excellent React wrapper for the Web Speech API, react-speech-recognition can become a more maintainable, leaner library that does one thing exceptionally well. This approach aligns with the React community's preference for smaller, focused libraries over larger all-in-one solutions.

[smorimoto]

@JamesBrill I'd love to hear your opinion!

[JamesBrill]

My initial take is that I strongly disagree. If I'm a developer who wants both the convenient React-based interface of this library and be able to use my third-party STT service of choice, then it's not clear how I could do that without a means of connecting the two. Without the polyfill "backdoor", it's not clear how this library would work with any third-party service - I'm interested to hear the alternatives you're thinking of. To address each of the 5 advantages you suggest:

1. Smaller package size: I'd argue this package is already very lean and the polyfill aspect of it is relatively small. It's the polyfill provider who has to do most of the heavy lifting in terms of logic - this library just uses it like any implementation of the W3C spec
2. Simplified maintenance: you said it currently has to focus on multiple services. But this isn't true - the library only has to integrate with the W3C spec. I've previously documented the various polyfills and their limitations, but that was purely documentation to be of service to library users - those polyfills are implemented outside of this library
3. Clearer responsibility boundaries: again, this library just has to integrate with the W3C spec and doesn't have to know about the idiosyncrasies of any third-party services
4. Flexibility for developers: you said "freedom to choose and integrate preferred STT services". This is exactly what polyfills enable
5. Future-proofing: you said "independence from needing updates for new STT services". Again, this isn't necessary as the burden is on polyfill authors to implement the W3C spec

So I'm really not clear on how this library could be used with STT services without polyfill support. If we remove it, this library becomes incredibly difficult to use, if not impossible, with anything but the browser implementation of the Web Speech API, which is limited or non-existent on some browsers. Therefore, without that support, this library is unusable for commercial applications where cross-browser support is a must. Polyfill support was added to empower React developers to build commercially viable web speech applications.

If you can propose a better way to integrate this library with third-party services that isn't a polyfill of the W3C spec (I can't think of a better interface than that), then please share.