Someone ported #Haskell #Concur to the new #GHC #Javascript backend. It uses nanomorph for DOM diffing instead of #VDOM!
@westbrook @davatron5000 @stubbornella I suspect this might overlap with existing #HtmlModules work.
Also one more idea similar to 1.:
5. Could we use this format to do the initial render of a component? By which I mean that #Angular compiles components to #JavaScript which looks like:
```
function renderComponent() {
if (initialRender) {
createComponentDom();
} else {
updateExistingDom();
}
}
```
This always bugged me as inefficient, because the first branch is only ever executed once per component instance. If we compiled components to this SFC format, could we just do the first render at compile time, generate the HTML directly and drop that `createComponentDom` function?
I'm not knowledgeable enough to say that definitely makes sense, but I think it's an interesting idea at least.
Not sure if other frameworks could benefit from similar optimizations, I suspect #React would not, but I'm less clear on non-#VDom frameworks.
Playing a bit with #Preact / #JSX today and am feeling the pain of not having host elements. I've realized that because a "component" is really just a #VDOM template, there is no implicit contract around what it actually rendered.
As an arbitrary example, what if I want to set a style on a `<Foo />` component? What selector should I use for that style? I have no idea what `<Foo />` will actually generate, or even how many top-level elements it will output. The `Foo` component _must_ expose some kind of `className` or other API to provide this behavior, it's not implicit at all.
Maybe this is good because it provides stronger encapsulation. But it can also lead to bugs. If I render `<Header />` a `header` CSS selector is _probably_ right. But what if `<Header />` actually renders:
<div>
<header>...</header>
</div>
Then a `header` selector isn't actually the top-level element and my style could easily be wrong.
Just some idle thoughts about the lack of host elements.
Apparently #Preact (or #JSX / #VDom) cannot directly render comments: https://github.com/preactjs/preact/issues/1469#issuecomment-477510098
I get why that's not super useful in a client-side context, but particularly for server-side rendering use cases I would expect to be able to render comments. I would expect to be able to render any arbitrary DOM structure, but I guess that's not possible out of the box?
Not sure if there any workarounds to render comments in Preact. I'm not immediately able to find anything, might be a challenge to work around.
Marko JS
@MarkoDevTeam
A declarative, HTML-based language that makes building web apps fun
#nodejs #javascript #isomorphic #frontend #dom #serversiderendering #vdom #clientsiderendering #uicomponents #webdev
markojs.com/
Hacker News
Anupam 🇮🇳《ミ》λ≡
Doug Parker 🕸️
pablolarah