Brut: A New Web Framework for Ruby

I like the emphasis on forms and pages. That's the approach I take in my apps. Forms and Links drive all interaction. Any JavaScript enhancements merely click an existing form (even if it's hidden). You can always inspect the HTML and know exactly the route that will handle the interaction. I think controllers are overused. It's really forms, models (backend) and views (Pages). A lot of the validation and ceremony of controllers can be handled more elegantly by the framework.

This reminds me of Camping without the dynamic parent class constructor.

>What about monads or algebraic data types or currying or maybe having everything be a Proc because call?! You don’t have to understand any part of that question. But if you want your business logic to use functors, go for it. We won’t stop you.

I love this! It sounds exactly what I’d want to use for a side project or a project with a limited number of reasonable, senior coworkers.

Neat, this looks like it might be a good middle ground between Sinatra (which I adore) on the barebones/low-level end and Rails (which I also adore for apps that need it, but simple apps really don't).

Looking forward to trying it out!

I see it is currently based on Sinatra. Just wondering if you have considered looking into Roda?

Tried to login to the example site, unfortunately hit an error immediately after auth'ing with github.

> Is this the index action of the widgets resource or the show action of the widget-list resource? is a question you will never have to ask yourself or your team. The widgets page is called WidgetsPage and available at /widgets.

Hm, uh, seems like now we will be forever asking ourselves this question about /widgets.

That being said, it looks good! Might get me back into ruby if I can come up with a project for it.

Oh man, Brut's HIPPOCRATIC LICENSE[1] is interesting! Just excerpting bits of Section 3.1 and Section 3.2 for example:

  * 3.1. The Licensee SHALL NOT, whether directly or indirectly, through agents
   or assigns:

    * 3.1.12. Taliban: Be an individual or entity that:
      
      * 3.1.12.1. engages in any commercial transactions with the Taliban; or
      
      * 3.1.12.2. is a representative, agent, affiliate, successor, attorney, or
        assign of the Taliban;
   
    * 3.1.13. Myanmar: Be an individual or entity that:
      
      * 3.1.13.1. engages in any commercial transactions with the
        Myanmar/Burmese military junta; or
      
      * 3.1.13.2. is a representative, agent, affiliate, successor, attorney, or
        assign of the Myanmar/Burmese government;
   
    * 3.1.14. Xinjiang Uygur Autonomous Region: Be an individual or entity, or a
      representative, agent, affiliate, successor, attorney, or assign of any
      individual or entity, that does business in, purchases goods from, or
      otherwise benefits from goods produced in the Xinjiang Uygur Autonomous
      Region of China;

  * 3.2. The Licensee SHALL:

   * 3.2.1. Provide equal pay for equal work where the performance of such work
     requires equal skill, effort, and responsibility, and which are performed
     under similar working conditions, except where such payment is made
     pursuant to:
     
     * 3.2.1.1. A seniority system;
     
     * 3.2.1.2. A merit system;
     
     * 3.2.1.3. A system which measures earnings by quantity or quality of
       production; or
     
     * 3.2.1.4. A differential based on any other factor other than sex, gender,
       sexual orientation, race, ethnicity, nationality, religion, caste, age,
       medical disability or impairment, and/or any other like circumstances
       (See 29 U.S.C.A. § 206(d)(1); Article 23, United Nations Universal
       Declaration of Human Rights; Article 7, International Covenant on
       Economic, Social and Cultural Rights; Article 26, International Covenant
       on Civil and Political Rights); and
   
   * 3.2.2. Allow for reasonable limitation of working hours and periodic
     holidays with pay (See Article 24, United Nations Universal Declaration of
     Human Rights; Article 7, International Covenant on Economic, Social and
     Cultural Rights).

> I know, we can vibe away all the boilerplate required for Rails apps. But how much fun is that? How much do you enjoy setting up RSpec, again, in your new Rails app? How tired are you of changing the “front end solution” every few years? And aren’t you just tired of debating where your business logic goes or if it’s OK to use HTTP DELETE (tunneled over a _method param in a POST) to archive a widget?

For your personal hobby project, go nuts. Break all the rules and cowboy all your own conventions.

But for business applications, the conventions Rails enforces at least make codebases somewhat familiar if you've seen a Rails codebase before.

At a certain codebase size, boilerplate is almost unavoidable. Unpleasant, but necessary. Personally, I'd rather have some conventions, rules, and guardrails for where the boilerplate lives rather than trying to navigate your homegrown pile of code. Good luck maintaining that spaghetti when you've got multiple developers.

It's not clear how this new web framework avoids boilerplate anyway, so I don't see how this is an improvement over Rails. Presumably you'll still need to set up lots of stuff yourself, like RSpec. If the framework sets all of that stuff up for you in a conventional way, then you're just back to square one as soon as you need to fight against the framework's conventions.

[flagged]

[flagged]

[flagged]