Replies: 1 comment
-
I found a more recent comment on the topic of FB JSX 2.0: facebook/jsx#124 It consolidates some issues to take into consideration. There's actually a label for a few convos: https://github.com/facebook/jsx/labels/Proposal%202.0 |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
As we all know (but mostly the people who are more in-depth to Solid), we've been using dom-expressions as the way for SolidJS to transform JSX expressions into fine-grained, VDOM-less, reactive code. This thread would hopefully discuss what lies ahead in the development of Solid DSL and DOM Expressions.
To start, the intent of Solid DSL is to provide an extension to the current feature set of JSX. The capabilities of JSX itself is fairly limited, and there have been many attempts, proposals and discussions to further extend its capabilities, even to the point of proposing the idea of having JSX 2.0. Much to the disappointment of many, it seems that the specification of JSX is no longer active nor being developed further. With no foreseeable resolution to this, we can fairly assume that JSX will remain as it is for years to come.
In similar fashion, the JSX spec being no longer developed isn't something new. For example, Markdown's latest update was released on December 17, 2004, that's 17 years ago! With a handful of features, there has been a lot of forks to the original specification such as CommonMark and Github-flavored Markdown. What does this say to us? That the best course action would be to fork the specification of JSX and extend the features with our own hands.
Forking, however, comes with tradeoffs. Tooling is such a crucial part of what comes after. JSX has phenomenal tooling, it even has TS support. With this in mind, this would require us not only designing the DSL and its features, but also hopefully provide a first-party support for the tools. The interesting part is that, most tools usually share the same core and that core would be the parser and the compiler.
Solid DSL would require us to write a compiler from scratch, and although it may sound easy (given that it is just JSX), it would require the need to write an ECMAScript-compliant compiler from scratch. Babel, which what dom-expressions is built out from, can no longer help us attain what we need, because of Babel refusing to allow plugins to extend or provide an ability to generate custom tokens/syntax, which would require forking Babel itself. This also means that what ever we've implemented with dom-epxressions, we would need to reimplement in Solid DSL's future compiler. This means that, if not disproven, Solid DSL will become dom-expressions' successor, but this doesn't mean deprecating dom-expressions (unless Solid DSL is proven a success).
Being a successor, we would want Solid DSL to be 100% backwards-compatible with both the current features of JSX and dom-expressions (minus Babel), but we also need it to be better. We can probably implement the ideal compiler into lower-level languages such as Rust and Go, and provide an API that would allow us to develop tools such as intellisense, linter, etc. that would be allow us to be on par with current build tools (e.g. esbuild) and better in terms of tooling (TypeScript) or be on par with other faster tools (e.g. Astro). I'm positive that Solid DSL would be beneficial and user-friendly in terms of DX, UX and productivity.
That's all 😄
Beta Was this translation helpful? Give feedback.
All reactions