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:
