ES6 in Chromium proposal: Allow template literals

[Demetrios Papadopoulos]

Hi Chromium devs,

If you don't read/review/author JS code in Chromium you can stop reading now.

Proposing to move ES6 template literals to the "allowed features" section of the ES6 style guide.

Style guide section:

https://chromium.googlesource.com/chromium/src/+/master/docs/es6_chromium.md#Template-Literals

Benefit 1: Makes constructing strings easier (shorter and more readable)

Before

let s = 'The time in ' + cityName + ' is ' + time;

After

let s = `The time in ${cityName} is ${time}`;

Benefit 2: Less error prone, less surprising

Before

let a = 1;
let b = 2;

// Oops, probably forgot parentheses, returns 'total is 12' unexpectedly.
let s1 = 'total is ' + a + b;

// Returns 'total is 3'.
let s2 = 'total is ' + (a + b);

After

// Returns 'total is 12', which is less surprising, since no plus sign was used.
let s = `total is ${a}${b}`;  

// Returns 'total is 3'
let s = `total is ${a + b}`;

Compatibility:

Support in related environments  (Chrome, iOS) looks good, even for Chrome on iOS9, see

http://caniuse.com/#feat=template-literals

https://kangax.github.io/compat-table/es6/#test-template_literals

Let me know if there are any concerns about this proposal. If there is enough support, I am planning to move forward with this change later this week.

Thank you,

Demetrios 

[Michael Giuffrida]

Fully in support! Some questions:

1. Does closure type-check expressions in template literals?

2. Does clang-format choke on template literals?

3. Will we allow/encourage multi-line template literals? They look odd because they aren't indented:

  function printFoo(foo) {
    let message = `Hello world!
Foo is: ${foo}.
Have a nice day!`;
    console.log(message);
  }

4. What will be the new JavaScript style guidance for strings? Should we encourage template strings everywhere or only where necessary? (See: Template Literals are Strictly Better Strings

Michael

[Mike Frysinger]

agree, especially considering the JS style guide already says they're allowed

https://chromium.googlesource.com/chromium/src/+/master/styleguide/web/web.md#JavaScript

https://google.github.io/styleguide/jsguide.html#features-strings-template-strings

-mike

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAPUSrA3C%2B%3DxNkZ4DV%3DXLWr43eZToRUAdQokCd%2Bo12LCr9BJ1Dg%40mail.gmail.com.

[Dan Beam]

+adamk@, bmeurer@, tbreisacher@

On Mon, Oct 9, 2017 at 1:37 PM, Mike Frysinger <vap...@chromium.org> wrote:

agree, especially considering the JS style guide already says they're allowed

https://chromium.googlesource.com/chromium/src/+/master/styleguide/web/web.md#JavaScript

https://google.github.io/styleguide/jsguide.html#features-strings-template-strings

You're right and that's great, but Closure compiler (super popular in Google) almost always rewrites this ES6-y syntax to the ES5 equivalent (support for outputting ES6 is a work in progress).  Chrome would ship these without transpiling.  This is a difference.

I was a little concerned that this syntax would make it easier to write XSS-vulnerable code (i.e. `${alert(/XSS/)}`) but it turns out to not really be different.

adamk@ told me that bmeurer@ has made this syntax faster lately, so hopefully there's minimal performance impact (if any).

-- Dan

[dpapad]

On Monday, October 9, 2017 at 12:42:09 PM UTC-7, Michael Giuffrida wrote:

Fully in support! Some questions:

1. Does closure type-check expressions in template literals?

I think so, based on this example (click "advanced" then "compile").

 

2. Does clang-format choke on template literals?

I don't think so. The proposal CL besides updating the style guide, it also deploys a few usages of template strings to ensure that all the involved tools don't blow up. The deployed usages are not exhaustive of all possible cases though, so it is possible that some case could choke clang-format. Having said that, I think that allowing the feature will make it more likely to find and fix such cases if any.

 

3. Will we allow/encourage multi-line template literals? They look odd because they aren't indented:

  function printFoo(foo) {
    let message = `Hello world!
Foo is: ${foo}.
Have a nice day!`;
    console.log(message);
  }

I don't have a strong opinion on this, so leaning towards allowing it. It's also not a very common use case of string concatenation anyway. 

 

4. What will be the new JavaScript style guidance for strings? Should we encourage template strings everywhere or only where necessary? (See: Template Literals are Strictly Better Strings

As a starting point I would suggest the following approach: 

• Require template strings in cases were two or more plus signs would be used otherwise.
  
• Allow both old and new, for cases where a single plus sign would be used.
  

[Dave Schuyler]

I checked the performance of template literals (results here). tl;dr; template literals perform very well; no concerns.

On Monday, October 9, 2017 at 12:30:32 PM UTC-7, dpapad wrote:

[dpapad]

FYI, I am about to land the CL that allows template literals usage. I don't think there are any outstanding concerns in this discussion. Please speak up if that is not the case.

Thanks.