How do their APIs compare?

These two projects operate at completely different layers, so "comparing APIs" really means comparing a small, focused gem's surface against a slice of a full-stack framework's. Here's the honest breakdown.

mislav/will_paginate: small, convention-based, data-centric API

will_paginate's public API is deliberately tiny and revolves around one concept: a "paginated collection."

• Model/query layer: Array#paginate(options) and ActiveRecord's paginate/page methods return a WillPaginate::Collection, which is just an Array subclass carrying current_page, per_page, total_entries, and computed total_pages [lib/will_paginate/array.rb:L3-L34] [lib/will_paginate/collection.rb:L44-L83]. Any third-party collection can plug into the ecosystem simply by exposing that same handful of readers, as documented directly in the module comment [lib/will_paginate/collection.rb:L4-L10].
• Lazy counting trick: Collection#replace infers total_entries from a short result set to avoid an extra COUNT query when possible [lib/will_paginate/collection.rb:L124-L137].
• View layer: a single will_paginate(collection, options) helper wraps a LinkRenderer class that does all HTML generation; it's designed to be subclassed to change rendering behavior [lib/will_paginate/view_helpers.rb:L6-L45] [lib/will_paginate/view_helpers/link_renderer.rb:L6-L45]. The base renderer's windowing logic (inner_window/outer_window) is factored into LinkRendererBase [lib/will_paginate/view_helpers/link_renderer_base.rb:L1-L78], and framework-specific renderers (e.g. Sinatra's LinkRenderer#url) just override a few protected methods like url(page) [lib/will_paginate/view_helpers/sinatra.rb:L5-L42].
• Safety-conscious defaults: the ActiveRecord finder specs show the library explicitly guards against parameter tampering (host/port/protocol/script_name injection into pagination links) [spec/view_helpers/action_view_spec.rb:L201-L215], and paginate avoids mutating caller-supplied option hashes [spec/finders/active_record_spec.rb:L261-L266].

This is a narrow, single-purpose API: a handful of public methods (paginate, page, will_paginate), a couple of extension points (LinkRenderer, CollectionMethods), and everything else internal.

rails/rails: broad, multi-framework API surface

Rails isn't one API — it's dozens of subsystems each with their own conventions. From what's in the retrieved data, Action Cable is a representative example:

• Bootstrapping via Zeitwerk autoloading: action_cable.rb sets up a Zeitwerk::Loader for the gem, explicitly ignoring generator/template dirs and deferring eager-load for adapters like Redis/PostgreSQL that pull in optional dependencies [actioncable/lib/action_cable.rb:L26-L47]. will_paginate has no autoloading machinery at all — it's a small set of required files.
• JS client + Ruby server split: Action Cable ships a compiled JS client (actioncable.js) alongside the Ruby server-side code, with its own deprecation shims (e.g. the renamed action_cable.js → actioncable.js warning) [actioncable/app/javascript/action_cable/index_with_name_deprecation.js:L1-L3] [actioncable/app/assets/javascripts/actioncable.js:L1-L10]. will_paginate has no client-side JS component.
• Test-infrastructure conventions across Rails as a whole: patterns like ActionView::Base.with(config_option: value) for scoped config overrides in tests [AGENTS.md:L91-L102], and a documented convention for where to find helpers, tests, and defaults (lib/*/helpers/, test/template/<helper_name>_test.rb, load_defaults version blocks) [AGENTS.md:L165-L171] — reflecting how much larger and more structured Rails's internal API/contribution surface is compared to will_paginate's few files.

Key contrasts