Better paths, ie. /post/:id rather than view-post?id=:id

<rendermap {view} {arrayOfVariableSets}> renders the view for every entry in the arrayOfVariableSets, providing the entry as variables (it must be an object of varialbes).

The <render {file} {variables}> basically mimicks render(file, variables). It renders a sub-view.

This probably depends on #5.

/post/view.js, /post/edit.js, /index.htm

Ie. <printifelse isFriday "Yes, it is friday" "Nope">

It should be legal to have frontend JavaScript files that Arent created as dynamic renders. How to do this?

One solution is a folder with public/ files which should probably also contain static HTML files. I don't like that.

Alternatively backend js files should be differentiated by their name somehow, so the server knows to not just serve it.... I like this. But how? Naming konvention?

An example with some actual code-behind: a blog that runs on the file system.

Use some open source editor for editing, save Markdown as flatfiles. Dynamically render the views from flat files.

Maybe the name is bad?

<printifelse {cond} {printIfTrue} {printIfFalse}>

(At the time of writing npm start {dir} runs it for a dir, if you are currently in the jikes dir -- but it should be possible to run from anywhere, preferably with just jikes)

It must be possible to render within a set template.

There are quite a few design decisions to be made for this, and the syntax/placement has not been planned yet.

It should be possible to handle a call and then redirect to a different page.

No decisions have been made about how to do this, yet.

<renderif {cond} {view} {variables}>

If a page or view is updated/deleted/added while the server is running this should be håndled correctly. In theory it should be possible to start the server and then add the files.