Thread by @wycats

What people often miss about our use of Glimmer templates in Ember is that it's an intentionally restricted programming language (like Elm or ClojureScript).

Our view is that you get the most value from these restrictions in the application's rendering code.

A nice thing about building a restricted programming language in the context of HTML is that people are already familiar with HTML and the basic idea of templating HTML.

This means that fairly aggressive limitations feel normal in the context of a template.

You can see that there's a need to substantially restrict what you're allowed to do during render by looking at how the ethos around react render functions has changed over time.

These days, React hooks require a linter and storing state in React's runtime through special funcs.

There's nothing wrong with that. React's render functions are now a a heavy DSL with syntax restrictions and new functions that you're supposed to think of as built-in syntax.

On the other end of the spectrum, system like Elm drive the restricted programming language across your entire application.

This is also a cool approach, and one that's been pretty influential in the front end space.

Ember's approach is to build a restricted programming language on top of HTML for the rendering engine, and use JavaScript to manage interactions with your server, general purpose programming and longer-term state management.

Ember has a well-developed boundary between your JavaScript state and your the rendering process.

To make a long story short, Ember's templates are a standalone render program that runs from the top down in the Glimmer VM, using JavaScript state as inputs.

Whenever your JavaScript state changes, the Glimmer VM revalidates the whole render program from the top-down (using reliable optimizations to avoid revalidating parts of the render that we know couldn't have changed.)

Ember's templates have the basics you need in a programming language, like functions, conditionals and block-let, but not much else (including mutation, hoisted variables, or method syntax). This means that you can understand the rough flow of an Ember template visually.

A lot of the work we've done over the past few years has been living up to those aspirations.

The earliest versions of Ember had a separation between templates and JS, but data flow between the two was porous, fundamentally sneaking mutation into the template layer.

Early syntax decisions made certain syntax (like {{something}}) extremely visually ambiguous, which required a lot of experience with Ember to understand the structure of a template (and therefore its data flow) at a glance.

The upshot of all of that is that people experienced with Ember learned enough of the quirks to appreciate the benefits of the hybrid model (declarative rendering, JavaScript for general programming, effects and long-lived state) but the benefits aren't apparent at first.

Over the past few years, we

- largely eliminated two-way state entaglement between JS and the rendering program
- made the difference between arguments (props in react), state, function calls and component invocation obvious as a glance
- overhauled JS state management

As part of overhauling state management, we formalized the boundary between your app JS and the render program, and shrunk down the user-facing system to a single tracked annotation on JS properties that could affect the render program when they change.

This means that if you need to compute something from your JS state in order to render it, you can decompose it into JS getters or functions with abandon.

Ember Octane, which is set to be released as 3.14, is a community-wide project to take all of these improvements and put them front and center in the docs, guides and how we teach Ember.

And because Ember is for applications that evolve over many years, the Octane release will also include tooling (codemods) and guidance on how to incrementally migrate existing apps to the new, clearer idioms.

Ember's hybrid approach to templating uses a programming language approach to rendering and a more vanilla approach to the rest of your application.

Because HTML (and templating concepts) are so widely known, we can get very aggressive in rendering without seeming unfamiliar.

No mutable variables! Block-based let! No methods!

These aren't Rails or PHP templates transplanted into the modern front-end world.

They're a genuinely different attack on the conceptual essence of front-end programming.

At the end of the day, it's not enough to build tools that the most expert among us can use to write good applications.

We also need to find ways to make any necessary restrictions intuitive enough for developers of diverse experiences to use successfully.

React Hooks are one attack on that problem. Declarative rendering mixed with JavaScript for app code is another.

I think the jury's still out on which approach, when fully developed, will prove to result in the more robust applications when built by mere mortals.

The last few years have substantially advanced the state of the art through a lot of cross pollination of ideas and approaches.

The end of 2019 feels like the start of a new wave of experimentation, less encumbered by the history of front end tooling than ever before.

😁😁😁