{
  "id": 8328417,
  "title": "FlowScript 0.1: A semantic language for describing applications before implementation",
  "url": "https://urgent.news/2026/09/18/flowscript-0-1-a-semantic-language-for-describing-applications-before",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-09-18T22:54:48.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/erland_kjensli_e3e4076039/flowscript-01-a-semantic-language-for-describing-applications-before-implementation-3pn3"
  },
  "original_language": "en",
  "account": "A researcher is investigating the possibility of creating a compact, human-readable notation to describe an application's semantic model before implementation. This experiment is now publicly available as FlowScript 0.1, a working draft found on GitHub.\n\nFlowScript aims to represent an application's structure, hierarchy, logical destinations, UI structure, navigation, user interactions, actions, side effects, conditions, state, context, dataflow, validation, asynchronous behavior, errors, feedback, reusable structures, and responsive presentation. By describing the semantic model of an application, the implementation becomes downstream, allowing for more flexibility in implementation choices.\n\nA key distinction in FlowScript is the separation of hierarchy and navigation. While hierarchy answers \"what contains what,\" navigation answers \"what can lead to what.\" Additionally, FlowScript treats structure, navigation, and state as separate graphs, which helps avoid ambiguity in model interpretation.\n\nAnother important distinction is between the logical application model and its presentation on a device or viewport. For example, the same logical destination might appear differently depending on the layout. FlowScript allows semantic identity to remain consistent regardless of presentation changes.\n\nFlowScript also distinguishes between user actions and system actions. User interactions with controls lead to system actions, which then change the navigation context. This separation helps make behavior easier to reason about and potentially reuse. Similarly, FlowScript separates conditions from state, treating conditions as predicates and states as object or process statuses.\n\nThe syntax of FlowScript is deliberately lightweight, using a format like \"keyword:value\" with indentation expressing semantic nesting. While the syntax is simple, the underlying semantics are stricter, allowing for validation of references, nesting, targets, conditions, state declarations, and other relationships.\n\nFlowScript is not intended to replace programming languages or other design tools. Instead, it operates at a different level, describing the semantic structure and behavior of an application while leaving implementation technologies to determine how that model becomes software. The long-term vision is to have a single source that supports multiple projections, such as hierarchy diagrams, navigation graphs, state diagrams, and more.",
  "summary": "I've been exploring a question that sits somewhere between software architecture, DSL design, application modeling, UX structure, and programming-language design: Can we describe the semantic model of an application in a compact, human-readable notation before implementation begins? That experiment is now public as FlowScript 0.1 . GitHub repository:…",
  "key_points": [],
  "editors_take": null,
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}