Comments (10)
I've removed the =""
from 0.29.15.
from dom-expressions.
We use innerHTML to generate template elements and sometimes it corrects bad HTML my previous mechanism was to string equal the template vs the result in the innerHTML in dev mode. The browser adds the =""
so I had done that to match. Now I just count the number of tags which is less precise but means that probably doesn't matter to do anymore.
I've always optimized for runtime speed over size, even if negligible. I wonder how much we get back from gzip anyway which should be able to reduce duplication in the template strings pretty handedly. While calling helpers definitely can be reduced more by the minifier I think it would depend a lot on the type of templates you are using.
from dom-expressions.
Thanks Ryan for your answers! :)
The browser adds the ="" so I had done that to match.
Hmm, when I set empty string attribute on the element using pure browser API, it does not add =""
. Did I miss some something?
I've always optimized for runtime speed over size, even if negligible. I wonder how much we get back from gzip anyway which should be able to reduce duplication in the template strings pretty handedly. While calling helpers definitely can be reduced more by the minifier I think it would depend a lot on the type of templates you are using.
I think in bigger apps, with a lot of templates this make a huge difference in delivery. Do you have an access to some mature Solid app, or some OSS project? We could do some benchmarking to validate :)
from dom-expressions.
Hmm, when I set empty string attribute on the element using pure browser API, it does not add ="". Did I miss some something?
Yes try setting the boolean attribute in an innerHTML
and then look what is generated. Like create template with just the boolean property naked. The HTML it generates will have the =""
or at least it did in every browser I checked about 2 years ago.
Yeah I don't have anything of that size to make a comparisn. But I do know that cloning is faster than separately setting from microbenchmarks.
from dom-expressions.
That's correct. The inner html as text will contain the =""
however the nodes will not have it.
Setting innerHTML as '<div empty string=""></div>'
is exactly the same as '<div empty="" string=""></div>'
I think this could save some size without any side effect. It's still a valid HTML to pass just the attribute without assignment so browsers will interpret it anyway as =""
. I guess it's like const test = undefined
vs const test
. Implicit value assignment.
But I do know that cloning is faster than separately setting from microbenchmarks.
That's true. Im just wondering about the impact the duplicated templates will have on the bundled size. I know that is some apps the templates can be like 80% of the size with very complex structure. It might be the case that the cost of setting attributes can be justified in order to trim the bundle by eg. 50%.
There is also one more option instead of using setAttribute we could interpolate the template with attributes to create the final template. I think that would lead to template compilation where structure is shared and all static data is precompiled- not sure what do you think about that.
from dom-expressions.
An example of how we could use template literals for that:
function template(strings, ...keys) {
return (function(...values) {
let dict = values[values.length - 1] || {};
let result = [strings[0]];
keys.forEach(function(key, i) {
let value = Number.isInteger(key) ? values[key] : dict[key];
result.push(value, strings[i + 1]);
});
return result.join('');
});
}
const genericTemplate = template`<button ${0}><div>${1}</div><span></span></button>`
const html = genericTemplate('my-attr="value"', 'Hello there!')
from dom-expressions.
Yeah for the =""
as I was saying it was mostly because I needed the string comparison to be equal. Now that I don't that's probably an easy reduction. So I see no issue with us removing that.
The template thing is trickier. I looked at stuff like bytecodes etc doing my own encoding and I wasn't happy with the performance. And mostly that I needed to bring in the code to do it which was larger than the gains I was shaving from the template. Strings really have the benefit of being easily Gzippable. And I felt all I was doing was implementing my own compression algorithm.
I think there are some heuristics that make sense. Like if templates are sufficiently small like a single element we probably could look at using document.createElement and attribute helpers assuming that those helpers would be there anyway and wouldn't add more code size. Right now template sharing would only be applicable within the same file. And I don't see it applying to partials but whole sections. Like if the initial example here is in a div instead of fragment no gain as it would be in a single template. But it also seems complicated for a scenario that I'm not sure how often you'd hit or would get reasonably handled by GZip. I'm not saying I can't picture this scenario but I suspect the wins aren't clear cut.
from dom-expressions.
Awesome! Thank you Ryan for tackling this so quickly! 🎉
The template thing is trickier. I looked at stuff like bytecodes etc doing my own encoding and I wasn't happy with the performance. And mostly that I needed to bring in the code to do it which was larger than the gains I was shaving from the template. Strings really have the benefit of being easily Gzippable. And I felt all I was doing was implementing my own compression algorithm.
Yes, I know what you are talking about :/ Ember.js (glimmer) is doing the template compilation to bytecode. Although it trimmed down the bundle size in bigger apps it increased the runtime drastically. That's why I suggested the template literals as they seams like a good compromise between compilation and runtime performance.
Let me do some benchmarks with a few ideas that we have here, and get back with results on small components, a website and small app.
from dom-expressions.
Seems like this issue can be closed
from dom-expressions.
Well I only ever did half of the suggestion and the OP was going to investigate the other half. But I agree this one is stale.
from dom-expressions.
Related Issues (20)
- [html] top level <style> causes TypeError: Cannot read properties of undefined (reading 'firstChild')
- [html] empty html template causes TypeError: Cannot read properties of undefined (reading 'name')
- `o[1] is not a function`
- There is no definition of `media` property in interface `MetaHTMLAttributes`
- Bug in generic types for universal render target? HOT 5
- Type definitions of `classList` are wrong HOT 8
- Treat `inert` as a boolean attribute
- Support combining tag classes and the class property in hyper dom expressions HOT 1
- Don't consider namespace imports to be dynamic expression HOT 3
- Emit var instead of const for generated element references HOT 7
- Add ability not to treat every tag with `-` in name as web component HOT 4
- `this` inside arrow function is incorrect after Solid transform HOT 3
- `<this.Foo />` doesn't work HOT 2
- Supporting iterable collections HOT 4
- Question: Possible to use third-party component libraries with Tagged Template Literals? HOT 6
- Template generation template literal escape problem
- bug: Compilation from JSX style attribute to ternary results in functions getting called twice HOT 1
- JSX attribute types HOT 2
- Option for preserving whitespace within JSXChildren HOT 1
- Fragment loses reactivity when using HDE HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from dom-expressions.