Sam and Ryan talk about what sorts of capabilities a tool should have to be considered a web framework. They discuss how frameworks tackle the complexity of getting different systems to communicate with each other, how good frameworks embrace the strengths and patterns of the language they're written in, and why frameworks and services are not in opposition to each other.

Timestamps:

0:00 - Intro
3:58 - Adapter pattern and cohesive boundaries
9:43 - Rails is Omakase
13:47 - Configurable, but still cohesive
17:04 - Frontend frameworks try to “work with everything”
21:42 - Does composition mean a React framework will look different than Rails?
29:29 - Why taste still matters
34:20 - A framework is a shell of adapters and a brain that coordinates them
35:16 - When using services, complexity still exists in the in-between
37:59 - A fullstack dev is someone who acknowledges and understands how all the parts come together
44:06 - Tweets about the hard problems that Laravel tackles, and the deep design it took to get there
49:15 - Frameworks should embrace the strengths and patterns of their language and ecosystem
50:35 - Why RSCs and Server Actions mean the “Rails for JS” may end up looking nothing like Rails
52:11 - Why users of a “fullstack framework” shouldn’t even care about where the code is running
55:31 - Why libraries or services that are easy to install and set up are not a replacement for frameworks

Links:

What is a framework?