Three members of the Ember core team discuss reactivity, build systems, and the longevity of the Ember community. They explore topics like reactivity in large applications, standardized frameworks, Embroider project, and the importance of seamless global application frameworks. They also touch on the developer-first security platform Socket and efficiency in build systems through reactivity and managed fetch.
Ember's approach focuses on stability while evolving with good patterns, ensuring platform investments improve over time.
Ember's reactivity system allows normal JavaScript paradigms, using decorators to track state changes without breaking composability.
Embroider project aids Ember ecosystem migration to modern tooling, converting Ember-specific elements into standardized formats for seamless transition.
Deep dives
Ember JS Core Team Members Introductions and Backgrounds
Chris Manson, Chris Thoburn, and Ed Faulkner, representatives of the Ember JS core team, discuss their backgrounds, roles within the team, and how they got involved in Ember, showcasing the community's longevity and shared vision.
Ember's Stability Without Stagnation Philosophy
Ember's approach focuses on stability without stagnation, evolving by adopting good patterns and building new ones when necessary, ensuring the platform and language level investments improve over time, setting it apart from other frameworks.
Reactivity System in Ember
Ember's reactivity system prioritizes allowing normal JavaScript paradigms for data reading and writing, using decorators to track state changes and ensuring changes downstream are managed without breaking the composability of JavaScript.
Embroider Project: Migration Path for Ember Ecosystem
The Embroider project aids the migration of the Ember ecosystem to standardized build tooling, focusing on getting apps onto more modern tooling like Veet and providing a way to convert Ember-specific elements into standardized formats, paving the way for a more seamless transition.
Evolution of Ember Data and the Birth of Warp Drive
The evolution of Ember Data from its inception with Sproutcore in 2006 to its rebranding as Warp Drive is discussed. Originally designed to bring the Core Data APIs for iOS into JavaScript, Ember Data aimed to create a client-side ORM with enhanced network layer abstractions. Despite initial challenges faced by early users, Warp Drive now focuses on managed fetch functionality, providing features like error handling, authentication, data normalization, and cache manipulation in a lightweight manner.
Longevity and Upgradeability in Developer Choices
The importance of building apps for longevity and making upgradeability a key aspect of software development is highlighted. By focusing on clear communication of abstractions, standardization, and compatibility, developers can ensure that their applications can scale smoothly over time. The Ember team's approach of making pluggable components in the framework fosters community contributions and advancements in web development practices.
KBall takes another dive into recent hot topics around reactivity and build systems, this time with three members of the Ember core team. They also talk about some of the reasons why the Ember community has been so long lived, how thinking about upgradeability leads to universality, and how features first built specifically for frameworks make their way into the language specification or universal libraries.
Changelog++ members get a bonus 16 minutes at the end of this episode and zero ads. Join today!
Sponsors:
Neon – Fleets of Postgres! Enterprises use Neon to operate hundreds of thousands of Postgres databases: Automated, instant provisioning of the world’s most popular database.