Ember (along with a whole family of related open source tools) is steadily reducing the cost of shipping sophisticated applications. By making it easier to compose applications out of high-level, shared pieces, and deploy them on demand to commodity hosting, we've been sowing the seeds for a revolution in how software gets built and paid for. This is a talk about both the technical "how" -- including the latest work in the Cardstack project -- and the "why": our opportunity to grow an open, decentralized software ecosystem that can sustainably pay for open source while respecting user freedom.

1. The Revolution Will Not
Be Centralized
edward@eaf4.com
ef4
eaf4
Edward Faulkner
This is a talk about re-decentralizing the web. But I am going to take a roundabout path to getting there that starts much closer to what this community is already doing.

2. A framework for creating
ambitious web applications
What is the Ember community’s favorite adjective?

3. ambitious
What is ambitious depends on your context.

4. When you are only one year old, climbing the playground is ambitious!

5. When you are six years old, hiking up mountains is ambitious.

6. http://bit.ly/2yklMHdDecember 14, 2011
When Ember was born, just the idea of creating desktop-class applications in the browser was ambitious.
We are extremely successful in that space: Apps with big responsibilities and complicated requirements.

7. We have not stopped being ambitious. Yesterday we heard a lot of details about ongoing Ember work that I will not repeat in detail. But let’s take a quick glance at the
high level amount of activity.

11. Two interesting things here:
The first is how far back glimmer-vm goes! It has undergone continuous evolution from the point when it was called htmlbars.
The second is that recent velocity is very high.

12. Lest anybody worry that glimmer.js is consuming all of our dev resources, this makes it clear that it is not.
But it is definitely a high-value increment on top of everything else.

13. And we see that our latest month is among the handful of most ambitious in the project’s history.
Things are really moving! On a codebase that is not young. That’s a robust sign of health!

14. ambitious

15. ambitious along
which dimensions?
•Easier development
•Easier learning
•Faster code in more environments

16. Easier development ?
The Werewolf of Eschenbach, Germany: line engraving, 1685
This illustration accompanies the classic essay “No Silver Bullet” by Fred Brooks written in 1986.
Essential vs accidental complexity. Limits to how much we can reduce essential complexity.

17. • Only so much complexity can fit per brain
• Communication cost goes up as N^2 when
you add more brains.
How do make software development easier? The first answer is, you don’t.
Fundamental limits.

18. Only Known Workaround:
Higher-Level Abstractions
return solveMyProblem();
fetch('https://emberfest.eu/')
No such thing as too much magic. Only good and bad abstractions.
Which is part of the vital role of frameworks — to be really abstract, you need to solve many people’s problem. You need a community.

19. The ember add-on ecosystem is the where we can build abstractions higher than Ember itself. In a sense, Ember exists to allow the add-on ecosystem to flourish, just as
a kernel exists to allow an application ecosystem to flourish and cooperate.
My topic today is how to let add-ons grow into something more powerful.

20. Storage
Server App
Client App
PostgreSQL, MySQL, Redis, Elasticsearch, s3, etc
Rails, Django, Struts, Express, etc
Your code
Your code
Glimmer, Ember, etc
Addons
We already get a large amount of reuse. It’s why we can build what we do today already.
Notice that the horizontal boundaries are natural places where both open source projects and commodity services tend to thrive. People are used to integrating across
them.
Vertical boundaries are harder. A lot of the custom code we write today is trying to integrate things across vertical boundaries.

21. Server App
Client App
Your code
Glimmer, Ember, etc
Addons
Storage
@cardstack/hub
(Legacy)
This is the Cardstack architecture. You may have seen my Emberconf talk, where I focused mostly on what Cardstack can add inside an Ember app. Here I will focus
more on the broader architecture.
Cardstack Hub is a node-based server. It gets compiled from the set of Cardstack plugins in your package.json.
It sits in front of your data sources, which can include your existing application servers.

22. Server AppStorage
@cardstack/hub
(Legacy)
Client App
Your code
Addons
Glimmer, Ember, etc
Addon
A single npm package can be an ember add-on and a cardstack plugin simultaneously. It can provide ember components, etc. It can also provide Features to Cardstack
hub.
This is a step toward making add-ons that can behave more like mini applications. For example, instead of just a calendar UI, why not install a whole calendar system,
including storage and search? An invoice builder? A CRM?

23. Data Source Plugins
Middleware Plugins
Dockerized
Services
The Hub doesn’t want to own your data. It serves as a command and query tier (Command Query Responsibility Segregation) in front of your existing data sources.
Data source plugins can index, write, and search data sources.
Middleware plugins expose data out to client apps. JSON:API is the most relevant example for us.
Cardstack plugins that need more than just pure Javascript within the node-based Hub can declare that they depend on arbitrary Docker images, which will be spun up
automatically. Here I’m showing Elasticsearch: add a single package, gain a full search engine.
Data source plugins are not unlike ember-data adapters, moved to the server. But on the server they are more powerful. And we can hide their complexity from the
client app.

24. •authenticator
•code-generator
•constraint-type
•field-type
Hub plugins are well-typed
•indexer
•messenger
•middleware
•searcher
•writer
Some plugin systems encourage you to inject arbitrary code into arbitrary places. That hits composition limits, and it makes it much harder to write plugins.
The hub’s plugins are well-typed, meaning they expose specific types of Features that each do one specific thing. Which makes them easier to write and keeps the
whole system more compose-able.

25. So what does all this have to do with cards?
Everything.

26. As a visual design language, Card UI is already ubiquitous. The newly-redesigned iOS app store demonstrates card motion and affordances perfectly.
But card-based design is capable of more. It’s a design system that fits naturally with component composition. Users can move in and out of rich experiences that
each have totally different internal implementations, but follow enough design conventions around their edges so that they come together as a coherent experience.
And when you can pass interactive cards from person to person, you can support organically growing workflows.

27. Custom code
Shared code
Card UI lets us attack one of the critical problems on the web today. Centralization. Walled gardens. Too hard to integrate into coherent experiences. Stifled innovation.
Every app has a wide, custom layer in between the user and their data. This gives it total control, but it is also a huge burden. You can’t focus on just the value-
added parts that are special. You write yet another login screen, menu system, content management feature, media manager, authorization system, scheduling system,
etc.

28. When everyone does this, users get disjointed experiences. Too many logins. Forced to choose between staying in one walled garden where at least everything works
together vs the freedom and innovation of a more open web. Developers can’t safely invest in a platform that’s wholly owned by someone else.
Businesses feel this acutely. They frequently face build-vs-buy dilemmas. They can’t buy features a la carte, and they can’t easily recover from the wrong choice
because their data gets locked in.
Every app locks your data in. Which is clearly bad for users. But isn’t it good for us, who make and sell software? No, only for the biggest, established, billion dollar
vendors. Lock-in makes small, innovative teams too risky to trust with Important Software.

29. When data and hosting are all controlled by one company, it’s a high risk situation. So only very big, established vendors can sell Important Software.
And important software is where most of the money is.

30. Data Sources
Card Apps
So how do we grow an open ecosystem with lower risk and less lock-in?
It’s deliberate that the Hub exists so that Cards can be portable across data sources. It enables a much more distributed way of writing apps. And the massive open
source investment in making software easier and easier to deploy to commodity hosting means we can make it practical for a wider audience of organizations to control
their own hosting.
You can still write a normal, self-contained app if you want to. But you can go faster and attack bigger Important Software markets if you don’t go alone.
This isn’t about trying to convince people to decentralize out of idealism. This is about leapfrogging the current generation of user experience.

31. Data Sources
Card Apps
This also connects directly to Glimmer.
Cards need to be portable and fast everywhere.
Glimmer components are the perfect fit. They can be small fast web components when rendered as small cards, and expand into Ember apps when the user dives
into a complex dashboard or workflow.
Compilation is important not just for performance, but for the widest possible compatibility at the lowest cost. We can unlock Rust-epoch-like capabilities.

32. Data Sources
Card Apps
We also live in a time when multiple distributed technologies are mature or maturing.
Git is far a far more powerful distributed system than most people realize, and it not only good for source code.
Matrix is federated realtime messaging done well.
And the explosion of interest in blockchain-based distributed systems is creating new ways to coordinate people.

33. The Cloud
Fully decentralized
systems
One of Cardstack’s key bets is that — despite what many people think — Cloud services are not really the enemy of a decentralized internet.
You can build a system that takes advantage of the strengths of each.
The cloud isn’t bad when users have meaningful choices and control.

34. Keep building higher!
So that is the opportunity: we keep investing in the open web platform, controlled by no one, and unlock new ways for communities like ours to deliver the next
generation of software together.

35. edward@eaf4.com
ef4
eaf4
https://github.com/cardstack/cardstack
https://cardstack.com/