Marco Otte-WitteWe at @mainmatter have been long-term active members and contributors to the #emberjs community.
Now we're expanding into #svelte. Why do we do that and what does it mean for our involvement with Ember?
1/🧵
@mainmatter First of all, @emberjs keeps enabling teams to stay focused on shipping value for their clients, and doing so for long – countless examples of teams that have been productive with Ember for years and sometimes decades speak a clear language, e.g. Intercom, or Auditboard.
2/🧵
@mainmatter @emberjs That said, Ember has a very clear niche in which it excels – dashboard-style, desktop-first productivity apps. There, Ember's relatively heavy weight doesn't matter, you actually need everything that ember-data provides, and things like SSR and SSG are largely irrelevant.
3/🧵
runspired 🐹@marcoow tbh I’d argue that any app that uses fetch or a rest API even a little needs everything EmberData provides. And whats nice is we’ve managed that without the weight and with greater flexibility than alternatives like Protobuf, tRPC, MobX, TanstackQuery, or Apollo. And as we get further into the “it’s a data framework for all apps” story I think we’re going to be able to show that off well.
@runspired maybe, yes – I'd be excited to see how ember-data outside of Ember works. To be fair, I think the big differentiator between Ember and Svelte (and Remix etc.) is the MPA + PE -> SPA story, not so much ember-data
@marcoow one thing I think remix and next have been saying a lot lately that I think I’d like to see us start saying with embroider (because it’s true): embroider/ember (the meta framework) is “just a build plugin”
NullVoxPopuli