I built godom: Go owns the DOM and the browser is just a rendering surface
godom은 Go 프로세스가 DOM을 직접 소유하고 브라우저는 단순 렌더링 서피스로 동작하는 Go 기반 UI 프레임워크입니다. Electron이나 복잡한 JS 프론트엔드 없이 단일 바이너리로 빌드되어 브라우저 탭에서 UI를 보여주며, 상태가 브라우저 종료 후에도 유지되고 다중 탭 및 다중 기기 동기화가 기본으로 지원됩니다. 이는 로컬 단일 사용자용 도구에 최적화된 설계로, 복잡한 웹 프레임워크나 API 설계 없이 Go 코드만으로 UI를 구현할 수 있습니다. 보안은 신뢰된 네트워크 내 사용을 전제로 하며, 간단한 토큰 인증만 제공해 공개 인터넷용 웹앱에는 적합하지 않습니다.
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/
sayzard
Hacker News
Anupam 🇮🇳《ミ》λ≡
Doug Parker 🕸️
pablolarah