Another Virtual DOM thing - which is obviously wrong.
Show HN: HyperApp – 1k JavaScript framework for building web applications
101–110 of 169 posts
Re: Show HN: HyperApp – 1k JavaScript framework for building web applications
#102Earlier quoted context omitted.
Highly recommended to watch https://youtu.be/Io6JjgckHbg
Yeah nah, I'm not watching a 30mn video on something I'm not interested in to get what amounts to a 2-paragraphs answer.
Re: Show HN: HyperApp – 1k JavaScript framework for building web applications
#103Re: Show HN: HyperApp – 1k JavaScript framework for building web applications
#104If 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
#105Earlier quoted context omitted.
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
#106Earlier quoted context omitted.
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.
Second question ... why use,different rendering engines?
Re: Show HN: HyperApp – 1k JavaScript framework for building web applications
#107Earlier 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.
Not needed for 99.9% of features
Re: Show HN: HyperApp – 1k JavaScript framework for building web applications
#108This makes me almost want to write web code again - compared to things like React and Angular 1-2-3-4-5-6.
React has a massive API for what is something essentially quite simple.
Personally my favourite "alternative" rendering library is hyperdom. Fast, simple and just gets the job done.
Re: Show HN: HyperApp – 1k JavaScript framework for building web applications
#109If 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.…
Or is there tooling that works for the tagged template approach?