5 ms·
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 o
by spankalee 8y ago
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 https://github.com/Polymer/lit-html
Where JSX would look like this:
const view = (state, actions) => (
<div>
<h1>{state.count}</h1>
<button onclick={() => actions.down(1)}>-</button>
<button onclick={() => actions.up(1)}>+</button>
</div>
)
The lit-html would be:
const view = (state, actions) => html`
<div>
<h1>{state.count}</h1>
<button onclick={() => actions.down(1)}>-</button>
<button onclick={() => actions.up(1)}>+</button>
</div>
`;
Nearly identical. lit-html uses `<template>`s and cloning, so that it doesn't have to do any expensive VDOM diffs.
- malydok 8y agoThen you need to send lit-html over to the client also. This would be a great alternative if one doesn't already use Babel, but what's the selling point otherwise? Is there an easy way to combine lit-html's render with the HyperApp one?
- spankalee 8y agoIMO, 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 likely HyperApp.
- simplify 8y agoBut mixing and matching causes your page to bloat due to needing to download all the different libraries, right?
- seabrookmx 8y agoYup. 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.
- iteriteratedone 8y agoWell this level should be abstracted to a common interface , why is the component choosing ??? It can be a config detail like what storage engine to use Second question ... why use,different rendering engines?
- Vinnl 8y agoWell... At this point you can't e.g. include two web components when one of them uses Polymer 1 and one of them uses Polymer 2, for example...
- spankalee 8y agoThat's only because Polymer 1 and 2 installed themselves on the `window.Polymer` global, so they would conflict, and Polymer 1 used the old Web Components v0 spec. Polymer 3.0 doesn't write to any globals and can intermix with LitElement, other Web Components libraries, and future Polymer 4.0 and beyond.
- Vinnl 8y agoThat's a great step forward :) And how about using two Web Components that depend on a third component? For example, what if I'm using two third-party components that both depend on LitElement, but on different versions of LitElement? Will those still conflict?
- plexicle 8y agoLoving Polymer 3.0 and the new lit-element (which I believe just straight up used lit-html behind).
- ricardobeat 8y agoAlso check out https://viperhtml.js.org/hyper.html https://viperhtml.js.org/hyper.html, original inspiration for lit-html. Same principle, different implementation, takes advantage of special string literal properties to achieve impressive speeds.
- JustSomeNobody 8y ago> ... 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.
- abiox 8y agofast(er) is relative. and _not_ doing a thing is often faster than doing a thing.
- gldalmaso 8y agoIsn't vdom diff a way to not do things?
- spankalee 8y agoYou have to do the diff, which is a thing. lit-html doesn't do the diff because it knows from the template what parts actually change. No need to diff the parts that never change.
- eropple 8y agoReplacing the entire tree is very rarely, if ever, faster than doing the fast thing.
- rictic 8y agoTrue, but neither virtual-dom nor lit-html replace the entire tree.
- iteriteratedone 8y agoFaster: general notuon of speed ... we are splitting hairs Not needed for 99.9% of features
- acdha 8y agoIt ultimately comes down to Amdahl's law: doing something in a browser requires updating the DOM. Since you always have to do the DOM processing, the only way adding the extra virtual DOM work will be a net win is if it makes it easier to avoid unnecessary updates or allows something like ordering updates to avoid triggering repeated layouts / reflows[1]. Since updating the DOM is relatively fast in modern browsers it's not particularly hard to find cases where the work the virtual DOM has to do cancels out any savings. 1. See e.g. https://developers.google.com/web/fundamentals/performance/rendering/avoid-large-complex-layouts-and-layout-thrashing https://developers.google.com/web/fundamentals/performance/r..., a list of triggers at https://gist.github.com/paulirish/5d52fb081b3570c81e3a https://gist.github.com/paulirish/5d52fb081b3570c81e3a, and https://github.com/wilsonpage/fastdom https://github.com/wilsonpage/fastdom for a common technique to avoid it by manually ordering read operations before writes.
- masklinn 8y ago> Nearly identical. lit-html uses `<template>`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?
- ithkuil 8y agoHighly recommended to watch https://youtu.be/Io6JjgckHbg https://youtu.be/Io6JjgckHbg
- masklinn 8y agoYeah nah, I'm not watching a 30mn video on something I'm not interested in to get what amounts to a 2-paragraphs answer.
- anonytrary 8y ago30m sends you home? Watch it on 2x and skip parts you aren't interested in.
- itsnotlupus 8y agoI really want a way to get a generated voice recognition transcript for all that content people really think needs to be in video form. 2x playback is still 14:45 too long in this instance.
- spankalee 8y agoIt's not that anyone thought it _needed_ to be in video form, it's just a conference talk. For reading there's the readme here: https://github.com/Polymer/lit-html https://github.com/Polymer/lit-html and documentation site here: http://polymer.github.io/lit-html/ http://polymer.github.io/lit-html/ They both go into how lit-html works and how it doesn't just throw away and recreate the DOM on re-renders, though I admit the docs could still be better.
- gyrgtyn 8y agoThat looks just like choo! choo https://choo.io/ https://choo.io/ uses tagged templates too. It's 4kilobytes.
- ricardobeat 8y agoThe equivalent would be https://github.com/choojs/nanomorph https://github.com/choojs/nanomorph, choo's diffing engine based on morphdom.
- always_good 8y agoBut then you miss out on html syntax highlighting and jsx eslint. Or is there tooling that works for the tagged template approach?
- tlrobinson 8y agoYes: https://github.com/Polymer/lit-html/issues/191 https://github.com/Polymer/lit-html/issues/191
- localvoid 8y ago> so that it doesn't have to do any expensive VDOM diffs. I am wondering, how is it possible that such non-expensive algorithm is more expensive than many VDOM libraries in this benchmark[1] ? 1. https://rawgit.com/krausest/js-framework-benchmark/master/webdriver-ts-results/table.html https://rawgit.com/krausest/js-framework-benchmark/master/we...
- cztomsik 8y agoPlease note: 1. benchmarks have zero information value 2. be careful about wording, react does effective DOM update, but effective does not always mean fast - what I mean is that compiled templates are usually much faster than doing vdom diffing along with all of that destructuring and other unoptimizable (prepack might help, but it's far from being usable) stuff
- localvoid 8y ago> 1. benchmarks have zero information value Statements without any proof is more valuable than "benchmarks with zero information value"? > what I mean is that compiled templates are usually much faster than doing vdom diffing If they are usually much faster, why it is so hard to make them perform faster than vdom libraries in this benchmark? Or maybe any other benchmark, please just show me something that I can measure.
- crooked-v 8y agoTemplate strings loses all the actual benefits of JSX, in that you can have your editor parse it for validity and type hinting in the same way as if it was all createClass class (but more convenient).
- grrowl 8y agoYou should check out https://github.com/choojs/choo https://github.com/choojs/choo (similar framework in 4kb) and other packages in its ecosystem — https://github.com/choojs/nanohtml https://github.com/choojs/nanohtml (template strings to HTML elements)