var multiStr = "This is the first line" +
"This is the second line" +
"This is more...";
var multiStr = "This is the first line \
This is the second line \
This is more...";
David asked me if I'd be up for a guest post picking out some of my favorite Pens from CodePen. A daunting task! There are so many! I managed to pick a few though that have blown me away over the past few months. If you...
This is the hardest thing I've ever had to write, much less admit to myself. I've written resignation letters from jobs I've loved, I've ended relationships, I've failed at a host of tasks, and let myself down in my life. All of those feelings were very...
"Enabling" you ask? Yes. We all know how to disable the submit upon form submission and the reasons for doing so, but what about re-enabling the submit button after an allotted amount of time. After all, what if the user presses the "stop"...
Whenever I go to Google Analytics I notice a slight flicker in the dropdown list area. I see a button appear for the shortest amount of time and the poof! Gone. What that tells me is that Google is making their site function...
It should be noted the backslash multiline string notation is not part of any ECMAScript standards and can break various minifiers. Otherwise, it’s definitely good to know!
I think this is quite controversial. Other than issue with minifiers, ‘backslashes’ can cause error if there is any white space after it. I often write multiline string as arrays and join, this way IMO is quite readable.
var multiStr = [
"This is the first line",
"This is the second line",
"This is more..."
You can also see the intent here wether it’s about construct a real multiline string (with join(“\n”)) or just try to avoid writing a long string (with join(“”)).
* @tungd : +1
* Moreover, you can't indent your code or it will add the whitespaces to the string.
"my string \
is long" === "my string is long"; // and not "my string is long"
See also this performance test from different possibilities; the \ variant is the fastest.
I forgot about this implementation till this morning while I was working on some jQuery forms. Funny I came across this now.
While I understand the concern for minifiers, we don’t write JS for minifiers, we write JS for JS interpreters. JS minifiers need to improve. If the minifier you use doesn’t support this basic pattern, however, feel free to work around it.
When I first found out that you could escape newlines, I thought it was a pretty neat way to split a single line of text over several lines. It’s advantages are that it’s faster than concatenation and more readable than having the text spanning one long line that you have to scroll through.
However, it’s slower, less readable and less maintainable than having the text on one line and just turning on word wrap in your IDE. It’s also error prone, for reasons explained above.
You can just use the first one, minifiers (at least uglify-js) will change the
var a = "foo" + "bar";into
var a = "foobar";anyway.
What do you think? Could you please enlighten me?
@David: i don’t think there’s much case for “improving” minifiers to support the escaped line feed. The structure itself is non-standard, some browsers don’t support it, so minifiers that adhere to the standards are right to reject that method. Besides, your own point defeats itself: it we write JS for JS interpreters, the implication is to write JS for the broadest compatibility possible. Escaped line feeds reduce that compatibility. And minifiers are increasingly essential tools to reduce bandwidth and execution time, so we SHOULD write JS with minifiers as part of the plan.
Am I missing something? It looks like string literal line continuations _are_ in the spec:
Maybe it’s relatively new but that’s from 2011…?
Ah, I read that more closely and now see that the backslash is only valid if it’s part of something else–not by itself like this post describes. My bad.
Michael Haren: The backslash *isn’t* “by itself”; it’s the character right before a newline. However, the spec does specify (ha!) that the newline is *not* a valid character for escape purposes. The only valid escape characters after a backslash are listed explicitly: ‘ ” \ b f n r t v
Excellent, your blog’s always a lifesaver, thanks David!
But! There’s something new coming!
Your two examples produce different results. I think many people will be surprised by the amount of whitespace in your multiline example.
But that’s not a multiline string! That is a multiline string literal representing a single-line string.
If you want to produce a multiline string (a variable in memory that, upon inspection during execution, contains more than one line of text), you don’t need the trailing backslash but the classic backslash + new line modifier.
The trailing backslash allows us to introduce line breaks in a string literal, mostly for clarity in the source code, without inserting them in the actual string represented by the literal.
This is way outdated. Multiline string literal is accomplished with back tick.