3 ms·

The interesting thing about switching renderers is that you are now free of the DOM. I just think web developers only know one api really well (the DOM and it’s

The interesting thing about switching renderers is that you are now free of the DOM. I just think web developers only know one api really well (the DOM and it’s offspring frameworks) that when you give us a blank canvas (no pun intended), we resort to the same data structure and api of what we’ve always known. We’re truly free to make a <Modal /> however we like. Perhaps not even in those tags. We just don’t know it yet.

eyelidlessness 5y ago
JSX has very little to do with the DOM. It’s always been a language extension to provide render-agnostic expressions. Non-DOM renderers have existed for years (React Native, smart TV, CLI, PDF, PowerPoint, the list keeps going…). The reality is it’s a good abstraction because it’s so decoupled from the DOM, but it’s associated with the DOM and web mainly for historical reasons. It’s also worth noting that there are similar extensions to other languages that are similarly render-agnostic.
- runawaybottle 5y ago
  So I have a to contest that a bit. It parallels the DOM in structure entirely. You can see how this is the truth when you want to have components outside of a parent-child hierarchy belong to the same ‘component’, you have to use this very abstract concept of a Portal, as in, nothing is natural once you start thinking out of the tree structure. Certainly you can map this api to a variety of other APis, which I’m sure is what they did with React Native, but it was built with the DOM tree structure in mind. I think it’s one of the most brilliant things frontend has ever created along with Jquery, but they are both slaves to the DOM.
  - brundolf 5y ago
    Lots of things are already tree-structured though, including Three.js
  - eyelidlessness 5y ago
    > So I have a to contest that a bit. It parallels the DOM in structure entirely. You can see how this is the truth when you want to have components outside of a parent-child hierarchy belong to the same ‘component’, you have to use this very abstract concept of a Portal, as in, nothing is natural once you start thinking out of the tree structure. This isn’t a property of JSX, it’s a property of a virtual DOM. The former is typically used with the latter, but don’t have to be. SolidJS is an example of JSX without VDOM. It compiles to plain DOM operations, you only have a component tree during development. And like React, its compiler was designed to be render-agnostic and can be/is used in other environments. It’s funny you should mention Portal here. I am working on a technique/hopefully eventual library to transparently (without requiring developer intervention) use Portals as a partial hydration solution—completely sidestepping the tree structure and only rendering interactive components. I believe it will be framework agnostic for anything that provides (or can provide) a hyperscript/createElement function and Portal-like functionality. And like those frameworks, it’s just a declarative data structure and can render to anything. > Certainly you can map this api to a variety of other APis, which I’m sure is what they did with React Native, but it was built with the DOM tree structure in mind. I’ve spent a lot of time (maybe too much time) looking at the underlying renderer abstractions of React, Preact, Solid, JSX Lite, several others. The only one tightly coupled to DOM is Preact (and even that isn’t totally coupled). In fact that coupling is one of the major advantages Preact has in terms of package size. React’s design has a separate renderer interface/abstraction that is primarily oriented around state reconciliation; the DOM implementation is just one of many. Solid’s JSX (implemented in a Babel transform somewhat misleadingly called dom-expressions) is similarly decoupled from its DOM implementation with an abstract renderer interface. The difference is rather than state reconciliation it’s reactive. JSX Lite’s render target is even more abstract, it renders an intermediate data structure that can be transformed to other component libraries, and even some design apps. You can implement a JSX transform to basically any render target, without React. You can even skip the entire notion of state, events, interaction. I even use it on my personal site to generate PNGs at build time! Unless you’re looking at my source code you’d never know it.
    - eyelidlessness 5y ago
      Correction: Solid’s dom-expressions compiler is more directly coupled to DOM APIs than I remembered. In hindsight this makes sense given the design, but I imagine it could provide the level of abstraction I misremembered. It would probably harm performance without some second-pass build time inlining.

eyelidlessness 5y ago

JSX has very little to do with the DOM. It’s always been a language extension to provide render-agnostic expressions. Non-DOM renderers have existed for years (React Native, smart TV, CLI, PDF, PowerPoint, the list keeps going…). The reality is it’s a good abstraction because it’s so decoupled from the DOM, but it’s associated with the DOM and web mainly for historical reasons. It’s also worth noting that there are similar extensions to other languages that are similarly render-agnostic.

runawaybottle 5y ago
So I have a to contest that a bit. It parallels the DOM in structure entirely. You can see how this is the truth when you want to have components outside of a parent-child hierarchy belong to the same ‘component’, you have to use this very abstract concept of a Portal, as in, nothing is natural once you start thinking out of the tree structure. Certainly you can map this api to a variety of other APis, which I’m sure is what they did with React Native, but it was built with the DOM tree structure in mind. I think it’s one of the most brilliant things frontend has ever created along with Jquery, but they are both slaves to the DOM.
- brundolf 5y ago
  Lots of things are already tree-structured though, including Three.js
- eyelidlessness 5y ago
  > So I have a to contest that a bit. It parallels the DOM in structure entirely. You can see how this is the truth when you want to have components outside of a parent-child hierarchy belong to the same ‘component’, you have to use this very abstract concept of a Portal, as in, nothing is natural once you start thinking out of the tree structure. This isn’t a property of JSX, it’s a property of a virtual DOM. The former is typically used with the latter, but don’t have to be. SolidJS is an example of JSX without VDOM. It compiles to plain DOM operations, you only have a component tree during development. And like React, its compiler was designed to be render-agnostic and can be/is used in other environments. It’s funny you should mention Portal here. I am working on a technique/hopefully eventual library to transparently (without requiring developer intervention) use Portals as a partial hydration solution—completely sidestepping the tree structure and only rendering interactive components. I believe it will be framework agnostic for anything that provides (or can provide) a hyperscript/createElement function and Portal-like functionality. And like those frameworks, it’s just a declarative data structure and can render to anything. > Certainly you can map this api to a variety of other APis, which I’m sure is what they did with React Native, but it was built with the DOM tree structure in mind. I’ve spent a lot of time (maybe too much time) looking at the underlying renderer abstractions of React, Preact, Solid, JSX Lite, several others. The only one tightly coupled to DOM is Preact (and even that isn’t totally coupled). In fact that coupling is one of the major advantages Preact has in terms of package size. React’s design has a separate renderer interface/abstraction that is primarily oriented around state reconciliation; the DOM implementation is just one of many. Solid’s JSX (implemented in a Babel transform somewhat misleadingly called dom-expressions) is similarly decoupled from its DOM implementation with an abstract renderer interface. The difference is rather than state reconciliation it’s reactive. JSX Lite’s render target is even more abstract, it renders an intermediate data structure that can be transformed to other component libraries, and even some design apps. You can implement a JSX transform to basically any render target, without React. You can even skip the entire notion of state, events, interaction. I even use it on my personal site to generate PNGs at build time! Unless you’re looking at my source code you’d never know it.
  - eyelidlessness 5y ago
    Correction: Solid’s dom-expressions compiler is more directly coupled to DOM APIs than I remembered. In hindsight this makes sense given the design, but I imagine it could provide the level of abstraction I misremembered. It would probably harm performance without some second-pass build time inlining.