Ruby on Rails for Flutter

Rails' bet was that most of the decisions in a web application are not worth making twice, so the framework makes them and you write the part that is yours. Dartvel takes the same bet for Flutter: where the file lives is the route, the model is the schema and the client and the form and the admin screen, and one command runs the generators.

lib/pages/index.dart            ->  /
lib/pages/articles/index.dart   ->  /articles
lib/pages/articles/[slug].dart  ->  /articles/:slug

dartvel dev     # generate, serve, hot reload, QR code
dartvel build web-server   # one file to deploy

Dartvel: The file path. Moving a page breaks every link to it

Dartvel: @DVModel: schema, client, form and admin from one class

Rails: Written by rails generate model, applied by rails db:migrate

Dartvel: Generated from the model class

Rails: rails generate, including scaffold: model, migration, controller, views and forms

Dartvel: dartvel dev regenerates on save

Rails: Active Job on Solid Queue, the default since Rails 8

Dartvel: DV.Jobs, DV.Queues, @DVJob

Rails: bin/rails generate authentication, built in since Rails 8

Dartvel: Sessions, passkeys, OAuth sign-in, SAML, LDAP, second factors

Rails: None built in; ActiveAdmin or Avo

Dartvel: Studio, in your own binary, free

Dartvel: Flutter pages: web, phone, desktop and TV

Rails: params.expect and permit in the controller

Dartvel: Typed function arguments, checked by the compiler

Rails: Kamal, set up by rails new, to any server with Docker

Dartvel: One binary from dartvel build web-server

A model declares fields. From that come the table, the typed client, a form with an input per field, a table widget, an admin screen and, unless you opt out, public pages with their own sitemap entries. rails generate scaffold writes much of the same once, as files you then own and edit; here they are regenerated from the class whenever it changes.

@DVModel()
class const _Article({
  required final String slug,
  @DVModel.pageTitle() required final String title,
  @DVModel.mainContent() required final String body,
});

The generated page is Article.Page(...), with .async, .signal and .fromId variants.

Models publish change streams to watchers in the same process. Carrying a change to another server or a phone is not built yet.

Forms come from the fields: Article.Form() creates a record and article.Form() edits one, and saving is what the form does. @DVModel.validate and @DVModel.uniqueField set the rules a write has to meet.

Over twenty years of gems, and a hiring pool to match.

A new Rails 8 app comes with authentication, Solid Queue, Solid Cache, Solid Cable and Kamal, so jobs, caching, WebSockets and deployment need no extra service.

For a server-rendered website, ERB and Hotwire are far less machinery than compiling a Flutter application.

Rails runs on every host on earth, and Kamal deploys it to any server with Docker. A Dartvel deployment is one binary, which is simple and newer.

Rails reaches phones too, through Hotwire Native, which wraps the web app in native iOS and Android shells.

Dartvel Cloud is not open yet; local builds and your own server are free and work now.

Rails is not a Flutter framework and does not claim to be. The comparison is here because "Rails for Flutter" is what people type when they mean: I want the conventions, the generators and the batteries, for the app I am actually building.

FSL-1.1-MIT licensed. Built with Dartvel.

Rails conventions, for an app that also runs on a phone.

What you reach for in Rails, and what it is here.

One class, and the boring files are already written.

Where Rails is ahead today.

Dartvel next to the tools people ask about.