Live data from Hacker News

Show HN: HyperApp – 1k JavaScript framework for building web applications

github.com

51–60 of 169 posts

Re: Show HN: HyperApp – 1k JavaScript framework for building web applications

#51

Earlier quoted context omitted.

IMO, the problem of composing renderers is solved at the component level. Each component should be able to freely choose its rendering library and control its own encapsulated DOM without interfering with other components, or leaking it's choice of template library to the outside. Web Components and Shadow DOM make this possible. You can mix and match components that use lit-html, Polymer, Preact, etc., and mostly li…

But mixing and matching causes your page to bloat due to needing to download all the different libraries, right?

Yup.

I think within your own components it makes sense to stick with a single library setup for this reason, but atleast if you want to use a third-party component you don't have to rule out components that use different rendering machinery. You just have to weigh that additional download penalty.

Re: Show HN: HyperApp – 1k JavaScript framework for building web applications

#52

In the same vein there's Mithril. It's 8kb but includes a router and a fetch polyfill! I love these little JS frameworks :) https://mithril.js.org/

Just want to second Mithril here. It is an awesome and refreshing approach. I love it too.

Re: Show HN: HyperApp – 1k JavaScript framework for building web applications

#53

If you're interesting in a reactive template library that doesn't require a compiler for non-standard JavaScript syntax, check out a library I've been working on for a little while now, lit-html: https://github.com/Polymer/lit-html Where JSX would look like this: const view = (state, actions) => ( {state.count} actions.down(1)}>- actions.up(1)}>+ ) The lit-html would be: const view = (state, actions) => html` {state.…

> ... expensive VDOM diffs Wait, I thought VDOMs were supposed to be fast(er). Note: I'm not a FE Dev, so I'm only going by stuff I (think I) read, not write.

fast(er) is relative. and _not_ doing a thing is often faster than doing a thing.

Re: Show HN: HyperApp – 1k JavaScript framework for building web applications

#55

If you're interesting in a reactive template library that doesn't require a compiler for non-standard JavaScript syntax, check out a library I've been working on for a little while now, lit-html: https://github.com/Polymer/lit-html Where JSX would look like this: const view = (state, actions) => ( {state.count} actions.down(1)}>- actions.up(1)}>+ ) The lit-html would be: const view = (state, actions) => html` {state.…

> Nearly identical. lit-html uses ``s and cloning, so that it doesn't have to do any expensive VDOM diffs.

So… it's not doing reconciliations and is just replacing the entire tree on every render, losing things like cursor position and forcing the browser to re-render and re-layout the entire thing?

Re: Show HN: HyperApp – 1k JavaScript framework for building web applications

#57

If you're interesting in a reactive template library that doesn't require a compiler for non-standard JavaScript syntax, check out a library I've been working on for a little while now, lit-html: https://github.com/Polymer/lit-html Where JSX would look like this: const view = (state, actions) => ( {state.count} actions.down(1)}>- actions.up(1)}>+ ) The lit-html would be: const view = (state, actions) => html` {state.…

That looks just like choo!

choo https://choo.io/ uses tagged templates too.

It's 4kilobytes.

Re: Show HN: HyperApp – 1k JavaScript framework for building web applications

#58
post #53

Earlier quoted context omitted.

> ... expensive VDOM diffs Wait, I thought VDOMs were supposed to be fast(er). Note: I'm not a FE Dev, so I'm only going by stuff I (think I) read, not write.

fast(er) is relative. and _not_ doing a thing is often faster than doing a thing.

Isn't vdom diff a way to not do things?

Re: Show HN: HyperApp – 1k JavaScript framework for building web applications

#59
post #53

Earlier quoted context omitted.

> ... expensive VDOM diffs Wait, I thought VDOMs were supposed to be fast(er). Note: I'm not a FE Dev, so I'm only going by stuff I (think I) read, not write.

fast(er) is relative. and _not_ doing a thing is often faster than doing a thing.

Replacing the entire tree is very rarely, if ever, faster than doing the fast thing.

Re: Show HN: HyperApp – 1k JavaScript framework for building web applications

#60
post #57

If you're interesting in a reactive template library that doesn't require a compiler for non-standard JavaScript syntax, check out a library I've been working on for a little while now, lit-html: https://github.com/Polymer/lit-html Where JSX would look like this: const view = (state, actions) => ( {state.count} actions.down(1)}>- actions.up(1)}>+ ) The lit-html would be: const view = (state, actions) => html` {state.…

That looks just like choo! choo https://choo.io/ uses tagged templates too. It's 4kilobytes.

The equivalent would be https://github.com/choojs/nanomorph, choo's diffing engine based on morphdom.
Post reply on HN