Do I need Node? (and if I already have Node, is this for me?)

[fcapolini]

Two versions of the same question, from opposite directions. Both come up, so
here are both answers.

---

"I write HTML and CSS. Do I have to learn Node?"

To write a Markout page: no. A page is an .html file. <:define> is a
tag, ${…} sits in the markup where the value goes, and the whole language
surface a full app uses is three tags and eight attribute forms. There is no
package.json, no bundler config, no import graph, and nothing to configure
before the file means something.

To install a kit, preview a site and build it: no, as of now either. When
this thread was opened the answer was "yes, today", and the gap is closed. The
VS Code extension
bundles the compiler and the server. Install it, open a folder of HTML files,
and the Markout view in the activity bar gives you three things:

• Kits, by checkbox. Tick one and it is fetched and pinned. No npm: a kit
  is .htm and CSS, fetched over HTTPS and checked against the checksum the
  registry published. It lands in .markout/kits/, which is one more rung on
  the walk the compiler already does — so a terminal, a teammate's checkout
  and CI all read the same tree, and a build driven from the sidebar is
  reproducible by hand.
• Preview serves the pages, reloading as you save. It runs on the copy of
  Node your editor is already running, so nothing looks for node on a PATH
  and nothing has to be there.
• Build writes the finished site to dist/.

No terminal appears anywhere in that, and neither does npm.

Where Node is still required, and why it is a boundary rather than a gap.
Markout has three ways to deliver a
page,
and the sidebar does the third:

	without Node	with Node
Built — the browser renders	yes, both buttons	markout build
Prerendered — rendered once, at build	no	markout prerender
Served — rendered per request	no	markout <docroot>, or the middleware

The other two are a render, and a render is Node executing your page. A
button offering either would be offering something its user cannot deploy. The
loss that is real is content in the HTML for a crawler that will not run
JavaScript; markout prerender is the answer to that, and it wants Node on
the machine that runs the build — a CI job will do, and it does not have to be
yours. markout restore fills in a clone's kits, which is the one command the
arrangement ever needs from a terminal, on any machine that has one.

The reasoning is written up in Working without
Node,
including the two designs that lost: npm i -g behind a checkbox builds the
no-npm experience on npm, and a store the extension owns is one the CLI cannot
read — diagnostics green on a page that will not build, discovered at deploy
rather than while typing.

What you still can't do is take a .html file with <:define> in it, open it
from disk, and have a browser render it. There is a compile step; what changed
is that it is a button rather than a toolchain. That is still a real
difference from a <script src> tag, and worth being straight about.

---

"I already run Node. Is this anti-Node, or anti-framework?"

Neither, and the repo is the evidence: four npm packages, TypeScript
throughout, a compiler and an isomorphic runtime.

• @markout-lang/core — compiler and runtime
• @markout-lang/cli — dev server, build, prerender, and add/restore
  for installing kits without npm
• @markout-lang/express — Markout as Express middleware: render markout
  pages from an application that already has a server
• markout-vscode — a Volar language server running the actual compiler,
  with the compiler and the server bundled

That third one is the direct answer. Markout is not asking you to replace your
server. Mount the middleware in the Express app you already have, keep your
routes, your auth, your database layer, and let Markout render the pages.
:server- marks values that run only on the request, and kits are ordinary npm
packages resolved through node_modules the way anything else is.

If you have npm, keep using it: npm i @markout-lang/bootstrap-kit is still
the way in, and the checkboxes are for the people who have no npm to type it
into. A kit installed either way resolves through the same compiler walk, so
the two paths do not produce different projects — a kit npm installed even
shows in the sidebar, with its checkbox locked on, because your package.json
owns that one.

What Markout replaces is the client framework layer — the part where you
add a bundler, a component compiler and a virtual DOM in order to put a value
in a <span>. Your server stays your server.

Worth naming the trade honestly: you give up the ecosystem. No component
libraries beyond two kits, no router, no state-management options, no answers
on Stack Overflow. If your app needs three npm packages that assume React, this
is not the year to switch.

---

The one-line version

Node is how Markout is prerendered and served; it is not something a page
author has to hold in their head, it is not something a deployed static build
needs at all, and as of the current extension it is not something you need
installed to install a kit, preview a site or build one. If you have Node,
Markout fits inside it. If you don't, the sidebar is the whole of it — and if
you're in that group, what would help most now is telling this thread whether
it works on your machine.