> What should a developer do that needs to share state across a Forgo app?

We already have many facilities in JS to handle state. Singleton patterns, closures etc. The example on the website uses closures to handle component state - which is simpler than React's hooks based approach.

  function SimpleTimer() {
    let seconds = 0; // Just a plain variable

    return {
      render(props, args) {
        setTimeout(() => {
          seconds++;
          rerender(args.element); // rerender!
        }, 1000);
  
        return <div>{seconds} secs have elapsed...</div>;
      },
    };
  }

> I don't consider reducers, actions, redux/flux to be React specific

They didn't emerge from React - but it isn't possible to do React without them. When I conduct trainings, I often see some of my students go - wow, why would you do that? So Forgo basically is an exploration of how to simplify things - and to let users pick their desired level of complexity.

I understand where the Redux terminology gets mixed up with React and people believe they're one and the same, but it's totally possible to do React without touching reducers, actions, or Redux.

Maybe you mean it's not realistic to write React "beyond toy examples" or "in the real world" without Redux, but still, I'd beg to differ there. You can get very far with plain React and the context API and other libraries. Redux definitely isn't required.

Forgo does look cool though! I like the idea of using plain variables for state, and returning an object allows you to add other things to that object (didMount, didUpdate, unmount etc).

Yeah, even with large-ish projects, just by refactoring some of your state manipulation into separate libraries that you manually hook into your top-level components, you can get by quite fine without a whiff of Redux.

That said, this is a cool framework, congrats on completing it! I'm also working on a minimalist React-ish framework though in a very different approach.

> They didn't emerge from React - but it isn't possible to do React without them.

It is 100% possible to build large React apps without redux/flux. There are entire ecosystems built around, say Mobx, among many other libraries and tools which don't even follow the flux style patterns.

> The example on the website uses closures to handle component state

I'm not asking about component state; I'm asking how do multiple components access app-wide state. I can't use a singleton for that; how do I know when that singleton is updated? I guess I could use a proxy but I don't want to do that.

> and to let users pick their desired level of complexity.

React is the view layer. It doesn't enforce any type of data layer or state management layer.

> I can't use a singleton for that; how do I know when that singleton is updated?

It's up to the developer to make that decision. An AccountInfo control could be listening to "ACCOUNT_INFO_CHANGE" events (emitted when account info changes), and can subsequently rerender and read off some singleton state. Rerenders are explicit.

And like you said, proxies could be another option.

> They didn't emerge from React - but it isn't possible to do React without them.

Here is a React/WebGL game I made which tracks a lot of variables and state, but does not use redux/flux...because it's 100% possible to make even make a 3D game with React without them!!!

https://focused-ritchie-7245d6.netlify.app/

> The example on the website uses closures to handle component state

This looks a lot like closure components from Mithril.js[0], which have been around for several years. It's nice to see people independently come to the conclusion that this approach is simpler :)

[0] https://mithril.js.org/components.html#closure-component-sta...

Thanks, hadn't seen this prior art!

> They didn't emerge from React - but it isn't possible to do React without them.

I've created many React apps without any complex state management libraries :-)

I work on a templating library called lit-html that aims to just solve the declarative DOM w/ property & events bindings problem: https://lit-html.polymer-project.org/

It's plain JS with a very similar DX to JSX, and I think addresses that really well.

My team also works closely with Chrome, Safari, and Firefox on proposals like Template Instantiation that aim to build up more APIs that template libraries can use to be smaller, faster, and more interoperable.

I really think we will eventually get good templating in the DOM so at least the most common use-cases are taken care of.

Where is the working group at with that proposal? I've been eyeing it closely, but it hasn't seen any significant movement in over two years, last I checked. I'm excited about template instantiate, though I worry the API is going to be tied to having template element instances, instead of being part of the HTMLTemplateElement and its own thing I could take advantage of with string templates. I also haven't seen any place where I can give feedback formally on the proposal to the working group :(

HTML imports were supposed to be the holy grail to solve this, but nobody but Chrome supported it :(

It's being discussed mainly in the WICG web components GitHub repo. There are recent issues in here: https://github.com/WICG/webcomponents/issues

Every time I look at lit I get this unsettling feeling that it’s almost what I want but can’t be, because it loses the only thing I want in JSX. Lit fundamentally targets templates with HTML output. Which is great for what it is. But the thing JSX offers that nothing else does is:

- return values are a data structure, so they’re render-target/render-implementation agnostic

- it’s compile time only/effectively a macro, so the compiler can choose how to render subtrees

I love the “it’s actually part of the language not a build tool” part of lit, but it can’t satisfy those other goals without giving up its core selling points.

lit-html also returns a data structure - strings and values. You can interpret the strings however you want.

JSX actually doesn't return a data structure. It's syntax only and some transforms do things quite different from what React.createElement() does. And this is part of the problem with it and why it can't really be standardized - there's no semantics to standardize.

lit-html as an render implementation does indeed target only the DOM, it's not trying to target non-web platforms.

Sorry, I misstated my point. JSX is itself a data structure, not interpolated strings and values. That makes it closer to hyperscript. But it doesn’t necessarily return anything or have a runtime value at all.

The problems you cite are exactly what I meant to say are its strengths. Because it’s entirely undefined syntax that only corresponds to data, it can be used as a general purpose macro for anything from React.createElement to defining a web component to defining an output for a CLI to defining a test or an API endpoint or anything at all. It’s a general purpose DSL, and the fact that it looks like HTML/XML is just convenient for its most common usage.

JSX really isn't a data structure, is just syntax. Sometimes it's compiled to statements, like with some idom transforms.

JSX is an expression with structural semantics. It doesn’t have to be compiled to a data structure but at the AST level it definitely is, which is the whole point.