DEV Community: schukai

Workspaces: Building a Headless Company OS for API-first Processes and AI Agent Workflows

Volker Schukai — Mon, 04 May 2026 00:42:46 +0000

Workspaces: Building a Headless Company OS for API-first Processes and AI Agent Workflows

Many business systems were historically built around user interfaces.

CRM? UI.
ERP? UI.
Document management? UI.
Commerce? UI.
Reporting? UI.

That works as long as humans manually execute every process step.

But modern companies increasingly need something else: systems that can be automated, integrated, and controlled by other systems.

This is one of the reasons we are building Workspaces.

Workspaces is our approach to a headless Company OS with an ERP core, web administration, and API-based operation for business processes. The platform brings together CRM, commerce, PIM, documents, workflows, tasks, compliance, reporting, chat, newsletters, AI-adjacent features, and task streams in one shared multi-tenant system.

But this article is not meant to sound like everything is already perfect.

It is not.

We are not perfect either. But we are working on it.

And that is actually an important part of the story.

Workspaces is not just a product name for us. It is a direction. A journey. A long-term attempt to make operational business software more programmable, more open, and more useful for automation.

The goal is not simply to build another ERP with a nice web interface.

The goal is to build a platform where humans, systems, integrations, and eventually AI agents can work with business processes through stable contracts.

Why We Started Thinking About This

If you have ever integrated business software, you probably know the problem.

Many systems have an API, but the API often feels like an afterthought.

The UI is the real product.

The API is something added later.

The documentation is incomplete.

The data model is hard to understand.

Permissions are unclear.

Workflows are hidden inside UI actions.

Automation requires too much custom glue code.

For simple integrations, this might still work.

For serious automation, it becomes painful.

And when AI agents enter the picture, the problem becomes even more obvious.

An AI agent does not need a beautiful dashboard. It needs reliable answers to very practical questions:

Which actions are available?
Which data may I access?
Which parameters are required?
Which workflow can I start?
How do I check the current status?
What happens if something fails?
In which tenant and permission context am I operating?

A system that was designed only from a UI perspective usually cannot answer these questions cleanly.

That is the gap we are trying to close with Workspaces.

The Basic Idea Behind Workspaces

Workspaces is designed as a headless-capable business platform.

The web administration interface is still important. People need good tools. Teams need dashboards, forms, lists, reports, tasks, and workflows.

But the UI should not be the only way to operate the system.

Core functions should also be accessible through APIs. Processes should be controllable by external systems. Clients should be able to discover what is available. Authentication and permissions should be part of the platform contract.

In simplified form, the idea looks like this:

External systems
AI agents
Integrations
Automations
Internal web administration
        │
        ▼
     /api/v1
        │
        ▼
Workspaces Company OS
CRM · ERP · Commerce · PIM · Documents · Workflows · Tasks · Reporting · Compliance

The important part is this:

API access is not supposed to be a side feature. It is supposed to be part of the foundation.

This is something we are actively working toward.

Some parts are already there. Some parts are still evolving. Some things will certainly change as we learn from real use cases.

But the direction is clear: business software should become more programmable.

API-first Is More Than “We Have an API”

A lot of software products say they are API-first.

But in practice, “API-first” can mean very different things.

For us, it means that the API should not merely expose database objects. It should represent useful business capabilities.

Not only:

POST /contacts
PATCH /orders/123
GET /documents/456

But also:

Start a customer onboarding workflow.
Create a task in the correct business context.
Attach a document to an entity.
Check the status of an automation.
Expose available capabilities to a client.
Respect tenant and permission boundaries.

This distinction matters.

Business software is not only about data. It is about processes.

And processes need more than CRUD.

Discovery-first Instead of Hardcoded Assumptions

One principle we care about is discovery.

Instead of forcing clients to hardcode every path, every feature, and every entry point, we want Workspaces to expose available capabilities at runtime.

A simplified example could look like this:

GET /api/v1/capabilities

The response could describe which capabilities are available in the current context:

{
  "tenant": "example-company",
  "capabilities": [
    {
      "name": "crm",
      "entrypoint": "/api/v1/crm",
      "actions": ["read_contacts", "create_contact", "update_contact"]
    },
    {
      "name": "documents",
      "entrypoint": "/api/v1/documents",
      "actions": ["upload", "classify", "link_to_entity"]
    },
    {
      "name": "workflows",
      "entrypoint": "/api/v1/workflows",
      "actions": ["start", "inspect", "cancel"]
    }
  ]
}

This is useful for traditional clients.

It is even more useful for dynamic clients and AI agent workflows.

Instead of assuming:

I hope this endpoint exists.

A client can ask:

What can I do here?
Which capabilities are available?
Which actions are allowed?
Where do I start?

That is the kind of interaction model we want.

We are not fully done with this vision. But we believe this is the right direction.

Why OpenAPI-like Contracts Matter

For developers, an API is only truly useful when it is documented, consistent, and machine-readable.

That is why Workspaces moves toward OpenAPI-like contracts, structured metadata, and field-level descriptions.

This matters for:

SDK generation
API clients
validation
tests
external integrations
AI agent tooling
documentation
field-level access control
privacy-aware data handling

In business software, a JSON response alone is not enough.

A client should be able to understand which fields are readable, writable, required, sensitive, or restricted.

A simplified example:

{
  "resource": "contact",
  "fields": {
    "id": {
      "type": "string",
      "readOnly": true
    },
    "email": {
      "type": "string",
      "privacy": "personal_data",
      "required": true
    },
    "customerNumber": {
      "type": "string",
      "readOnly": true
    },
    "internalNote": {
      "type": "string",
      "visibility": "restricted"
    }
  }
}

For normal software clients, this is helpful.

For AI agents, it becomes essential.

An agent should not simply read, interpret, or modify everything it sees. It needs boundaries. It needs contracts. It needs to know what is allowed.

This is one of the reasons we think API design, metadata, and privacy-aware field contracts are becoming more important, not less.

Headless Authentication and API Key Operation

If business processes should be automated, a classic browser login is not enough.

External systems, services, and agents need ways to authenticate without a human clicking through a web interface.

That is why Workspaces supports and continues to evolve around headless login flows and API key operation.

But authentication alone is not enough.

Every API call exists in a business context:

Who is calling?
For which tenant?
With which permissions?
For which capability?
For which purpose?

This is especially important in a multi-tenant system.

An AI agent that analyzes documents, creates tasks, or updates CRM data must not operate outside its allowed context.

Permissions, tenant context, and authentication should not be bolted on later. They should be part of the platform contract from the beginning.

This is a difficult area, and we are still learning.

But it is also one of the most important areas.

Because automation without clear boundaries is not progress. It is risk.

Workflows Instead of Isolated API Calls

Many APIs are built around isolated operations.

Create this.
Update that.
Delete something else.

That is necessary, but it is not enough for real business processes.

A typical process often looks more like this:

A new lead comes in.
The company and contact data are checked.
A CRM record is created or updated.
A document is attached.
A compliance rule is evaluated.
A task is created.
A person or team gets assigned.
A reporting event is written.
The process continues depending on the result.

If this logic lives only in external scripts, middleware, or cron jobs, the process becomes fragmented.

The data is in one place.
The workflow is somewhere else.
The business rules are hidden in custom code.
The status is hard to inspect.

That is exactly what we want to improve.

Workspaces is designed to support workflows and task streams so that integrations and agents can work with processes, not just records.

A simplified workflow start could look like this:

POST /api/v1/workflows/start

{
  "workflow": "new_customer_onboarding",
  "input": {
    "companyName": "Example GmbH",
    "email": "info@example.com",
    "source": "website"
  }
}

The response could return the current process state:

{
  "workflowRunId": "wf_123456",
  "status": "running",
  "next": {
    "type": "task",
    "assignedTo": "sales",
    "label": "Review customer data"
  }
}

This turns the API into more than a data pipe.

It becomes a process interface.

Why This Matters for AI Agents

AI agents are often described as chatbots.

But for business software, the more interesting question is not whether an agent can chat.

The interesting question is:

Can an agent safely perform useful work inside real business processes?

To do that, the agent needs access to tools, data, workflows, and status information.

But that access must be controlled, traceable, and understandable.

Workspaces is being built with this direction in mind.

An agent should be able to:

discover available capabilities
authenticate headlessly
operate in a tenant context
understand allowed actions
call APIs with documented parameters
start workflows
create tasks
check process state
write results back into the business context

This does not mean that every process should be fully autonomous.

It also does not mean that an AI agent should replace human decision-making everywhere.

In many cases, the best model is a hybrid one:

Agent prepares.
System validates.
Human approves.
Workflow continues.

That is a much more realistic and useful approach than pretending that everything should be automated immediately.

A Possible Agent Scenario

Imagine a company receives an inquiry through a web form:

"We are interested in product X and would like to receive an offer."

An AI-assisted workflow in Workspaces could look like this:

Receive the inquiry.
Check whether the company already exists.
Create or update the CRM contact.
Fetch product information from the PIM.
Link relevant documents or price lists.
Check compliance or internal rules.
Create a task for the sales team.
Write the current status into the task stream.
Prepare a draft response.
Let a human review and send it.

The agent does not need to rebuild the CRM, ERP, PIM, document management, and task system.

It uses Workspaces as the operational control center.

AI agent
  │
  ├─ queries available capabilities
  ├─ authenticates headlessly
  ├─ reads permitted CRM and PIM data
  ├─ starts workflows
  ├─ creates tasks
  ├─ checks status
  └─ writes results into the process context

This is the kind of architecture we believe will become increasingly important.

Not because AI magically solves every business problem.

But because AI becomes much more useful when it can operate through stable, well-defined, permission-aware interfaces.

The Hard Part: Business Software Is Messy

One thing we have learned again and again: business software is messy.

Every company has different processes.
Every team has exceptions.
Every workflow has edge cases.
Every integration reveals another detail.
Every automation needs guardrails.

That is why we do not want to present Workspaces as if everything is finished and flawless.

It is not.

We are building it step by step.

We are improving the APIs.
We are refining the capability model.
We are working on better metadata.
We are improving workflow handling.
We are learning where automation helps and where humans must stay in control.

And yes, sometimes we discover that something we built needs to be changed.

That is part of the journey.

The important thing is the direction:

We want to make operational business software programmable, discoverable, automatable, and ready for a future where humans, systems, and AI agents work together.

Why a Shared Data and Process Framework Matters

Many companies use a separate tool for every area:

CRM for contacts
shop system for commerce
PIM for product data
DMS for documents
task tool for assignments
newsletter tool for communication
reporting system for analytics
compliance tool for rules

That can work.

But it creates integration cost.

Every automation has to connect multiple systems.
Every agent needs several APIs.
Every process must synchronize context across tools.
Every exception creates another piece of glue code.

Workspaces follows a different approach.

Operational domains should exist in one shared multi-tenant system, or at least in a shared process and API framework.

That does not mean every company has to treat everything as one monolith.

But it does mean that processes can be modeled more consistently across domain boundaries.

For developers, this is helpful because less logic disappears into middleware, cron jobs, and one-off scripts.

What Developers Might Find Interesting

For developers, Workspaces becomes especially interesting when business software is not only used, but integrated, extended, automated, and programmed.

Some of the technical ideas behind it are:

API-first architecture
headless operation
discovery endpoints
capability-based access
OpenAPI-like contracts
machine-readable metadata
privacy-aware field contracts
multi-tenancy
permission and authentication context
workflow start and status inspection
task stream integration
operational domains in one shared system

This is a different perspective on business software.

Not:

Here is an ERP with a user interface.

But:

Here is an operational backend that humans, systems, and agents can use through stable contracts.

That is what we are working toward with Workspaces.

Conclusion

Workspaces is our attempt to build an API-first, headless-capable business platform for operational processes.

It combines an ERP core, CRM, commerce, PIM, documents, workflows, tasks, compliance, reporting, communication, and additional functions in one shared multi-tenant system.

But more importantly, Workspaces is part of a broader journey:

We want to make business processes programmable.

We want APIs that are not just technical endpoints, but reliable business contracts.

We want discovery, metadata, authentication, permissions, workflows, and task streams to work together.

We want AI agents and external systems to interact with business software safely and meaningfully.

And we know this is not easy.

We are not perfect either. But we are working on it.

For us, Workspaces is not a finished claim that all problems are solved.

It is the direction we are building toward.

A headless Company OS for businesses that want their processes to become more integrated, more automated, and more programmable.

You Don’t Always Need React — Sometimes You Just Need Structure

Volker Schukai — Mon, 13 Apr 2026 16:51:07 +0000

Structure in the browser without committing to a framework

At some point, most frontend projects hit the same wall.

You start simple: a bit of vanilla JavaScript, maybe some fetch calls, a few event listeners. It works. It’s fast. It feels clean.

Then the UI grows.

Forms get more complex. State starts leaking across components. Validation logic spreads. Tables need filtering, pagination, persistence. Suddenly, “just JavaScript” turns into a pile of implicit behavior.

That’s usually the moment where teams reach for a framework like React or Vue.js.

And to be fair—those solve a lot of problems. But they also come with their own cost: another abstraction layer, a different mental model, and often a growing distance from the platform itself.

monsterjs takes a different approach.

Working with the platform, not around it

Instead of replacing the browser model, monsterjs leans into it.

It builds on:

Custom Elements
Shadow DOM
ES Modules

No virtual DOM. No proprietary templating language. No “magic” rendering pipeline.

You still write HTML, CSS, and JavaScript—but with a layer of structure that helps you scale beyond toy examples.

Where it actually helps

The goal isn’t to reinvent everything. It’s to make common application patterns easier and more consistent.

Things like:

declarative DOM updates instead of manual wiring
form-associated custom elements that behave like real inputs
reactive data binding without a full framework runtime
REST-backed forms and datatables that reflect real backend flows
built-in i18n handling
reusable UI building blocks you can compose

From simple pages to real application flows

The interesting part is how far you can push this without leaving the platform.

monster-register-wizard
A full multi-step registration flow: email availability checks, profile + address steps, consent handling, validation, API mapping.
monster-file-manager
Browse files in a tree, open them in tabs, attach editors by MIME type.
monster-datatable
Pagination, filters (input, select, range, date-range), save/status handling—built for real CRUD interfaces.
Form controls like
monster-credential-button,
monster-tree-select,
monster-variant-select,
monster-repeat-field-set

These aren’t demo widgets. They’re meant for actual application complexity.

Getting started without friction

One of the nice things: you don’t have to commit upfront.

You can start with a minimal browser setup—no build step, no tooling overhead—and grow into a package-based setup later if needed.

The documentation on monsterjs.org reflects that:

a dedicated getting-started section
examples that go from simple to structured
and even an llms.txt file, making it easier to consume the project through AI tooling when you just want quick orientation instead of reading everything

When this approach makes sense

monsterjs fits best if you:

want to stay close to the DOM and browser APIs
prefer composable building blocks over full frameworks
need structure for complex forms, CRUD UIs, and flows
don’t want to introduce a full rendering framework

If your project is already deeply tied to React, Vue.js, or a similar ecosystem, adding another model probably won’t help.

But if you’re somewhere between “vanilla chaos” and “framework overhead,” this is an interesting middle ground.

https://monsterjs.org/

Monster Select now supports paginated dropdowns – fully reactive, fully open source

Volker Schukai — Wed, 24 Sep 2025 13:30:55 +0000

We added pagination to our select component – and yes, it’s fully open source

Sometimes it’s the small things that make a big difference.

Our latest update to the monster-select component adds something developers (and users) have been asking for: pagination.

No more infinite scrolling. No awkward workarounds. Just clean, native paging – fully integrated.

🔧 What’s new?

We’ve added a pagestepper UI to the dropdown:

Paginated view of options
Configurable number of items per page
Fully reactive (updates with filters and async data)
Works with keyboard navigation
Handles edge cases gracefully (like filtering and empty pages)

Here’s what it looks like:

🧪 Example: Remote Filter + Pagination

Here’s how to configure the select for a real-world use case:

<monster-select
  data-monster-option-filter-mode="remote"
  data-monster-option-filter-position="popper"
  data-monster-option-url="/api/items?filter={filter}&page={page}"
  data-monster-option-mapping-labeltemplate="${name}"
  data-monster-option-mapping-selector="data.*"
  data-monster-option-filter-defaultValue=""
  data-monster-option-mapping-valuetemplate="${id}"
  data-monster-option-features-showremoteinfo="true"
  data-monster-option-remoteinfo-url="/api/items?count=1"
  data-monster-option-mapping-currentpage="meta.pagination.currentPage"
  data-monster-option-mapping-objectsperpage="meta.pagination.perPage"
  data-monster-option-mapping-total="meta.pagination.total"
></monster-select>

This example assumes your backend API returns something like:

{
  "data": [
    { "id": 4, "name": "Item 4" },
    { "id": 5, "name": "Item 5" },
    { "id": 6, "name": "Item 6" }
  ],
  "meta": {
    "pagination": {
      "currentPage": 2,
      "perPage": 3,
      "total": 12
    }
  }
}

Want filtering? It’s already baked in. Just hook up filter={filter} and the component handles debounce, remote updates, and reactivity for you.

💡 Why we built it

Select components can get complicated. Especially when:

You're dealing with large datasets
Filters need to be remote
You want full keyboard and accessibility support
Pagination and state should sync with backend logic

We needed a modular, scalable solution that plays well in modern web apps. So we built it into MonsterJS – and open-sourced the whole thing.

🔗 Explore more

Git: gitlab.schukai.com/.../monsterjs-org
Docs & Live Demos: monsterjs.org

The monster-select is just one part of the puzzle. The lib also includes reactive state management, routing, declarative rendering and more.

We’re building MonsterJS for developers who want structure without the overhead – and components that just work.

✅ TL;DR

Monster Select now supports full pagination
Works with async data and remote filtering
Open Source at monsterjs.org

Try it out. Fork it. Break it. Or build on top of it.

MonsterJS v4 has landed – and it’s hungry.

Volker Schukai — Sun, 11 May 2025 09:58:18 +0000

We’ve released version 4 of our JavaScript component library, and yes, it’s packed with features that’ll make your inner frontend dev do a little dance (even if it’s in Vim).

What’s new in the Monster’s lair?

🧮 Datatables – Show off your data like it deserves, with sorting, paging, and built-in flexibility.

🔍 Select with remote filtering – Hook it to your API, and let users type, search, and select without any awkward full-list dropdowns.

📅 Monthly calendar – Clean, snappy, and ready to display all your timelines and events.
🧱 Drag-and-drop grid – For the moments when you want users to rearrange reality.
✨ …and much more – Yes, we mean it. This release refines performance, improves accessibility, and adds polish all over the place.

Give the Monster a chance. It doesn’t bite (unless your code has no semicolons).

npm i @schukai/monster

Docs, demos, and more goodies live at: https://monsterjs.org

Shadow DOM Perfected: Experience the Power of Monster 3.100!

Volker Schukai — Sun, 12 Jan 2025 19:48:54 +0000

The Shadow DOM is, in our opinion, one of the most exciting new features in modern HTML engines. This concept enables a much better encapsulation and protection of implementation details than ever before, resulting in cleaner and more maintainable code.

What is your opinion of the shadowroot?

Our JavaScript library is built on this principle and offers a comprehensive range of components—everything from sliders and tabs to select controls and data tables. The use of Shadow DOM ensures that our components are not only modular but also highly resilient against styling or scripting conflicts, making them ideal for large-scale applications.

Beyond Shadow DOM, we leverage cutting-edge JavaScript, CSS, and HTML features to create a seamless developer experience. For example, our components take full advantage of JavaScript Proxy objects to enable fine-grained control over state management, making debugging and data tracking more intuitive. CSS custom properties and container queries allow us to deliver responsive and highly customizable designs out of the box, while modern HTML APIs like the IntersectionObserver ensure performance stays top-notch, even with complex UI elements.

With the release of Monster version 3.100, we’ve once again raised the bar with notable improvements:

The slider component now supports displaying multiple slides simultaneously, a much-requested feature that enhances usability and visual appeal.

The select control has been optimized to handle dynamic loading of values and options more efficiently, offering smoother performance in highly dynamic environments.

These updates, combined with our use of the latest web technologies, underscore our commitment to delivering flexible, robust, and feature-rich tools for modern web development.

And the best thing is that it's all open source.

Introducing the New Version of Monster Components: Power Up Your Development Workflow

Volker Schukai — Fri, 15 Nov 2024 14:31:15 +0000

We’re excited to announce the latest version of our Monster component library, packed with enhancements designed to make your developer life easier. Whether you’re building complex applications or refining a simple interface, Monster.js offers tools to save time and improve results.

Highlights from the New Release

Datatable: Structured Data Visualization Made Easy

Our Datatable component is a game-changer for handling structured data. With its intuitive API and seamless integration, you can quickly transform raw data into interactive and visually appealing tables. Explore its features here.

And battery included is the dark mode, so you don’t have to worry about it.

And of course, there’s built-in support for small screens as well.

Why Monster?

On monsterjs.org, you’ll find a rich collection of components and features tailored for developers. From layout tools to advanced UI controls, Monster.js is built to simplify your workflow while giving you the flexibility to create.

Start exploring today and take your projects to the next level!

Custom Function Integration in Element Updater with MonsterJS

Volker Schukai — Fri, 01 Mar 2024 11:49:45 +0000

MonsterJS introduces a flexible way to enhance the functionality of Element Updaters by allowing the attachment of custom functions. This feature provides developers with the ability to extend the standard behavior of Element Updaters, tailoring them to specific needs.

Implementing `updaterPipeCallbacks`

To integrate custom functions with Element Updaters, a control must implement the updaterPipeCallbacks method. This method should return an object containing key-value pairs, where the key is a unique name for the callback, and the value is the function itself.

Example Implementation

Here's an example of how you can define a custom function within a control using onUpdaterPipeCallbacks:

updaterPipeCallbacks() {
    return {
        "my-callback-doing": (value) => {
            switch (typeof value) {
                case "string":
                    return value + "!";
                case "number":
                    return value + 1;
                default:
                    return value;
            }
        }
    }
}

In this example, the my-callback-doing function checks the type of the input value and modifies it based on its type:

If the value is a string, it appends an exclamation mark.
If the value is a number, it increments the value by one.
For other types, it returns the value unmodified.

Using Custom Functions in Templates

Once you've defined your custom functions, you can invoke them in your control's template using the call command within the data binding expression.

Template Integration Example

Here's how you can incorporate the my-callback-doing function into a control's template:

<div data-monster-replace="path:options | index:label | call:my-callback-doing" part="option-label"></div>

In this template snippet, the data-monster-replace attribute is used to dynamically update the content of the <div>. The call:my-callback-doing part specifies that the my-callback-doing function should be applied to the value obtained from path:options | index:label.

Conclusion

By leveraging the updaterPipeCallbacks method, developers can create more dynamic and flexible web components with MonsterJS. Custom functions provide a powerful way to enhance the interactivity and responsiveness of your web applications, ensuring that you can cater to a wide array of use cases and scenarios.

https://monsterjs.org/

Unleashing the Power of Dynamic Web Content with Monster Templating

Volker Schukai — Sun, 25 Feb 2024 16:36:35 +0000

In the ever-evolving landscape of web development, creating dynamic and interactive web applications is more crucial than ever. Enter Monster Templating, a modern and powerful DOM-based templating system that seamlessly integrates your data with the document object model (DOM). This guide delves into the heart of Monster Templating, unveiling how it can transform your HTML into a dynamic, data-driven powerhouse with minimal coding effort.

Embarking on the Monster Templating Journey

The First Steps: Importing the Updater Class

Our adventure begins with the integration of the Updater class from Monster's CDN, a simple yet pivotal step towards unlocking dynamic content creation:

import {Updater} from 'https://cdn.skypack.dev/@schukai/monster@latest/source/dom/updater.js';

Setting the Stage: Preparing Your HTML Document

Monster Templating thrives on flexibility, allowing you to inject data-binding attributes directly into your HTML or dynamically through JavaScript. This dual approach caters to diverse development styles and project requirements:

const body = document.querySelector('body');
const headline = document.createElement('h1');
headline.setAttribute('data-monster-replace', 'path:headline');
body.appendChild(headline);

Or, embed directly in your HTML:

<h1 data-monster-replace="path:headline"></h1>

Bringing Data to Life: Setting Up Data Binding

With Monster, your data becomes the soul of your application, dynamically updating your HTML in real-time:

let obj = { headline: "Go!", };
const updater = new Updater(body, obj);
const subject = updater.getSubject(); // For real-time updates
updater.run();

Demonstrating the magic of dynamic updates, we see how effortlessly the content evolves:

setTimeout(() => { subject['headline'] = "Hello!"; }, 1000);

Exploring the Enchanted Forest of Templating Features

The Magic Wand: Content Replacement

Monster's data-monster-replace attribute stands as your magic wand, enabling you to replace content effortlessly, adding a sprinkle of transformational magic when needed:

<div data-monster-replace="static:HELLO | tolower"></div>

The Alchemist's Lab: Attribute Manipulation

Transform and concoct new attributes with the data-monster-attributes attribute, an alchemist's lab where new properties are forged:

<div data-monster-attributes="id static:myid, class static:myclass">hello</div>

Vanishing Acts: Element Removal

With data-monster-remove, elements disappear from the DOM, a reminder of the impermanence of content in the dynamic web era:

<div data-monster-remove></div>

The Conjurer's Trick: Dynamic Element Insertion

data-monster-insert reveals the conjurer's trick, materializing elements from thin air (or data), showcasing the templating system's strongest feature:

<ol data-monster-insert="myid path:a"></ol>

The Two-Way Mirror: Data Binding for Input Elements

Monster introduces a two-way mirror with data-monster-bind, where input fields and data models reflect and influence each other:

<input type="text" data-monster-bind="path:a.b">

The Grand Library of Data Types

As we delve deeper into the enchanted forest, we uncover a grand library of data types, each with its own unique charm and function. From casting numeric spells with number to weaving complex structures with object, Monster Templating accommodates a diverse array of data types, ensuring your web applications are as dynamic and versatile as the world they inhabit.

Epilogue

Monster Templating doesn't reinvent web development, but it is a lightweight alternative. The real adventure lies in applying these principles to your projects to transform static HTML into living, breathing web applications that respond and evolve with your users' interactions.

https://monsterjs.org/

The awakening of the monster

Volker Schukai — Sun, 05 Nov 2023 15:52:35 +0000

We are pleased to announce the latest development in our JavaScript project: the release of the latest Monster library (3.52).

This release marks an important milestone in the development of our web initiative by combining our previously separate components into a single, robust package.

A look at the past

In the past, you had to manage multiple dependencies within the @schukai ecosystem, such as @schukai/component-form and other individual packages.

While these modules served their purpose, they also introduced complexity when it came to version control, dependency management, and overall project coherence.

What's new in @schukai/monster?

The @schukai/monster library simplifies the development workflow by bringing all the high quality components you rely on under one roof.

What you can expect:

Unified code base: A single NPM package is managed, resulting in smoother updates and integrations.

Streamlined development: With everything in one place, you'll spend less time juggling packages and more time building great applications.

Improved performance: We've optimized internal dependencies and ensured that the unified library meets or exceeds each package's performance benchmarks.

Seamless integration: The transition to @schukai/monster has been made as seamless as possible, requiring minimal changes to existing projects.

To make the transition easier for you, we have created a comprehensive migration guide. Here are the main steps to get you started:

Refactor your import directives to reference @schukai/monster.

Follow the detailed instructions for any specific components that require additional migration steps.

Looking to the future

The release of @schukai/monster is more than just an update - it's a commitment to the future of development in our ecosystem. We will continue to support the library with regular updates, new features and improvements based on your feedback.

We invite you to use the power and simplicity of @schukai/monster in your next project. Stay tuned for more updates, and happy coding!

monsterjs.org/

YAConfigLib - Dynamic Configurations in Go: Introducing Postprocessing Hooks

Volker Schukai — Mon, 14 Aug 2023 15:40:14 +0000

Hey Gophers! 🚀

Do you struggle with configuration files in different formats like JSON, YAML or TOML in your Go applications? If yes, then you appreciate the value of a robust configuration management library.

Today we released a brand new feature in our configuration library.

We present: Postprocessing Hooks! 🌟

Imagine, you can not only read configurations in different formats, but now you can also define hooks that are triggered directly when a configuration change is made. Previously, you could also solve this via ChangeHooks, but these ran in their own Go routine.

The decisive advantage for tasks such as

Changing paths based on new configurations.
Building new structures after loading configurations.
Integrating real-time responses to dynamic configurations into your application.

Why should you try the new feature of our configuration library?

Flexibility: read and manage configurations in YAML, TOML and JSON.
Reactivity: Real-time actions based on dynamic configuration changes.
Powerful: Efficient handling without the overhead of additional routines.

We are convinced that after your first experience with Postprocessing Hooks, you will wonder how you ever got along without it!

Try it out, share your feedback and let's improve dynamic configurations in Go together!

Stay tuned for more exciting updates. Have a great time programming! 🎉

https://gitlab.schukai.com/oss/libraries/go/application/configuration

Remote Brew: The Secret Blend of Team Bonding and Communication

Volker Schukai — Sun, 23 Apr 2023 15:41:54 +0000

Imagine you are an entrepreneur, executive, or part of a team that has been working remotely since the start of the pandemic. In this new work environment, you and your colleagues are seeking ways to maintain informal exchanges and a sense of community despite the physical distance. This article explores how virtual coffee breaks and casual coworking can help achieve that.

The Challenge

Our company had already successfully transitioned to remote work before the pandemic, and we were fortunate to not have to learn it the hard way.

However, over the past few years, we have also faced many challenges such as the lack of informal exchange moments that used to occur around the coffee machine or during lunch breaks. This has led to employees feeling more isolated and less connected to one another."

One, Two or Many Ideas

We have devoted considerable thought to addressing and improving this challenge. We have explored many potential approaches and discarded them. One current idea involves creating a virtual space where the team can meet spontaneously and informally, much like a real coffee break.

How can this be implemented technically and organizationally? We have experimented with various methods.

To address the challenge of fostering casual exchanges between remote team members, we took a hopefully simple approach by creating a virtual "water cooler" or "coffee break room." This room is technically implemented as a zoom room. The ambience is designed to be appealing and inviting. It also integrates seamlessly with our favorite communication tools such as instant messaging platforms.

We encourage all team members to seek out this space when they are taking a break, chatting with colleagues, or just looking for a moment to relax. We see this virtual space as a means to recreate the spontaneous interactions that used to take place in the office, fostering a sense of community and connection among team members.

So far, we are enthusiastic about the potential of virtual coffee chats and plan to explore additional possibilities in the future.

And Now for Something Completely Different

In addition to the virtual coffee machine, we are testing another concept.

We also regularly schedule informal virtual events and team-building activities, such as virtual happy hours and game nights. These events are designed to be fun and help team members get to know each other better in a relaxed and informal setting.

By combining the virtual water cooler with these regular virtual events, we seek to cultivate a sense of social cohesion and support to help mitigate the challenges of telecommuting and foster a positive work culture.

Casual coworking

We work together casually by inviting two or three team members to at least one-hour sessions. After a brief greeting, the cameras are turned off. The microphone and speakers, however, remain on. Everyone starts working.

If someone needs to discuss something, they can turn on their camera as needed.

At the end of the session, there is a virtual goodbye, and we exchange information about work and personal matters.

Unlike pair programming or collaboration, the focus here is not on working together on a project. People can even work on different tasks.

The structure:

Casual coworking with scheduled one-hour sessions
Focus on individual work with the option for brief interactions
Virtual goodbye and exchange of information at the end of each session

Our previous experiences indicate that virtual coffee breaks and casual coworking can be effective. However, it's crucial to ensure that the framework is appropriate and to continue refining the formats.

In an era where distance and remote work define the daily routines of many people, it is more important than ever to find ways to maintain a sense of community and informal exchange. Virtual coffee breaks and casual coworking are two examples of how this can be achieved.

Hey there! Have you had any experiences like this or maybe some cool, innovative ideas of your own? We'd love to hear about them in the comments below. Your positive feedback means a lot to us, so let's chat

Understanding Shadow DOM and Shadow Roots in JavaScript: A Simple Guide for Beginners

Volker Schukai — Thu, 30 Mar 2023 21:30:05 +0000

As part of development on the Monster open-source project, our developers often use the powerful Shadow DOM technology to create complex components. This article aims to provide a concise explanation of what Shadow DOM is all about and how knowledge of it can be beneficial when working with Monster components. We will also explore the basics of the Shadow Roots API in JavaScript, which is an essential part of the Web Components standard and allows the creation of encapsulated, reusable components. With the help of a simple example, beginners will find it easier to understand and apply these concepts in their projects.

What is Shadow DOM?

Shadow DOM is a powerful web standard that lets you create encapsulated HTML, CSS, and JavaScript in your web components. It lets you create self-contained components whose internal structure, style, and behavior remain separate from the main DOM tree. This separation ensures that the styles and scripts within a component do not interfere with other elements on the page.

What is a Shadow Root?

A Shadow Root is the root element of a Shadow DOM tree. It is attached to a host element, which is a regular DOM element. The Shadow Root acts as a boundary between the host element and the Shadow DOM, providing encapsulation.

Creating a Shadow Root:

To create a Shadow Root, you can use the attachShadow() method on a DOM element. This method takes an object with a single property, mode, which can be set to either 'open' or 'closed'. An open Shadow Root can be accessed using JavaScript, while a closed one cannot.

<!DOCTYPE html>
<html>
<head>
  <style>
    .container {
      border: 1px solid black;
      padding: 10px;
    }
  </style>
</head>
<body>
  <div class="container" id="container"></div>
  <script>
    const container = document.getElementById("container");
    const shadowRoot = container.attachShadow(
            { mode: "open" }
          );

    shadowRoot.innerHTML = `
      <style>
        p {
          color: red;
        }
      </style>
      <p>Hello, Shadow DOM!</p>
    `;
  </script>
</body>
</html>

In this example, we create a Shadow Root attached to a <div> element with the class "container". Inside the Shadow Root, we define a <style> block with a rule for <p> elements and a <p> element with the text "Hello, Shadow DOM!". The style defined inside the Shadow Root applies only to elements within the Shadow Root and does not affect the main DOM.

Understanding Shadow DOM and Shadow Roots in JavaScript is essential for developers starting to work with Web Components. The encapsulation they provide helps create reusable, self-contained components that do not interfere with the main DOM tree. With this simple guide and example, you should now have a solid foundation for working with Shadow DOM and Shadow Roots in your projects.

There is still a lot to say about this topic, as the world of Shadow DOM and Web Components continues to evolve. If you have any questions or need further clarification, please feel free to post them in the comments section. We'll be more than happy to help you on your journey to mastering Shadow DOM and creating incredible web components.

DEV Community: schukai

Workspaces: Building a Headless Company OS for API-first Processes and AI Agent Workflows

Workspaces: Building a Headless Company OS for API-first Processes and AI Agent Workflows

Why We Started Thinking About This

The Basic Idea Behind Workspaces

API-first Is More Than “We Have an API”

Discovery-first Instead of Hardcoded Assumptions

Why OpenAPI-like Contracts Matter

Headless Authentication and API Key Operation

Workflows Instead of Isolated API Calls

Why This Matters for AI Agents

A Possible Agent Scenario

The Hard Part: Business Software Is Messy

Why a Shared Data and Process Framework Matters

What Developers Might Find Interesting

Conclusion

You Don’t Always Need React — Sometimes You Just Need Structure

Structure in the browser without committing to a framework

Working with the platform, not around it

Where it actually helps

From simple pages to real application flows

Getting started without friction

When this approach makes sense

Monster Select now supports paginated dropdowns – fully reactive, fully open source

🔧 What’s new?

🧪 Example: Remote Filter + Pagination

💡 Why we built it

🔗 Explore more

✅ TL;DR

MonsterJS v4 has landed – and it’s hungry.

Shadow DOM Perfected: Experience the Power of Monster 3.100!

Introducing the New Version of Monster Components: Power Up Your Development Workflow

Highlights from the New Release

Datatable: Structured Data Visualization Made Easy

Why Monster?

Custom Function Integration in Element Updater with MonsterJS

Implementing updaterPipeCallbacks

Example Implementation

Using Custom Functions in Templates

Template Integration Example

Conclusion

Unleashing the Power of Dynamic Web Content with Monster Templating

Embarking on the Monster Templating Journey

The First Steps: Importing the Updater Class

Setting the Stage: Preparing Your HTML Document

Bringing Data to Life: Setting Up Data Binding

Exploring the Enchanted Forest of Templating Features

The Magic Wand: Content Replacement

The Alchemist's Lab: Attribute Manipulation

Vanishing Acts: Element Removal

The Conjurer's Trick: Dynamic Element Insertion

The Two-Way Mirror: Data Binding for Input Elements

The Grand Library of Data Types

Epilogue

The awakening of the monster

A look at the past

What's new in @schukai/monster?

Looking to the future

YAConfigLib - Dynamic Configurations in Go: Introducing Postprocessing Hooks

Remote Brew: The Secret Blend of Team Bonding and Communication

The Challenge

One, Two or Many Ideas

And Now for Something Completely Different

Casual coworking

Understanding Shadow DOM and Shadow Roots in JavaScript: A Simple Guide for Beginners

What is Shadow DOM?

What is a Shadow Root?

Implementing `updaterPipeCallbacks`