[gleenn]

I always struggle with the idea that "frameworks are bad, combine libraries instead," it makes sense and makes orthogonal libraries not step on each other or make things more complicated. The thing lost is having an easy time getting up and running quickly. I was always a big Liminus champion fir this reason, they tried really hard to group a good set of libraries and document it all well. Bur this work is also fantastic. Sometimes, you really just want to get something done, and the batteries included solution might be the thing that gets your project done. I came from Ruby on Rails and will always miss that ability to get a DB connected, Javascript enabled, dynamic website onto something like Heroku from 0 to production in like... 20 minutes. So thanks for Coast, looks like it will help fill in an important part of the tooling spectrum.

[adamkl]

Agree. There is a lot of value in the "easy, batteries included" solution which is why Rails gets so much love from the start-up community. The problem always seems to be that the same things that makes Rails easy to get started with (cough ActiveRecord cough) also make it easy to create foot-guns in the future (provided your start-up lasts long enough to get to that point).

Combining a Rails like framework that makes things easy with a language who's idioms prioritize simplicity seems like a great combination.

[dimitrios1]

I am going to butcher this, but my sense is this counter culture against the big heavy opinionated frameworks arose from that generation of programmers who in a sense "grew up" (career wise) on things like Rails. Like others have said, there eventually comes a time where you are fighting the framework more than the framework is providing value, and having learned the value of the abstractions and functionality through multiple applications, they then became able to pick and choose a finer subset for a particular problem or domain.

The best of both worlds, in my opinion, is a loosely coupled set of opinionated tools and libraries, but that also has a tool that provides a unifying interface into the "golden path" for using those together to provide some functionality.

[dgb23]

> The best of both worlds, in my opinion, is a loosely coupled set of opinionated tools and libraries, but that also has a tool that provides a unifying interface into the "golden path" for using those together to provide some functionality.

This is almost it. A few more things I think one wants:

- Do most of the coupling and plumbing yourself, IoC is evil when applied to things that do too much.

- Control the application state - see above.

- Be free to substitute any major part, be able to compose them freely.

- Re-use and extracting libraries from past work to be convenient, robust and affect past / maintenance-mode projects positively too.

- Be able to defer extracting libraries and generalizing up to the time you actually need to.

- Decouple code organization from artifact deployment.

- Be absolutely free in how you design and write domain logic and information processing - this is the brain of an application.

- Be absolutely free in how you design and write the UI - this is the body of an application.

- Have the tooling/utilities around code that fit your workflows and business needs.

I've come to the conclusion that full-stack frameworks in the style of Rails/Laravel/Django get in the way of some of the above and don't provide enough to make the above possible by themselves. I think the answer is not "use this framework" or even "build this framework".

It starts with your business/domain needs and builds from there - custom and simple. It builds up slowly and steadily like a garden that reflects your team's personality. It takes a careful, comprehensive, holistic approach. There are angles from version control, to project management to deployment that are all incorporated.

[adamkl]

Sounds like “create-react-app”. A bunch of libraries and configurations wrapped up in a “golden-path”.

Provides the “easy” for 95% of usecases and an “eject” button that unwraps everything and puts it under you control for the last 5%.

[dimitrios1]

Create react app was one example I had in mind, I think Redwoodjs is another one that recently popped up.

[ravi-delia]

> Combining a Rails like framework that makes things easy with a language who's idioms prioritize simplicity seems like a great combination.

I think that's what makes Phoenix and Elixir so nice to use. The primitives Phoenix uses aren't too far from the surface, and the default setup is fairly batteries included without ruling out future growth.

[slowmovintarget]

To quote Rich Hickey: "gem install hairball"

[adamkl]

I like that quote, but it's the Rails idioms and conventions that make hairballs, not the fact that it includes a bunch of batteries.

[capableweb]

Adopting any framework is quite literally adopting the framework's idioms and conventions so not sure how that is different.

[adamkl]

It was a general comment about frameworks. It’s possible to have a framework that includes all the “batteries” but has idioms and conventions that promote simplicity and maintenance.

Rails chose idioms and conventions that prioritize speed at the cost of complexity. The “included batteries” are not the problem.

[EsotericAlgo]

The good 'ole days.

You're paying the tax at some point, but if that's at the start of the project it might be high enough to stop it in its tracks. A mature Rails or Django project require abstracting configuration later on in development which is a different sort of tax.

Convention over configuration absolutely has it's perils. I've unfortunately (fortunately?) hit this enough times with Clojure, I know the ecosystem well-enough I'd personally pick composition for a personal project. In a team project where composition makes collaboration difficult (generally a communication and experience problem) I'd probably choose another language with an opinionated framework.

[andrewzah]

Agreed, that's why I find it so difficult to leave rails/ruby. I really like Clojure+Datomic+Clojurescript but I can't justify the extra work needed compared to the extensive tooling and library support that rails has since it's mature and widely used.