[{"data":1,"prerenderedAt":100},["ShallowReactive",2],{"home-projects":3},[4,27,47,65,77],{"slug":5,"title":6,"description":7,"body":8,"category":9,"sources":10,"name":17,"order":18,"status":19,"stack":20,"website":13,"repository":24,"featured":25,"path":26},"nuxt-charts","Nuxt Charts — a project by Dennis Adriaansen","Charts, reusable blocks and dashboard templates for Vue and Nuxt developers.","\n## Why I built Nuxt Charts\n\nI’m Dennis Adriaansen, known as Dennis Adriaans in the Nuxt community. Nuxt Charts started with a practical need: an error dashboard I was building needed clear, attractive charts that felt at home in Vue.\n\nI wanted a shorter path from application data to a useful interface. That became the focus of Nuxt Charts: familiar components, careful visual defaults and room to customize.\n\n## A library, then the rest of the screen\n\nThe work includes chart components, reusable blocks and dashboard templates. Charts cover trends, comparisons, proportions and flows; blocks and templates put them into the context of a working interface.\n\nThe underlying visualization work uses Unovis. The Vue package, [vue-chrts](https:\u002F\u002Fgithub.com\u002Fdennisadriaans\u002Fvue-chrts), is open source. Nuxt Charts adds a Nuxt-focused entry point, examples and a broader collection of interface work.\n\n## What matters to me\n\n- Make the data easy to read before adding decoration.\n- Use defaults that fit a real application.\n- Keep types and component APIs understandable.\n- Let developers adapt a chart to their product’s visual language.\n\nFor the current chart catalog, setup instructions and commercial template details, visit [Nuxt Charts](https:\u002F\u002Fnuxtcharts.com). For the starting point, read [why I built Nuxt Charts](\u002Fblog\u002Fwhy-i-built-nuxt-charts).\n","Data visualization",[11,14],{"label":12,"url":13},"Nuxt Charts — current library, blocks and templates","https:\u002F\u002Fnuxtcharts.com",{"label":15,"url":16},"My original DEV article: Why I’m Building Nuxt Charts","https:\u002F\u002Fdev.to\u002Fdennisadriaans\u002Fwhy-im-building-nuxt-charts-4dlj","Nuxt Charts",1,"Active",[21,22,23],"Vue","Nuxt","Unovis","https:\u002F\u002Fgithub.com\u002Fdennisadriaans\u002Fvue-chrts",false,"\u002Fprojects\u002Fnuxt-charts",{"slug":28,"title":29,"description":30,"body":31,"category":32,"sources":33,"name":28,"order":40,"status":41,"stack":42,"website":36,"featured":25,"path":46},"cloudconfig","cloudconfig — a project by Dennis Adriaansen","A TypeScript configuration layer for models, APIs, access rules and backend deployment on Cloudflare.","\n## A backend for frontend developers\n\ncloudconfig is my backend infrastructure project. Its starting point is a familiar frustration: building an interface is straightforward, but the database, validation, routes, access rules and deployment need to agree with each other.\n\nThe aim is to express those shared decisions in a TypeScript backend definition and derive the repetitive parts from it.\n\n## One definition, several connected pieces\n\nThe current project describes model definitions, database migrations, validated REST routes, authentication, access rules and a typed client. The same model definition gives the frontend and backend a common contract.\n\nNuxt applications use the Nuxt integration. A standalone API is also part of the project. The deployment target today is Cloudflare.\n\n## Where the boundaries belong\n\nA typed client helps a developer call an API correctly. Access rules still belong on the server. A generated endpoint needs to enforce the application’s rules whether the request comes from a dashboard, a script or an agent.\n\nThat distinction is especially useful when a natural-language interface proposes an action. The proposal is an input to the application, and the backend determines which operations are permitted.\n\n## Current status\n\ncloudconfig is in beta, and its API can change before a stable release. Cloudflare is the current platform; broader cloud portability is a direction for the project, not a promise that other platforms already have full support.\n\nRead [the project documentation](https:\u002F\u002Fcloudconfig.dev\u002Fdocs) for current setup and deployment details. My article on [a backend for frontend developers](\u002Fblog\u002Fcloudconfig-a-backend-for-frontend-developers) connects that work to a public post about the idea.\n","Backend infrastructure",[34,37],{"label":35,"url":36},"cloudconfig documentation","https:\u002F\u002Fcloudconfig.dev\u002Fdocs",{"label":38,"url":39},"My public post about a simple backend layer on Cloudflare","https:\u002F\u002Fx.com\u002FDennisAdriaans\u002Fstatus\u002F2106081787013193818",2,"Beta",[43,44,45],"TypeScript","Cloudflare","D1","\u002Fprojects\u002Fcloudconfig",{"slug":48,"title":49,"description":50,"body":51,"category":52,"sources":53,"name":57,"order":58,"status":59,"stack":60,"website":63,"repository":56,"featured":25,"path":64},"open-run","Open Run — a project by Dennis Adriaansen","Schedule coding agents on your own machine and review what each run changes.","\n## Give repeatable work a place to run\n\nOpen Run schedules coding-agent CLIs on a local machine. A project is a Git repository, an instruction is a prompt, and a trigger decides when the work starts.\n\nIt uses the agent CLIs a developer already has configured. Open Run itself does not require model API keys. The selected agent can still send prompts and code to its provider according to that agent’s settings.\n\n## A run should leave something you can review\n\nThe project includes schedules, one-off runs and webhook-triggered work, along with conversation history and Git diff review. Repeated work gets an execution directory tied to a recorded base commit.\n\nA useful automation produces an understandable change. The review step connects the instruction, the result, the checks and the diff.\n\n## Examples of the kind of work it supports\n\nA scheduled prompt might ask an agent to inspect a flaky test, explain a dependency change or prepare a small maintenance patch. These are example workflows, not promises that the tool will resolve every task unattended.\n\nThe machine and worker must be running for local schedules to fire. Agent availability and provider limits still apply.\n\n## Explore the implementation\n\nThe [Open Run repository](https:\u002F\u002Fgithub.com\u002Fdennisadriaans\u002Fopenrun) documents the CLI, runtimes, triggers and security model. It is the best place to check current behavior before configuring an automation.\n\nOpen Run sits beside [cloudconfig](\u002Fprojects\u002Fcloudconfig) and [Nuxt Agentic](\u002Fprojects\u002Fnuxt-agentic) in my work on making agent-driven applications and workflows easier to understand.\n","Coding agents",[54],{"label":55,"url":56},"Open Run README and current setup instructions","https:\u002F\u002Fgithub.com\u002Fdennisadriaans\u002Fopenrun","Open Run",3,"Open source",[43,61,62],"Node.js","Local agents","https:\u002F\u002Fgetopenrun.dev","\u002Fprojects\u002Fopen-run",{"slug":66,"title":67,"description":68,"body":69,"category":70,"sources":71,"name":72,"order":73,"status":41,"stack":74,"featured":25,"path":76},"nuxt-agentic","Nuxt Agentic — a project by Dennis Adriaansen","A Nuxt application foundation for agents, connected tools, automations and internal workspaces.","\n## The application layer for agents\n\nNuxt Agentic is my Nuxt-based application project for teams building assistants, internal tools and automated workflows.\n\nThe starting point is a reusable source project: an interface, module structure and common services that a development team can adapt to its own application.\n\n## The parts of the application\n\nThe current project brings together agent definitions, provider and model selection, connected tools, scoped permissions, automations and run history. A Nuxt UI workspace connects those features.\n\ncloudconfig provides the backend models, generated APIs and typed client. That split keeps infrastructure work in the backend layer and product interactions in the application.\n\n## Review is part of the interface\n\nAn agent’s proposed action should be understandable before it changes business data. The application uses a plan, review and execution flow, with validation and access rules enforced on the server.\n\nThis is the kind of interaction I want to make reusable: a clear proposal, a visible consequence and a backend that can reject an unauthorized operation.\n\n## A project in development\n\nNuxt Agentic is still being developed. This page describes the project’s direction and current source structure; it is not a guarantee of a finished integration for every provider or a release date.\n\nFor the backend layer, see [cloudconfig](\u002Fprojects\u002Fcloudconfig). For a local coding-agent scheduler, see [Open Run](\u002Fprojects\u002Fopen-run).\n","Application framework",[],"Nuxt Agentic",4,[22,75,28],"Nuxt UI","\u002Fprojects\u002Fnuxt-agentic",{"slug":78,"title":79,"description":80,"body":81,"category":82,"sources":83,"name":95,"order":96,"status":59,"stack":97,"repository":24,"featured":25,"path":99},"open-source-charts","Open-source charts — a project by Dennis Adriaansen","vue-chrts, angular-chrts and visx-vue: visualization work across the frontend ecosystem.","\n## Charting beyond one framework\n\nNuxt Charts connects to a broader set of visualization projects I work on as Dennis Adriaansen. You can find them under the GitHub account [dennisadriaans](https:\u002F\u002Fgithub.com\u002Fdennisadriaans).\n\n## vue-chrts\n\n[vue-chrts](https:\u002F\u002Fgithub.com\u002Fdennisadriaans\u002Fvue-chrts) is the Vue chart package behind the Nuxt-focused work. It uses Unovis and provides a component-oriented way to build charts in Vue applications.\n\n## angular-chrts\n\n[angular-chrts](https:\u002F\u002Fgithub.com\u002Fdennisadriaans\u002Fangular-chrts) brings chart components to Angular. I shared [a public update about the Angular work](https:\u002F\u002Fx.com\u002FDennisAdriaans\u002Fstatus\u002F2018720917036114092), also built around Unovis.\n\nThe framework changes, but the need for clear defaults, readable charts and understandable APIs stays familiar.\n\n## visx-vue\n\n[visx-vue](https:\u002F\u002Fgithub.com\u002Fdennisadriaans\u002Fvisx-vue) explores expressive, low-level visualization primitives for Vue. It is a different level of abstraction from a ready-made chart component.\n\nThe repository READMEs describe each package’s actual setup and scope. Read [chart design across Vue, Nuxt and Angular](\u002Fblog\u002Fchart-design-across-vue-nuxt-and-angular) for the ideas connecting the work.\n","Vue & Angular",[84,86,89,92],{"label":85,"url":24},"vue-chrts",{"label":87,"url":88},"angular-chrts","https:\u002F\u002Fgithub.com\u002Fdennisadriaans\u002Fangular-chrts",{"label":90,"url":91},"visx-vue","https:\u002F\u002Fgithub.com\u002Fdennisadriaans\u002Fvisx-vue",{"label":93,"url":94},"My Angular chart announcement on X","https:\u002F\u002Fx.com\u002FDennisAdriaans\u002Fstatus\u002F2018720917036114092","Open-source charts",5,[21,98,23],"Angular","\u002Fprojects\u002Fopen-source-charts",1794481660655]