Save some bytes by declaring variable as extra function argument

[okwolf]

Also modified a test to check for a case that another proposed byte reduction change didn't handle.

-3 bytes

[codecov]

Codecov Report

Merging #519 into master will not change coverage.
The diff coverage is 100%.

@@          Coverage Diff          @@
##           master   #519   +/-   ##
=====================================
  Coverage     100%   100%           
=====================================
  Files           1      1           
  Lines         135    135           
  Branches       40     40           
=====================================
  Hits          135    135

Impacted Files	Coverage Δ
src/index.js	100% <100%> (ø)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update a7edf32...2935888. Read the comment docs.

[jorgebucaran]

@okwolf Nice try, but this won't work when the text node is 0.

[okwolf]

@jorgebucaran we're missing a test that should fail with this PR then.

[okwolf]

@jorgebucaran I updated the test for h covering numbers so that all the use cases for the logic I tried to simplify are now covered. I wasn't able to cut the size so I reverted that change, but I left the other for a smaller 3 byte diet.

[jorgebucaran]

Thanks! I feel we are doing that trick of passing fake arguments to functions too much. I'm going to merge this, but I may revert it later, along with the others to increase readability if it only means some bytes.

[jorgebucaran]

@okwolf Can you change the commit message (and PR title) to something less mischievous? 🙏

[okwolf]

@jorgebucaran oh, I was actually mostly joking with this PR to begin with. I changed the title, but I'd rather just make a new one for different commit messages/branch name.

I'm not super attached to the only actual byte shrinking change left, but I do want to get the gap in test coverage for h patched.

[infinnie]

What about writing a helper function for "function" != typeof x or referencing the document in a local variable?

[jorgebucaran]

@infinnie I tried both approaches and neither yielded fewer bytes actually haha.

[okwolf]

@jorgebucaran I tried both approaches and neither yielded fewer bytes actually haha.

Gzip can be funny sometimes about when it likes duplication and when it doesn't.

[jorgebucaran]

Merging. Thanks @okwolf! 🎉

[leeoniya]

you guys are doing it all wrong. check out the gzthermal tool [1] used here [2].

::runs away and hides:: 🤣

[1] https://encode.ru/threads/1889-gzthermal-pseudo-thermal-view-of-Gzip-Deflate-compression-efficiency
[2] https://blog.usejournal.com/of-svg-minification-and-gzip-21cd26a5d007

[jorgebucaran]

@leeoniya If you are going to come tell people they are wrong but don't have the time to tell them exactly where or how then please don't. Unless you are Kaepora Gaebora.

[leeoniya]

i guess sarcasm doesnt come across well over the interwebs. i will improve my attempts at humor in the future.

anyways, i figured you guys might be interested in gzthermal since you're so OCD about byte size. but it can also lead to some very time-consuming code-golfing.

[infinnie]

Or an IIFE…

[jorgebucaran]

@leeoniya I like your humor, but you always seem to be in a rush when posting around here, aren't you? I think you are extremely smart, but when sharing wisdom, there's always so much more than what you reveal, which is inconvenient for those less enlightened (me). 😉

[leeoniya]

i will also point out, that if you guys compress with closure compiler, you don't need to do these optimizations by hand. here's the pretty-printed hyperapp file compiled via Closure Compiler [1], it already does this:

  function y(a, d, c) {
    if ("string" === typeof a) {
      c = document.createTextNode(a);
    } else {
      c = (d = d || "svg" === a.name) ? document.createElementNS("http://www.w3.org/2000/svg", a.name) : document.createElement(a.name);
      a.props.oncreate && x.push(function() {
        a.props.oncreate(c);
      });
      for (var b = 0; b < a.children.length; b++) {
        c.appendChild(y(a.children[b], d));
      }
      for (var h in a.props) {
        E(c, h, a.props[h]);
      }
    }
    return c;
  }

[1] https://closure-compiler.appspot.com/code/jsca1d643ec6d5e87dac7ed5b01a23f25c/default.js

[jorgebucaran]

@infinnie That would be cool, but actually when you bundle Hyperapp with your app, it is fewer bytes because you are not using the UMD bundle. 😆

[jorgebucaran]

@leeoniya I've heard about the wonders of google closure compiler before, but last time I checked, it seemed too hard to setup. Also last time I looked at domvm I tried to see what you were doing, and you had a build script, which I want to avoid.

Having said that, it would be much nicer if we didn't have to write obfuscated code, so I'll have another look. 🤔

[infinnie]

Maybe you could try a gzip directly after comment and extra space removal?

[leeoniya]

domvm's build script does a lot more stuff. (plus it used to use the Java version of Closure Compiler, which is much faster)

rollup has a ready-made plugin for the the js version of Closure: https://www.npmjs.com/package/rollup-plugin-closure-compiler-js

[jorgebucaran]

@leeoniya I heard that the JS version of the compiler is not as good as the Java one. Do we get the same benefits you said above using the JS version?

[leeoniya]

in my testing, the js version only differed by encoding html entities within strings [1]. it was easy to work around in my build script via a simple regex replace (but i also didn't need to produce source maps for the minified builds since i only generate source maps for the unminified bundles).

[1] google/closure-compiler-js#79

[jorgebucaran]

@leeoniya How did you produce the code you posted here? I tried https://closure-compiler.appspot.com, but it gave all sort of warnings.

[leeoniya]

you can do hyperapp's npm run bundle and paste the non-minified output into there. (leave the commented header)