<commit_before><template name="concepts">

<h1 id="concepts">Concepts</h1>

We've written our fair share of single-page JavaScript applications by hand.
Writing an entire application in one language (JavaScript) with one
data format (JSON) is a real joy.  Meteor is everything we wanted
when writing those apps.

{{> whatismeteor }}
{{> structure }}
{{> data_ }}
{{> reactivity }}
{{> livehtmltemplates }}
{{> packages_concept }}
{{> namespacing }}
{{> deploying }}
{{> packages_writing }}
</template>

<template name="whatismeteor">

{{#markdown}}

<h2 id="whatismeteor">What is Meteor?</h2>

Meteor is two things:

* A _library of packages_: pre-written, self-contained modules that
you might need in your app.<br>
There are about a dozen core Meteor
packages that most any app will use (for example [`webapp`](#webapp), which
handles incoming HTTP connections, and `templating`, which lets you
make HTML templates that automatically update live as data changes).
Then there are optional packages like `email`, which lets your app
send emails, or the Meteor Accounts series (`accounts-password`,
`accounts-facebook`, `accounts-ui`, and others) which provide a
full-featured user account system that you can drop right into your
app. In addition to these "core" packages, there are thousands of
community-written packages in [Atmosphere](https://atmospherejs.com/),
one of which might do just what you need.

* A _command-line tool_ called `meteor`.<br>
`meteor` is a build tool analogous to `make`, `rake`, or the non-visual parts of
Visual Studio. It gathers up all of the source files and assets in your
application, carries out any necessary build steps (such as compiling
[CoffeeScript](http://coffeescript.org), minifying CSS, building
[npm](https://npmjs.org/) modules, or generating source maps), fetches the
packages used by your app, and outputs a standalone, ready-to-run application
bundle. In development mode it can do all of this interactively, so that
whenever you change a file you immediately see the changes in your browser. It's
super easy to use out of the box, but it's also extensible: you can add support
for new languages and compilers by adding build plugin packages to your app.

The key idea in the Meteor package system is that _everything should
work identically in the browser and on the server_ (wherever it makes
sense, of course: browsers can't send email and servers can't capture
mouse events). Our whole ecosystem has been built from the ground up
to support this.

{{/markdown}}
</template>

<template name="structure">
{{#markdown}}

<h2 id="structuringyourapp">Structuring your application</h2>

A Meteor application is a mix of JavaScript that runs inside a client web
browser, JavaScript that runs on the Meteor server inside a
[Node.js](http://nodejs.org/) container, and all the supporting HTML fragments,
CSS rules, and static assets.  Meteor automates the packaging and transmission
of these different components.  And, it is quite flexible about how you choose
to structure those components in your file tree.

The only server assets are JavaScript and files in the `private` subdirectory.
Meteor gathers all your JavaScript
files, excluding anything under the `client`, `public`, and `private`
subdirectories, and loads them into a Node.js
server instance inside a fiber.  In Meteor, your server code runs in
a single thread per request, not in the asynchronous callback style
typical of Node.  We find the linear execution model a better fit for
the typical server code in a Meteor application.

Meteor gathers any files under the `private` subdirectory and makes the contents
of these files available to server code via the [`Assets`](#assets) API. The
`private` subdirectory is the place for any files that should be accessible to<commit_msg>Improved formatting for what is meteor<commit_after><template name="concepts">

<h1 id="concepts">Concepts</h1>

We've written our fair share of single-page JavaScript applications by hand.
Writing an entire application in one language (JavaScript) with one
data format (JSON) is a real joy.  Meteor is everything we wanted
when writing those apps.

{{> whatismeteor }}
{{> structure }}
{{> data_ }}
{{> reactivity }}
{{> livehtmltemplates }}
{{> packages_concept }}
{{> namespacing }}
{{> deploying }}
{{> packages_writing }}
</template>

<template name="whatismeteor">

{{#markdown}}

<h2 id="whatismeteor">What is Meteor?</h2>

Meteor is two things:

* A _library of packages_: pre-written, self-contained modules that
  you might need in your app.

  There are about a dozen core Meteor packages that most any app will use. Two
  examples: [`webapp`](#webapp), which handles incoming HTTP connections, and
  `templating`, which lets you make HTML templates that automatically update
  live as data changes. Then there are optional packages like `email`, which
  lets your app send emails, or the Meteor Accounts series (`accounts-password`,
  `accounts-facebook`, `accounts-ui`, and others) which provide a full-featured
  user account system that you can drop right into your app. In addition to
  these "core" packages, there are thousands of community-written packages in
  [Atmosphere](https://atmospherejs.com/), one of which might do just what you
  need.

* A _command-line tool_ called `meteor`.

  `meteor` is a build tool analogous to `make`, `rake`, or the non-visual parts
of Visual Studio. It gathers up all of the source files and assets in your
application, carries out any necessary build steps (such as compiling
[CoffeeScript](http://coffeescript.org), minifying CSS, building
[npm](https://npmjs.org/) modules, or generating source maps), fetches the
packages used by your app, and outputs a standalone, ready-to-run application
bundle. In development mode it can do all of this interactively, so that
whenever you change a file you immediately see the changes in your browser. It's
super easy to use out of the box, but it's also extensible: you can add support
for new languages and compilers by adding build plugin packages to your app.

  The key idea in the Meteor package system is that _everything should work
  identically in the browser and on the server_ (wherever it makes sense, of
  course: browsers can't send email and servers can't capture mouse events). Our
  whole ecosystem has been built from the ground up to support this.

{{/markdown}}
</template>

<template name="structure">
{{#markdown}}

<h2 id="structuringyourapp">Structuring your application</h2>

A Meteor application is a mix of JavaScript that runs inside a client web
browser, JavaScript that runs on the Meteor server inside a
[Node.js](http://nodejs.org/) container, and all the supporting HTML fragments,
CSS rules, and static assets.  Meteor automates the packaging and transmission
of these different components.  And, it is quite flexible about how you choose
to structure those components in your file tree.

The only server assets are JavaScript and files in the `private` subdirectory.
Meteor gathers all your JavaScript
files, excluding anything under the `client`, `public`, and `private`
subdirectories, and loads them into a Node.js
server instance inside a fiber.  In Meteor, your server code runs in
a single thread per request, not in the asynchronous callback style
typical of Node.  We find the linear execution model a better fit for
the typical server code in a Meteor application.

Meteor gathers any files under the `private` subdirectory and makes the contents
of these files available to server code via the [`Assets`](#assets) API. The
`private` subdirectory is the place for any files that should be accessible to
{'fraction_non_alphanumeric': 0.07460732984293193, 'fraction_numerical': 0.0015706806282722514, 'mean_word_length': 4.873174481168332, 'pattern_counts': {'":': 0, '<': 27, '<?xml version=': 0, '>': 45, 'https://': 4, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '1519687', 'n_tokens_mistral': 2060, 'n_tokens_neox': 1955, 'n_words': 1070}