Skip to content

Detailed 1.0 Analysis 2026

Jump to bottom Edit New page
Nathan Esquenazi edited this page Mar 29, 2026 · 1 revision

Padrino 1.0 Roadmap — Fresh Audit (March 2026)

A modern look at what's really remaining for an official 1.0 release, revisiting the original roadmap from 2013-2017 against today's codebase (v0.16.1).

Executive Summary

Padrino is much closer to 1.0 than the old roadmap suggests. The core framework is solid — Sinatra 4, Rack 3, Ruby 4.0 compatible, minimal dependencies, strong parameter protection, and a clean custom router. Most of the original 2013 roadmap items are done or superseded.

What's blocking 1.0:

  1. Admin UI is stuck in 2013 — Bootstrap 3, LESS stylesheets, CoffeeScript. Needs a full modernization pass (Bootstrap 5+ or Tailwind).
  2. No coherent authentication strategy — The admin has session-based auth with BCrypt and role-based access control, but there's no reusable auth module for non-admin apps, no token/API auth, and no documented path for OAuth or JWT.
  3. Generators carry dead weight — Dojo, Prototype, MooTools, Compass are all abandoned projects still offered as options.
  4. Documentation hasn't kept pace — 0.15.x and 0.16.x features (ParamsProtection, Rack 3, Sinatra 4) are under-documented.
  5. Ruby version floor too low — Supporting EOL Ruby 2.7 in a 2026 release undermines the "modern" message.

What doesn't need work:

  • Routing (custom PathRouter is clean and fast)
  • Rendering (reusable across core, helpers, mailer)
  • Reloading (mtime-based, dependency-tracked, mutex-protected)
  • Logger (thread-safe, configurable, benchmarking support)
  • Dependencies (only ~8 runtime gems total)
  • CSRF protection (built-in, well-tested)
  • Mass assignment protection (better than Rails strong_params)

The framework doesn't need a rewrite. It needs a polish, a cleanup, a real auth story, and the confidence to call it 1.0.

Original Roadmap Scorecard

Original Item Status Notes
Use pendragon / remove http_router ✅ Done (differently) Custom PathRouter replaced both — clean, fast, well-tested
Simplify routing syntax ⚠️ Partial Routing works well but controller syntax could still be simplified (#747)
Prevent mass assignments (#905) ✅ Done ParamsProtection module — arguably better than Rails strong_params, supports type coercion
Rewrite admin with Bootstrap ⚠️ Outdated Admin uses Bootstrap 3.0.0 — needs upgrade to Bootstrap 5+ or Tailwind
Better multithread support (JRuby) ✅ Adequate Thread-safe logger, reloader, and router. JRuby tested in CI. Ractor not needed for 1.0
Rewrite mailer (less patching) ⚠️ Acceptable Still patches Mail::Message but minimally — mostly init + rendering integration
Rendering reusable everywhere ✅ Done Padrino::Rendering used across helpers, mailer, and core
Rewrite reloading logic ✅ Done Custom mtime-based reloader with dependency tracking, mutex-protected
Rewrite logger ✅ Done Custom thread-safe logger with colorization, benchmarking, per-env config
New website using padrino-docs ✅ Done padrinorb.com launched, padrino-docs maintained as submodule
Updated website design ⚠️ Stale Site exists but content hasn't kept pace with 0.15-0.16 changes
Document missing stuff ❌ Remaining Docs lag behind — 0.15.x and 0.16.x features under-documented
Support only Ruby 3.4+ ⚠️ Needs decision Currently supports 2.7+. CI tests 2.7 through 4.0. Drop old versions for 1.0?
Ruby 3.0 coding style ✅ Done Rubocop compliance added in 0.16.0, code modernized
Less dependencies ✅ Done ~8 runtime deps total across all gems. Very lean
More robust ✅ Done Sinatra 4, Rack 3, Ruby 4.0 compat. Stable for years
Fastest Ruby framework ⚠️ Unmeasured padrino-performance gem exists but no public benchmarks

Score: 10/17 done, 5 partial, 2 remaining

What's Actually Needed for 1.0

🔴 Must-Have (Blocking)

1. Coherent Authentication Strategy

Padrino ships auth today, but it's buried inside padrino-admin and not reusable. The admin provides session-based auth with BCrypt password hashing, role-based access control, and a generated Account model — but if you're building a non-admin app or an API, you're on your own.

What exists today (in padrino-admin):

  • Session-based email/password authentication via AuthenticationHelpers
  • BCrypt password hashing on a generated Account model (11 ORM variants)
  • Role-based access control DSL (access_control.roles_for :admin do ... end)
  • Login/logout controller and views (generated)
  • logged_in?, current_account, login_required helpers
  • CSRF protection via Rack::Protection::AuthenticityToken

What's missing:

  • No reusable auth module outside of admin — you can't register Padrino::Auth in a regular app
  • No token-based or API key authentication
  • No OAuth/OAuth2 or OmniAuth integration story
  • No JWT support for stateless API auth
  • No documented path for "I need auth but not the full admin"
  • No multi-factor authentication support
  • The old padrino-auth gem idea never shipped

Proposal for 1.0:

Extract and generalize auth into a first-class feature:

  1. Extract Padrino::Auth from admin — Make session-based auth a registerable module for any Padrino app, not just admin. register Padrino::Auth should give you current_account, logged_in?, login_required, and the access control DSL without requiring the full admin scaffold.

  2. Add API auth support — Provide a lightweight token-based auth option for API apps. At minimum: bearer token validation middleware and a authenticate_token! helper. This is critical for the --api project mode.

  3. Document the auth extension points — Even if Padrino doesn't bundle OAuth or JWT directly, document how to integrate Warden, OmniAuth, rodauth, or JWT gems. Provide a clear "recommended stack" for common auth scenarios:

    • Session-based web app → built-in Padrino::Auth
    • API with token auth → built-in token support
    • OAuth/social login → OmniAuth integration guide
    • Full-featured auth → rodauth integration guide

  4. Modernize the Account generator — Update the generated Account model to support modern password requirements (configurable minimum length, optional complexity rules). Consider adding remember_token and reset_token fields for password reset flows.

  5. Keep it lightweight — This is Padrino, not Rails. Don't build Devise. Build the 80% solution and make the 20% extensible.

2. Modernize Admin UI

The admin generator ships Bootstrap 3.0.0 (released 2013) with LESS stylesheets. This is the single most visible debt in the framework.

Proposal:

  • Upgrade to Bootstrap 5 (CSS-only, no jQuery dependency)
  • Drop LESS entirely — use plain CSS or SCSS
  • Drop CoffeeScript references
  • Keep it simple: the admin is a generator, not a runtime dependency
  • Consider offering a Tailwind CSS alternative as opt-in
  • Update login views to match modern auth changes

3. Clean Up Generator Defaults

The generators still offer: Dojo, Prototype, MooTools, Ext Core as JS options. Compass as a stylesheet option. These are all effectively abandoned projects.

Proposal:

  • Remove dead JS libraries (Dojo, Prototype, MooTools, Ext Core)
  • Remove Compass support
  • Keep: no-JS (default), jQuery (optional)
  • Consider: Stimulus or vanilla JS as modern option
  • Remove dead ORM options if any are unmaintained (DynamoDB adapter, Mongomatic, Ripple)

4. Set Minimum Ruby Version

Currently requires Ruby >= 2.7.8. Ruby 2.7 reached EOL in March 2023. For a 1.0 release in 2026, supporting 3-year-old EOL Rubies undermines the "modern" message.

Proposal:

  • Minimum Ruby 3.1+ (or 3.2+ to get YJIT benefits)
  • Continue testing against JRuby
  • Ruby 4.0 already passes CI — great positioning

5. Documentation Pass

Docs haven't kept pace with 0.15.x → 0.16.x changes. A 1.0 launch without updated docs will fall flat.

Proposal:

  • Audit padrino-docs for accuracy against 0.16.1
  • Document ParamsProtection (mass assignment) — it's a great feature nobody knows about
  • Document the new auth strategy front and center
  • Document Rack 3 / Sinatra 4 compatibility story
  • Update getting started guide with modern defaults
  • Add a migration guide from 0.15.x

🟡 Should-Have (High Value)

6. API Surface Review

As @ujifgc noted in 2017: "1.0.0 should mean stable beautiful API." Now's the time to make breaking changes before locking in 1.0 semver.

Areas to review:

  • Controller routing syntax simplification (#747) — the controller :foo do ... end block DSL is unique to Padrino but can be verbose
  • Settings naming consistency across sub-gems
  • Deprecate any dead settings or methods
  • Ensure all public APIs have YARD docs

7. Close or Triage Open Issues

20 open issues, some from 2015-2016. A 1.0 release with 8-year-old open issues looks unmaintained.

Proposal:

  • Close issues that are no longer reproducible on 0.16.1
  • Label remaining issues as 1.0 or post-1.0
  • Notable open issues to address:
    • #2283 — Unhook moneta from padrino-cache (reduce coupling)
    • #2273 — SystemStackError with partial in layout
    • #2178 — Long boot time due to Reloader.safe_load
    • #2242 — Admin locale finding

8. Strengthen Rubocop Config

Rubocop was added in 0.16.0 but many rules are disabled (all Metrics cops off, some Lint cops off). For 1.0, tighten the bar.

Proposal:

  • Enable key Metrics cops (method length, cyclomatic complexity) with reasonable thresholds
  • Fix remaining Lint exclusions or document why they're necessary
  • This signals code quality commitment to potential adopters

🟢 Nice-to-Have (Post-1.0 or Stretch)

9. Performance Benchmarks

Publish benchmarks comparing Padrino to Sinatra raw, Rails API, Roda, and Hanami. The framework has always been fast — prove it.

10. Async / Fiber Exploration

Rack 3 has fiber support. Not critical for 1.0, but worth exploring for 1.1. Would make Padrino attractive for high-concurrency use cases.

11. API Mode Polish

padrino-gen project --api exists. Ensure it produces a clean, minimal API-only project (no admin, no views, JSON-focused). Should integrate with the new token auth strategy.

What's NOT Needed for 1.0

Things from the old roadmap or community discussions that we can safely skip:

Item Why Skip
Pendragon router PathRouter is already better and battle-tested
Ractor support Too immature ecosystem-wide. Thread safety is sufficient
New JS framework integration Not Padrino's job. Keep frontend-agnostic
Gemified apps overhaul Works well enough. Edge cases can be post-1.0
Custom ORM layer ORM-agnostic is a feature, not a bug
Build Devise-for-Padrino Overkill. Lightweight auth + extension points is the right call

Proposed 1.0 Release Plan

Phase 1: Cleanup (4-6 weeks)

  • Bump minimum Ruby to 3.1+ (or 3.2+)
  • Remove dead generator components (Dojo, Prototype, MooTools, Ext Core, Compass)
  • Triage and close stale issues
  • Fix #2273 (partial in layout), #2242 (admin locale)

Phase 2: Auth & Admin (6-8 weeks)

  • Extract Padrino::Auth module from padrino-admin into a reusable component
  • Add token-based auth support for API apps
  • Document auth integration paths (OmniAuth, rodauth, JWT)
  • Replace Bootstrap 3 with Bootstrap 5 in admin generator
  • Remove LESS, use plain CSS/SCSS
  • Update admin login views to use new auth module
  • Modernize Account model generator (password reset fields, configurable rules)
  • Test admin generation across all supported ORMs

Phase 3: API & Docs (4-6 weeks)

  • API surface review — deprecate/remove dead code
  • Tighten Rubocop configuration
  • Update padrino-docs for 1.0
  • Write auth guide (the #1 thing new users will look for)
  • Write migration guide from 0.15.x/0.16.x
  • Document ParamsProtection, CSRF, caching

Phase 4: Release (2 weeks)

  • 1.0.0.rc1 release for community testing
  • Performance benchmarks published
  • Announcement blog post
  • 1.0.0 final release

Estimated timeline: 16-22 weeks for a focused effort

Current State Snapshot

Component Version Health Key Deps
padrino-core 0.16.1 Solid Sinatra 4, Rack 3, Thor 1
padrino-helpers 0.16.1 Solid Tilt 2, i18n
padrino-mailer 0.16.1 Good Mail 2.5
padrino-cache 0.16.1 Good Moneta 1.6
padrino-admin 0.16.1 Needs work Bootstrap 3 (!), auth locked inside
padrino-gen 0.16.1 Needs cleanup Bundler
padrino-support 0.16.1 Solid None
padrino-performance 0.16.1 Minimal None

Auth today: Session-based only, admin-only, BCrypt, role-based ACL. No API auth, no OAuth, no JWT.

CI Matrix: Ruby 2.7, 3.0, 3.1, 3.2, 3.3, 3.4, JRuby, 4.0 Recent Activity: 57 commits since 2023, 20 in 2025 Open Issues: 20 (oldest from 2015)

Bottom Line

Padrino has been production-ready for years. The core is solid, dependencies are minimal, and compatibility is excellent. The main things standing between 0.16 and 1.0 are:

  1. Auth needs to be a first-class citizen — not buried in the admin, not absent for APIs
  2. The admin UI is a time capsule — Bootstrap 3 in 2026 is not a good look
  3. Generators carry dead weight — Dojo and Prototype shouldn't appear in a modern framework
  4. Docs need a refresh — The framework is better than its documentation suggests
  5. Symbolic commitment — Closing stale issues and bumping the Ruby minimum signals active maintenance

Get auth right, modernize admin, clean up the rough edges, and Padrino earns its 1.0.

Add a custom footer
Add a custom sidebar

Clone this wiki locally