O'Reilly

Multi-Line JavaScript Strings

By on  

The JavaScript language performs automatic semicolon insertion at the end lines, so creating multiline strings usually ends up looking something like this:

var multiStr = "This is the first line" + 
	"This is the second line" + 
	"This is more...";

String upon string of concatenated JavaScript mess...ugly, slow, and ...ugly.  Many novice JavaScript developers don't know that there's a better way to create multiline strings:

var multiStr = "This is the first line \
	This is the second line \
	This is more...";

Adding a backslash at the end of each line tells the JavaScript engine that the string will continue to the next line, thus avoiding the automatic semicolon insertion annoyance. Note that the second string includes line breaks within the string itself.  Just another nice tip to add to your JavaScript arsenal!

Track.js Error Reporting

Upcoming Events

Recent Features

  • Create a Sheen Logo Effect with CSS

    I was inspired when I first saw Addy Osmani's original ShineTime blog post.  The hover sheen effect is simple but awesome.  When I started my blog redesign, I really wanted to use a sheen effect with my logo.  Using two HTML elements and...

  • Vibration API

    Many of the new APIs provided to us by browser vendors are more targeted toward the mobile user than the desktop user.  One of those simple APIs the Vibration API.  The Vibration API allows developers to direct the device, using JavaScript, to vibrate in...

Incredible Demos

  • Degradable SELECT onChange

    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...

  • jQuery Wookmark

    The first thing that hits you when you visit Pinterest is "Whoa, the columns are the same width and the photos are cut to fit just the way they should."  Basic web users probably think nothing of it but as a developer, I can appreciate the...

Discussion

  1. Matt Titchener

    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!

  2. 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..."
    ].join("\n");

    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(“”)).

  3. /**
    * @tungd : +1
    *
    * Moreover, you can't indent your code or it will add the whitespaces to the string.
    *
    * e.g:
    **/

    "my string \
    is long" === "my string is long"; // and not "my string is long"

  4. See also this performance test from different possibilities; the \ variant is the fastest.

  5. I forgot about this implementation till this morning while I was working on some jQuery forms. Funny I came across this now.

  6. 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.

  7. Jamie

    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.

    The most common reason for including large, unbroken chunks of text in a JavaScript file is for the purposes of HTML injection, in which case I would personally include the text in a separate tag, which I then retrieve with innerText and store in a variable. That way, I can format it as HTML, but it won’t get shown on the page, nor get interpreted as JavaScript. Yes, it’s slower, but it’s much more readable and maintainable.

  8. Arian Stolwijk

    You can just use the first one, minifiers (at least uglify-js) will change the var a = "foo" + "bar"; into var a = "foobar"; anyway.

  9. In Google javascript guide, they advise “”+ instead of \ because . «The whitespace at the beginning of each line can’t be safely stripped at compile time; whitespace after the slash will result in tricky errors; and while most script engines support this, it is not part of ECMAScript.»

    http://google-styleguide.googlecode.com/svn/trunk/javascriptguide.xml?showone=Multiline_string_literals#Multiline_string_literals

    What do you think? Could you please enlighten me?

    Thank you.

  10. Joe T.

    @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.

    Personally, i find it no easier to read an escaped line feed than “a “+ “b “+ … There’s always something interrupting the end of the line. Sure, concatenating strings suffers a performance hit, but at the point it becomes significant, one should ask why such long strings are being statically coded into Javascript.

  11. Am I missing something? It looks like string literal line continuations _are_ in the spec:

    http://www.ecma-international.org/ecma-262/5.1/#sec-7.8.4

    Maybe it’s relatively new but that’s from 2011…?

  12. 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.

  13. This is code will help to generate html code in javascript:….

  14. 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

  15. Jack Sparow

    Excellent, your blog’s always a lifesaver, thanks David!

Wrap your code in <pre class="{language}"></pre> tags, link to a GitHub gist, JSFiddle fiddle, or CodePen pen to embed!

Recently on David Walsh Blog

  • OâReilly Velocity Conference â New York

    My favorite front-end conference has always been O'Reilly's Velocity Conference because the conference series has focused on one of the most undervalued parts of client side coding:  speed.  So often we're so excited that our JavaScript works that we forget that speed, efficiency, and performance are just as important. The next Velocity...

  • Free Download: Font Bundle Featuring 17 Incredible Typefaces

    The only thing we love more than a good font, is a good free font. So we’ve combed the Web for some of our favorite free fonts, and gathered them here in a single download. You’ll find a variety of useful typefaces, from highly geometric designs...

  • OâReilly Velocity Conference â Amsterdam

    My favorite front-end conference has always been O'Reilly's Velocity Conference because the conference series has focused on one of the most undervalued parts of client side coding:  speed.  So often we're so excited that our JavaScript works that we forget that speed, efficiency, and performance are just as important. The next Velocity...

  • CanIUse Command Line

    Every front-end developer should be well acquainted with CanIUse, the website that lets you view browser support for browser features.  When people criticize my blog posts for not detailing browser support for features within the post, I tell them to check CanIUse:  always up to date, unlike...

  • Generating Alternative Stylesheets for Browsers Without @media

    If your CSS code is built with a mobile-first approach, it probably contains all the rules that make up the "desktop" view inside @media statements. That's great, but browsers that don't support media queries (IE 8 and below) will simply ignore them, ending up getting the...