Collapse hydrate logic

[Rich-Harris]

There's no need to have a separate h() method (for adding attributes to DOM nodes etc) if we're not compiling in hydratable mode, since the only time that method is called is during c(). Instead, we can just merge those two methods into one, shaving off previous bytes.

This PR also gets rid of the ES5-style methods, in favour of ES6 shorthand.

[codecov-io]

Codecov Report

Merging #1388 into master will decrease coverage by 0.04%.
The diff coverage is 78.57%.

@@            Coverage Diff             @@
##           master    #1388      +/-   ##
==========================================
- Coverage   91.24%   91.19%   -0.05%     
==========================================
  Files         122      122              
  Lines        4454     4465      +11     
  Branches     1367     1377      +10     
==========================================
+ Hits         4064     4072       +8     
  Misses        156      156              
- Partials      234      237       +3

Impacted Files	Coverage Δ
src/compile/dom/Block.ts	93.39% <78.57%> (-2.4%)	⬇️

---

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 1130556...da2a45a. Read the comment docs.

[Conduitry]

🎉 @ switching to ES6 shorthand, but is there something to be said for keeping the non-single-letter names of the methods around somewhere? In comments?

[Rich-Harris]

I did wonder about that. A possible alternative would be to use full names in dev mode, and only use the single-character ones in prod? Would involve some hoop-jumping

[Conduitry]

What if we only use the ES6 shorthand in prod mode, and keep the named ES5 functions in dev? That sounds like it would involve fewer hoops, as we'd still always be calling the methods with the single-letter versions.

Is there some reason in particular you don't want to just have comments after each ES6 method shorthand, saying what its conceptual full name is?

[Rich-Harris]

It just upsets the neat freak in me, which probably isn't a great reason. Keeping the named ES5 functions in dev mode is a good solution, yeah. Though I'm thinking ahead to if we start using classes for blocks (see #1260 (comment)) — with classes you can't have a function name that's different from the method name