PageRenderTime 34ms CodeModel.GetById 30ms RepoModel.GetById 0ms app.codeStats 0ms

/packages/atom-beautify/node_modules/marko/docs/overview.md

https://gitlab.com/xanium4332/atom-config
Markdown | 231 lines | 180 code | 51 blank | 0 comment | 0 complexity | 119605b723fb3885354ce67cfb464ae7 MD5 | raw file
  1. Overview
  2. =================
  3. Marko is an eBay open source HTML-based templating engine that can be used to render templates on the server (Node.js) or in the web browser. It is [extremely fast](https://github.com/marko-js/templating-benchmarks) and lightweight (~3.75KB gzipped) while also supporting streaming and asynchronous rendering. Developers can extend the HTML grammar with custom tags and custom attributes to introduce new and reusable building blocks. The Marko compiler produces Node.js-compatible JavaScript modules that are [easy to read](https://gist.github.com/patrick-steele-idem/0514b480219d1c9ed8d4#file-template-marko-js), understand and debug. In contrast to other templating engines, Marko avoids [evil global variables](http://archive.oreilly.com/pub/a/javascript/excerpts/javascript-good-parts/awful-parts.html) and global helpers.
  4. Marko was founded on the philosophy that an HTML-based templating language is more natural and intuitive for generating HTML. Because the Marko compiler understands the structure of the HTML document, the directives in template files are less obtrusive and more powerful. Marko also retains the full power and flexibility of JavaScript by allowing JavaScript expressions inside templates.
  5. Marko supports [progressive HTML rendering](http://markojs.com/docs/marko/async-taglib/) by writing directly to an output stream so that HTML can be sent over the wire sooner. Marko automatically flushes around asynchronous parts of the template so that the HTML is delivered in the optimized number of chunks. Because Marko is an asynchronous templating language, additional data can be asynchronously fetched even after rendering has begun. These characteristics make Marko an excellent choice for creating high performance websites.
  6. For building rich UI components with client-side behavior please check out the [marko-widgets](https://github.com/marko-js/marko-widgets) project.
  7. <a href="http://markojs.com/try-online/" target="_blank">Try Marko Online!</a>
  8. # Syntax
  9. Marko supports _both_ a familiar HTML syntax, as well as a more concise indentation-based syntax. Both syntaxes are equally supported. Regardless of which syntax you choose, the compiled code will be exactly the same.
  10. Syntax highlighting is available in the following editors and IDEs:
  11. - Atom: [language-marko](https://atom.io/packages/language-marko)
  12. - Sublime Text: [marko-sublime](https://github.com/merwan7/sublime-marko)
  13. - WebStorm: [marko.tmbundle](https://github.com/marko-js/marko-tmbundle) (See: [Importing TextMate Bundles](https://www.jetbrains.com/phpstorm/help/importing-textmate-bundles.html))
  14. - TextMate: [marko.tmbundle](https://github.com/marko-js/marko-tmbundle)
  15. ## HTML syntax
  16. ```xml
  17. <!DOCTYPE html>
  18. <html lang="en">
  19. <head>
  20. <title>Marko Templating Engine</title>
  21. </head>
  22. <body>
  23. <h1>
  24. Hello ${data.name}!
  25. </h1>
  26. <ul if(data.colors.length)>
  27. <li for(color in data.colors)>
  28. ${color}
  29. </li>
  30. </ul>
  31. <div else>
  32. No colors!
  33. </div>
  34. </body>
  35. </html>
  36. ```
  37. ## Concise syntax
  38. The following concise template is equivalent to the previous template:
  39. ```xml
  40. <!DOCTYPE html>
  41. html lang="en"
  42. head
  43. title - Marko Templating Engine
  44. body
  45. h1 - Hello ${data.name}!
  46. ul if(data.colors.length)
  47. li for(color in data.colors)
  48. ${color}
  49. div else
  50. - No colors!
  51. ```
  52. ## Mixed syntax
  53. You can even mix and match the concise syntax with the HTML syntax within the same document.
  54. The following template is equivalent to the previous templates:
  55. ```xml
  56. <!DOCTYPE html>
  57. html lang="en"
  58. head
  59. title - Marko Templating Engine
  60. body
  61. <h1>
  62. Hello ${data.name}!
  63. </h1>
  64. ul if(data.colors.length)
  65. li for(color in data.colors)
  66. ${color}
  67. div else
  68. - No colors!
  69. ```
  70. # Sample Code
  71. A basic template with text replacement, looping and conditionals is shown below:
  72. _hello-world.marko:_
  73. ```xml
  74. <h2>Hello ${data.name}!</h2>
  75. <ul if(data.colors.length)>
  76. <li style="color: ${color}" for(color in data.colors)>
  77. ${color}
  78. </li>
  79. </ul>
  80. <div else>
  81. No colors!
  82. </div>
  83. ```
  84. The template can then be rendered as shown in the following sample code:
  85. ```javascript
  86. require('marko/node-require').install();
  87. var template = require('./hello-world.marko');
  88. template.render({
  89. name: 'World',
  90. colors: ["red", "green", "blue"]
  91. },
  92. function(err, output) {
  93. console.log(output);
  94. });
  95. ```
  96. The output of running the above program will be the following (formatted for readability):
  97. ```html
  98. <h2>Hello World!</h2>
  99. <ul>
  100. <li style="color: red">red</li>
  101. <li style="color: green">green</li>
  102. <li style="color: blue">blue</li>
  103. </ul>
  104. ```
  105. For comparison, given the following data consisting of an empty array of colors:
  106. ```javascript
  107. {
  108. name: 'World',
  109. colors: []
  110. }
  111. ```
  112. The output would be the following:
  113. ```xml
  114. <h2>Hello World!</h2>
  115. <div>
  116. No colors!
  117. </div>
  118. ```
  119. The streaming API can be used to stream the output to an HTTP response stream or any other writable stream. For example, with Express:
  120. ```javascript
  121. var template = require('./user-profile.marko');
  122. app.get('/profile', function(req, res) {
  123. // Render directly to the writable HTTP output stream:
  124. template.render({
  125. name: 'Frank'
  126. }, res);
  127. });
  128. ```
  129. # Another Templating Language?
  130. Most front-end developers are familiar with, and comfortable with, templating languages such as [Handlebars](https://github.com/wycats/handlebars.js), [Dust](https://github.com/linkedin/dustjs) or [Mustache](http://mustache.github.io/) so why was Marko introduced?
  131. What makes Marko different is that it is an HTML-based templating language that does not rely on a custom language grammar. Any HTML file is a valid Marko template and vice-versa, and the Marko compiler uses an [off-the-shelf HTML parser](https://github.com/fb55/htmlparser2). Because Marko understands the HTML structure of the templates, it can do more powerful things that would not be possible in a text-based templating languages such as Handlerbars, Dust or Mustache. Marko allows developers to _extend the HTML language_ by introducing custom HTML elements and attributes. On top of that, utilizing the HTML structure for applying templating directives makes templates more readable and allows data templates to more closely resemble the final HTML structure.
  132. Let's compare Marko with Handlebars (a text-based templating language):
  133. __Handlebars:__
  134. ```xml
  135. <h2>Hello {{name}}!</h2>
  136. {{#if colors}}
  137. <ul>
  138. {{#each colors}}
  139. <li class="color">
  140. {{this}}
  141. </li>
  142. {{/each}}
  143. </ul>
  144. {{else}}
  145. <div>
  146. No colors!
  147. </div>
  148. {{/if}}
  149. ```
  150. __Marko:__
  151. ```xml
  152. <h2>Hello ${data.name}!</h2>
  153. <ul if(data.colors.length)>
  154. <li class="color" for(color in data.colors)>
  155. ${color}
  156. </li>
  157. </ul>
  158. <div else>
  159. No colors!
  160. </div>
  161. ```
  162. A few things to note for the Marko template:
  163. * Less lines of code
  164. * Less lines are "touched" to make the template dynamic
  165. * Only opening tags are modified for conditionals and looping
  166. Beyond Marko being an HTML-based templating language, it was also designed with extreme performance and extensibility in mind. The Marko compiler gives developers full control over how templates are compiled to JavaScript and the runtime was designed to be as efficient as possible. Marko fully embraces the JavaScript language for better performance and flexibility (e.g. favoring JavaScript expressions over a custom expression language).
  167. Finally, another distinguishing feature of Marko is that it supports _asynchronous template rendering_. This powerful feature allows portions of the template to be rendered asynchronously. Instead of waiting for all data to come back from remote services before beginning to render the template, you can now immediately start rendering the template and the portions of the template that depend on asynchronous data will render as soon as the asynchronous data becomes available. The Marko rendering engine ensures that the final HTML will be streamed out in the correct order.
  168. # Design Philosophy
  169. * __Readable:__ Templates should be as close to the output HTML as possible to keep templates readable. Cryptic syntax and symbols should be avoided.
  170. * __Simple:__ The number of new concepts should be minimized and complexity should be avoided.
  171. * __Extensible:__ The template engine should be easily extensible at both compile-time and runtime.
  172. * __High Performance:__ Runtime and compiled output should be optimized for low CPU and memory usage and have a small footprint. All expressions should be native JavaScript to avoid runtime interpretation.
  173. * __Not Restrictive:__ Whether or not to go less logic or more logic in templates is up to the developer.
  174. * __Asynchronous and Streaming Output:__ It should be possible to render HTML out-of-order, but the output HTML should be streamed out in the correct order. This minimizes idle time and reduces the time to first byte.
  175. * __Intuitive:__ The templating engine should introduce as few surprises as possible.
  176. * __Browser and Server Compatibility:__ Templates should compile down to JavaScript that can be executed on both the server and the client.
  177. * __Debuggable:__ Compiled JavaScript should be debuggable and readable.
  178. * __Compile-Time Checks:__ Syntax, custom tags and custom attributes should be validated at compile-time.
  179. * __Tools Support:__ Tools should be enabled to offer auto-completion and validation for improved productivity and safety.
  180. * __Modular:__ Runtime and compiled templates should be based on CommonJS modules for improved dependency management. Template dependencies (such as custom tags) should be resolved based on a template's file system path instead of relying on a global registry.