Skip to content

Instantly share code, notes, and snippets.

@WebReflection
Last active October 6, 2024 12:35
Show Gist options
  • Save WebReflection/2d64f34cf58daa812ec876242c91a97c to your computer and use it in GitHub Desktop.
Save WebReflection/2d64f34cf58daa812ec876242c91a97c to your computer and use it in GitHub Desktop.
Proposal: an ESX for JS implementation

About

Highly Experimental

If you are using this already, consider changes soon due the discussion around current ESX proposal.

Feel free to keep an eye on udomsay as that will be the implementation reference for consumers.


This is a TC39 proposal and there is a Babel transformer for it too.

There is also a zero-tooling solution based on template litearl tags in this repository, which solves almost all pain-points around having ESX as syntax.


In a quest to explore improvements over common JSX transformers I have managed to find great performance able to compete with template literal based libraries.

In this document I would like to describe, via JS itself, and as PoC, how JSX could be both rebranded as ESX and improved.

Goal

Differently from E4X, but also differently from JSX, this proposal leaves developers provide their own "render" implementation, freeing ESX usage from any previous attempt to confine JSX or E4X into the DOM world, where it's been proven, in the JSX case, it's not really where it belongs, as it can be used as neutral, general purpose, DSL.

This document describes all the moving parts of ESX in a way that:

  • there is no DOM at all involved, only new primitives introduced by ESX
  • all relevant details around each part of the transformation are described through simple objects, here represented as classes instances, but these easily work just as object literals (easy polyfills via transformers)
  • no extra scope pollution is needed, hence no jsxPragma or jsxFragment around is required at all (no React.createElement or React.Fragment needed, nor udomsay.interpolation)
  • all classes can be used just as types to infer, as oppsite of being really classes ... no clashing in the logic can happen neither. The only global class needed out there is ESXToken which carries types and the prototypal inheritance for brand check.
  • hints to "parse-once" through templates and/or Components are all over the place, making usignal like alternative implementations possible, but also any SSR related project can benefit from these

ESX

// base class for instanceof operations
class ESXToken {
  static ATTRIBUTE: number;
  static INTERPOLATION: number;
  static STATIC: number;
  static FRAGMENT: number;
  static ELEMENT: number;
  static COMPONENT: number;
}

// possible `attributes` entry
interface ESXAttribute {
  type = ESXToken.ATTRIBUTE;
  dynamic: boolean;
  name: string;
  value: unknown;
}

// possible `attributes` or `children` entry
interface ESXInterpolation {
  type = ESXToken.INTERPOLATION;
  value: unknown;
}

// possible `children` entry
interface ESXStatic {
  type = ESXToken.STATIC;
  value: string;
}

// always the same reference when this is used as outer template
interface ESXNode extends ESXToken {
  id: object?
  children: (ESXStatic | ESXInterpolation | ESXNode)[];
}

// <></>
class ESXFragment extends ESXNode {
  type = ESXToken.FRAGMENT;
}

// <any-element />
class ESXElement extends ESXNode {
  type = ESXToken.ELEMENT;
  name: string;
  value: string;
  attributes: (ESXAttribute | ESXInterpolation)[];
}

// <AnyComponent />
class ESXComponent extends ESXNode {
  type = ESXToken.COMPONENT;
  name: string;
  value: function;
  attributes: (ESXAttribute | ESXInterpolation)[];
  get properties(): object?;
}

Code samples

To better understand what the transformer currently produce, please see this innput and compare it with this output.

@fusionstrings
Copy link

Yes, it’s a wishful thinking for success but in my eyes you’ve already succeeded and set the example on how to approach and do right thing.

The rest will be history. Someone is going to pick this up definitely, if not then still this is very brave.

@fusionstrings
Copy link

We shall not forget that for many, JSX is opaque and this may have very niche audience anyway, amongst them almost everyone is tied to one or other distro 🫣.

@bresnow
Copy link

bresnow commented Nov 27, 2022

This is interesting. I followed your repos for the GJS and ended up writing a gtk jsx factory/renderer semi independently. Saw this for the first time and think you have a powerful idea here.

@trusktr
Copy link

trusktr commented Mar 5, 2023

There's other ones too:

  • solid.js html
  • Lit html
  • etc.

The thing is, we can standardize syntax, but I don't think anyone is confident of which runtime implementation is the best yet.

Plus I personally don't think that this belongs in JavaScript spec. JavaScript is not specifically about making trees (namely DOM trees). I think a spec like this might make more sense as part of browser DOM API specs. I think it would be a lot more likely for a browser to standardize some sort of html template string language.

I just don't think that ECMAScript itself is likely to be the carrier of this feature, because it is very specific compared to other APIs (f.e. Math.whatever is an stdlib that is highly useful in many generic cases, not just tree building, and a language aims to be very generic).

Maybe WICG.io would be a better place to propose this (but I still think runtime semantics would currently hold it back). I like Solid.js html better than Lit html and esx, for example. I like the way that it works. But that's just my taste.

It will take a lot of time to see what's really the best runtime.

@WebReflection
Copy link
Author

I think it would be a lot more likely for a browser to standardize some sort of html template string language.

the whole premises of ESX is that it has nothing to do with HTML and it doesn't want to ... it's rather a XML compat DSL that translates into JS tokens.

Until people will couple JSX to HTML this standard will never happen. React JSX works in React native too, and good old E4X worked regardless of HTML.

There's no HTML in ESX, and that's no accident, as well as there's nothing DOM related too, to keep it general purpose, just like JS is ... which is why this could be an ECMAScript feature, not a WHATWG biased half powerful feature.

Trees are a structure that exist in every PL and since about ever, the fact Front End people keep thinking tress are only a DOM matter is, imho, a Front End people thinking limitation.

@WebReflection
Copy link
Author

P.S. please read the whole thing and see libraries already using ESX or transformers ... there's no limitation around what HTML can do, there's just a srializable JS friendly universal struct that can represent any kind of tree with attributes and holes ... every diversion from this representation will doom the proposal or the standard itself, and in the very same TC39 post people already said ESX is so cool, but I want it to do HTML things and that's where ESX will fail, if implemented outside pure ECMAScript syntax specification.

@WebReflection
Copy link
Author

P.S.2 this gist needs an update as the Token is now a single one, capable of everything described in the initial gist ... read the TC39 related post first and feel free to contribute there, not in this gist.

I can't unfortunately close gists but I am tempted to erase this one as it's not serving any purpose for the ESX cause.

@jogibear9988
Copy link

@WebReflection Your proposal was also Mentioned in this discord Thread: https://discord.com/channels/767813449048260658/1226165073022554172

Maybe you should look to also create a official proposal at https://github.com/tc39/proposals (described here: https://github.com/tc39/ecma262/blob/HEAD/CONTRIBUTING.md)

@o-t-w
Copy link

o-t-w commented Apr 8, 2024

Even though Signals is only a stage 0 proposal, it would be cool to see some examples of using signals in conjunction with ESX. Also would love to see some examples of using ESX in conjunction with custom elements.

@WebReflection
Copy link
Author

WebReflection commented Apr 8, 2024

@jogibear9988 I can't access that discord ... no idea, but I did write on TC39 channel and crickets happened

@o-t-w udomsay has it all: it's ESX with signals https://github.com/WebReflection/udomsay#readme ... it's also listed in js-frameworks-benchmark and it performs extremely well despite not being native.

@jogibear9988
Copy link

jogibear9988 commented Apr 8, 2024

@WebReflection

you can join here : https://discord.gg/VRzgBSxM (if you'd like to)

the comment in the discord was:

"I don't think something really registers as a proposal until it's put into GitHub based on the TC39 proposal template, and at least briefly presented before the commitee. I think there would be a lot of feedback, and the champion would have to be open to it."

@o-t-w
Copy link

o-t-w commented Apr 8, 2024

Standards is always a long tedious process. I wouldn’t call a thread with over 100 comments “crickets”.

@WebReflection
Copy link
Author

@o-t-w I suggested already TC39 standards that got implemented in ECMAScript, the crickets was around the fact I've no idea what else I should do to move that forward and as I need a champion to show interest it's time and effort to write down any proposal knowing nobody cares or showed interest ... that's crickets to me.

@shellscape
Copy link

dear lord yes. I've been futilely trying to develop TypeScript types for cross-framework JSX compat and this proposal is exactly what we need.

@shellscape
Copy link

@jogibear9988 that invite link is invalid

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment