Forem: Alex M

Symbiote.js: superpowers for Web Components

Alex M — Sun, 19 Apr 2026 16:37:41 +0000

The whole point of creating and adopting new libraries and frameworks is to solve problems that haven't been solved before — or to solve them more efficiently than existing solutions do.

Today we'll start a conversation about the kind of problems Symbiote.js can solve — and do it far more simply and elegantly than other frameworks.

Symbiote.js is a lightweight (~6 KB brotli) yet very powerful library built on Web Components. What sets it apart from the competition is its focus on advanced compositional capabilities within HTML markup (both general and template-based) and a more flexible approach to data contexts.

Symbiote.js is a self-contained solution for building complex modern interfaces. You don't need to assemble the classic sandwich of a global state manager, router, and SSR — it's all built in. At the same time you get maximum creative freedom, with no mandatory dependency on compilers, bundlers, or any closed ecosystem. All of this comes with minimal boilerplate, types, reactivity, a runtime debugger, and everything else useful and modern that we've all grown accustomed to.

Composition

Working with interfaces can be roughly divided into two parts:

Logical — component model and logic + data abstractions
Structural — composing components and data flows

Symbiote.js has its own unique strengths in both areas. But right now I'd like to focus specifically on the second part.

The library is built around HTML. Component templates are standalone HTML strings. External HTML serves as a full-fledged scaffold and a way to define structural dependencies. There is fundamentally no tight coupling to a JS runtime. This lets you manipulate your interface elements at a compositional and declarative level with great flexibility — both on the client and on the server.

You can hydrate pre-rendered markup, render templates from scratch, or use any hybrid approach. You can create "pure" context-provider components and "dumb" components with no logic of their own that automatically connect to a DOM-structure-based or a fully abstract data context. You can use a single component with completely different custom templates without a single extra line of JS — which is especially useful for embeddable solutions, where a declarative approach to configuration is particularly convenient.

Let's move on to examples.

Let's build something straightforward and practical — reusable tabs for our interface.

Our solution consists of two parts: a tab switcher and a view container that displays the selected content.

Step one:

import Symbiote, { css } from '@symbiotejs/symbiote';

class SuperTabs extends Symbiote {

  init$ = {
    '*currentTabName': 'first',
  };

  renderCallback() {
    this.tabEls = [...this.querySelectorAll('[tab]')];
    this.tabEls.forEach((/** @type {HTMLElement} */ el) => {
      let tab = el.getAttribute('tab');
      if (el.hasAttribute('current')) {
        this.$['*currentTabName'] = tab;
      }
      el.onclick = () => {
        this.$['*currentTabName'] = tab;
      };
    });
    this.sub('*currentTabName', (val) => {
      this.tabEls.forEach((/** @type {HTMLElement} */ el) => {
        if (el.getAttribute('tab') === val) {
          el.setAttribute('current', '');
        } else {
          el.removeAttribute('current');
        }
      });
    });
  }
}

SuperTabs.rootStyles = css`
super-tabs {
  display: inline-flex;
  gap: 2px;
  [tab] {
    cursor: pointer;
    &[current] {
      background-color: transparent;
      pointer-events: none;
    }
  }
}
`;

SuperTabs.reg('super-tabs');

Step two:

class SuperTabsView extends Symbiote {
  renderCallback() {
    this.tabCtxEls = [...this.querySelectorAll('[tab-ctx]')];
    this.sub('*currentTabName', (val) => {
      this.tabCtxEls.forEach((/** @type {HTMLElement} */ el) => {
        if (el.getAttribute('tab-ctx') === val) {
          el.setAttribute('active', '');
        } else {
          el.removeAttribute('active');
        }
      });
    });
  }
}

SuperTabsView.rootStyles = css`
super-tabs-view {
  display: block;
  [tab-ctx] {
    display: none;
    &[active] {
      display: contents;
    }
  }
}
`;

SuperTabsView.reg('super-tabs-view');

Our tabs are ready and will work seamlessly alongside any other framework — or entirely on their own:

<super-tabs ctx="section-select">
  <button tab="first">First</button>
  <button tab="second">Second</button>
  <button tab="third">Third</button>
</super-tabs>

<super-tabs-view ctx="section-select">
  <div tab-ctx="first">First content</div>
  <div tab-ctx="second">Second content</div>
  <div tab-ctx="third">Third content</div>
</super-tabs-view>

What's worth noting in these code examples?

The rootStyles interface — in this case, components are created without their own Shadow DOM by default. But they can live inside an external Shadow DOM that may exist somewhere up the tree. Or there may be none at all. Either way, styles are applied correctly. Any Tailwinds, Bootstraps, or shared document styles you're using will work just as expected.
The renderCallback lifecycle hook — it guarantees access to the component's child DOM nodes (the standard connectedCallback does not provide this guarantee).
Property initialization with init$ — here we initialize a property and set its default value (the active tab name).
Property subscription via the sub() method — the fundamental pattern for working with reactive properties: straightforward Pub/Sub. Subscriptions (and unsubscriptions) and value publishing can happen either fully automatically or explicitly, as shown in the example.
Property definition via *propName — declaring a property for the Shared Context. This is no longer a component's own property; it's shared among all components that have the ctx attribute explicitly set. This works similarly to, for example, the native browser element <input type="radio"> and its name attribute.

Also, as you can see, Symbiote.js works perfectly with standard DOM API methods. And unlike many other frameworks, this is absolutely NOT an anti-pattern here — because there is no Virtual DOM.

Working with the other approach — where you do NOT interact with the DOM directly — is equally easy and convenient. For example, let's create a "dumb" component that simply displays the current tab context value:

import Symbiote, { html, css } from '@symbiotejs/symbiote';

class SuperCurrent extends Symbiote {}

SuperCurrent.rootStyles = css`
super-current {
  display: block;
  h2 {
    text-transform: capitalize;
  }
}
`;

SuperCurrent.template = html`<h2>{{*currentTabName}}</h2>`;

SuperCurrent.reg('super-current');

Usage in markup:

<super-current ctx="section-select"></super-current>

That's all it takes — minimal code, and you've linked independent components into a single interacting group. And you can have as many of these components and groups on the page as you need. Naturally, you can bind event handlers and far more complex data structures the same way.

Low-code / no-js

Where is all of this especially useful?

Imagine you've built a library of such atomic components. From there, someone with no deep JavaScript knowledge can assemble interfaces using nothing but HTML markup. Include a script, place the tags with the right attributes — done. No bundler, no framework to keep in mind — just structure and meaning.

Teams often consist of various specialists: designers, analysts, marketers, SEO experts... This way, we create a universally accessible technical communication protocol, enabling a wide range of people to contribute without having to dive into the depths of actual programming or pulling developers in for every small change.

This opens doors for:

Designers — prototyping interfaces directly in HTML
Content managers — configuring content display through attributes, no code required
Embeddable solutions — complex widgets that anyone can customize via HTML without digging into the source code
AI assistants — generating and modifying interfaces on the fly, where a simple and predictable relationship between markup and behavior is critically important

The mechanics described in this article are FAR from everything Symbiote.js can do. I deliberately chose not to overload the material and I'm planning a whole series of similar publications with examples and real-world use cases. On your side, you can run an interesting experiment: ask an AI to provide a solution to a similar problem in any other framework you're interested in, and compare the volume and complexity of the resulting code, bundle size, number of dependencies, and so on. I assure you — the results will make you take a much closer look at Symbiote.js.

R&D: The Art of Managing Uncertainty in Software Development

Alex M — Thu, 16 Apr 2026 14:23:15 +0000

Here are two facts for you:

R&D is the only path to real innovation - the kind that creates competitive advantages and, potentially, reshapes or even creates entirely new markets
Most managers and business stakeholders are terrified of R&D tasks, and these tasks often get solved "despite" the process, not "because of" it

Let's figure out why this happens and what to do about it.

Preamble

I've wanted to share my thoughts on this topic for years, but never got around to it. I've seen it too many times: tasks with many unknowns treated no differently from the rest of the backlog, with the same cookie-cutter formal approaches and the same production metrics applied across the board. And it ALWAYS caused problems. At best - difficulties with planning and realistic deadline estimation. At worst - failed projects and entire teams burning out. I'm guessing many of you can relate.

The brave soul who takes on an R&D task faces a whole extra set of obstacles: from their own mental traps to a complete lack of understanding of what research work actually involves - from colleagues and management alike. On the other hand, it's exactly these kinds of tasks that make our work genuinely exciting.

The first step toward solving many problems, including the ones mentioned above, is acknowledging them. Regardless of your title, you need to be able to distinguish R&D from everything else. Hiding from uncertainty behind formalism only delays the painful collision with reality.

Throughout this article, I'll be drawing on personal experience, so expect a few true stories.

What Is R&D?

Research And Development - literally what it says on the tin. Development is the part that seems relatively predictable. Research is the space of uncertainties and the previously unknown. R&D tasks vary wildly in complexity and importance. The domain of our ignorance can extend in many directions - not necessarily only the technical one.

For example, I once worked on a telemedicine service, and most of the unknowns we had to deal with came from the legal and regulatory domain. The legal part was the key challenge and critically important. From a technical standpoint, the project was relatively straightforward from the start. The project never saw the light of day - it simply couldn't outlast the wait for a telemedicine law that it was being built for. The government insiders let us down with their insider knowledge.

Another example where the uncertainty was purely technical. We were building a virtual clothing try-on service. When I joined the project, there was already a semi-functional prototype that could load clothing models and simulate fabric behavior on a virtual 3D mannequin matched to the potential user's measurements.

The unknown was whether the heavy simulation process could be scaled at all. Fabric physics is complex stuff, and the prototype could barely run on a dedicated GPU. It seemed impossible to make it work in milliseconds per request. Figuring out HOW to do that - that's R&D.

Back then, nobody had really heard of neural networks yet, so we built an interpolation engine that could produce a plausible-looking image based on several pre-computed simulations, simply shifting vertices (polygon points) toward the nearest calculated values. That project, by the way, also didn't survive - for the very reason I'm trying to describe here: the people making key business decisions didn't understand what they were dealing with or what risks they should be accounting for. By the time we had a truly working concept, it was already too late.

This is how people throw millions out the window. Sometimes it's hard to stop when the investment has already passed a critical threshold. You desperately want to recoup what you've spent, and the only way to do that, it seems, is to invest just a little more. This dangerous mental trap is a direct consequence of not having a separate, systematic approach to R&D.

So what do we do?

Managed Chaos

Surprisingly, many people dislike the word "Chaos," treating it as some synonym for disorder. However, chaos as a mathematical concept is an important characteristic of what inevitably surrounds us, whether we like it or not. Any small thing can trigger serious consequences. The states of complex systems are difficult (impossible) to reliably predict over long time horizons.

At the same time, the field of possible variants and states tends toward a certain common Attractor. To put it simply: we can be wildly wrong about tomorrow's weather, but we always know that winter is generally cold and summer is generally warm (in the corresponding hemisphere). This kind of knowledge, applied to development, comes with experience. An experienced engineer may not be able to name an exact date, but they can feel the "temperature corridor" of a project - where the gravitational center of risk lies, where the zone of relative stability is. They also recognize that the illusion of control through following rituals consumes resources beautifully while guaranteeing, essentially, nothing.

When it comes to R&D, this is especially relevant. The way forward is to learn to read signals from the real world and apply chaos engineering practices - where the primary data source for analysis is the working system itself, at any stage of its lifecycle. Here we simply apply the scientific method and get rid of "shamanic" practices. The problem is that we're surrounded by plenty of "shamans" who don't appreciate this.

The Focus Trap

Focusing on one thing rather than jumping between different aspects of a larger task sounds, at first glance, reasonable. Predictable, controllable... Your average manager likes that. The problem is that it often leads to perfecting one node or aspect of a fundamentally unviable model.

This is essentially the "local optimization" problem: you're polishing one component to a mirror finish without noticing that the entire mechanism is flawed. In conventional development, you might get away with it - at the cost of a refactor. In R&D, the price is different: you can spend months perfecting a component that turns out to be useless after its first contact with reality.

In R&D, it's crucial to periodically step back from narrow or intermediate goals, forming and refining the big picture before diving back into the details. Focusing on small tasks gives a pleasant feeling of progress, but be careful not to fall into this trap - celebrating progress on a road to nowhere.

Here's another example. I worked on a platform for finding and selling auto parts. The complexity was that searches had to run across enormous databases of part numbers, including all possible analogs. You had to find matches across car makes and models, production years, VIN numbers, manufacturer data, supplier and warehouse data - practically in real time. Making this search fast was a non-trivial task, especially considering we were assembling the data from various sources, practically from scratch. One of our microservices was a custom VIN decoding API. We spent a significant amount of time on this task - it turned out to be far less trivial than it looked at first glance. In the end, the project was cancelled and all the work went into the drawer. Our grand plans never even received a fair assessment of feasibility - we simply ran out of time. But while we were grinding away at that VIN decoder, it felt like we were making great progress.

Plan B

It's important to understand that in R&D, a negative result is still a valid result. Sometimes a task hits a previously unknown factor and turns out to be simply unsolvable within the given constraints. If your entire project depends on it, you should ideally think about a "Plan B" while still defining the initial conditions.

Think about what assets you're acquiring along the way and how they might recoup costs, fully or at least partially. Think about possible pivot points. This should be done both upfront and periodically throughout the work. Think in advance about strategies for confronting risks. Many failures can be turned into wins if you think in the right frame.

A good R&D process generates value even on the path to failure. Libraries you've written. Datasets you've collected. Expertise the team has acquired. Patents. Articles. Open-source components. All of these are side assets that can be monetized or reused if the main hypothesis doesn't hold up.

A key practice here is defining kill-criteria in advance. Before work even begins, formulate specific, measurable conditions under which you stop the project. This isn't pessimism - it's professionalism. Without predefined boundaries, it's easy to fall victim to sunk cost fallacy, which was mentioned above.

Fresh Eyes

Sometimes people who've been stewing in a big project for too long lose the ability to see it clearly from the outside. The effects of mental traps and self-compromises made for psychological comfort tend to accumulate over time. Don't assume this is a sign of someone's incompetence. We're all (still) human, and human behavior is inherent to all of us - even the most brilliant among us.

That's why a fresh perspective is so important in projects with a high R&D component. Sometimes it's useful to criticize yourself, retrospectively evaluate your decisions, and be willing to reconsider them. Sometimes it's important to hear an outside opinion. Such opinions may seem amateurish and superficial, but often they reveal exactly how things look from outside your cozy process - the one you undoubtedly understand better than anyone.

The Start-Pause-Stop System

One of the practices used for managing uncertainty. Each new step may depend on the results of the previous one. Sometimes the entire process can hang for a long time waiting for some data. Sometimes work should be stopped entirely and the team should switch to something else. Your processes need to be adapted to three basic states. Pausing the main R&D branch automatically pauses all subtasks. Stopping triggers a preservation algorithm (for further reuse of artifacts, for example in another project, or for possible revival and continuation of work at some undefined point in the future). All process participants must be notified in time about changes in global status and be ready to switch as painlessly as possible. This approach helps significantly save resources, makes the process more transparent and manageable for business, and preserves the work done.

R&D Metrics

Classic development metrics - velocity, story points, burndown charts - work poorly in R&D. They measure speed of movement, but not its direction. You can "burn" story points at cosmic speed while heading in the wrong direction.

For R&D, other indicators are more informative:

Number of hypotheses validated per unit of time - shows real research velocity
Cost of validating a single hypothesis - helps optimize the experimentation process
Time to first contact with reality - the sooner a prototype hits a real environment, the better
Ratio of reusable artifacts to total work volume - shows how much value you're generating "along the way"

These metrics don't give an illusion of control - they give real feedback.

Team Requirements

One important consideration is the elevated requirements for team members working in R&D. Unfortunately, this type of work doesn't suit those who haven't yet had the chance to learn the hard way on real projects. Juniors can be valuable in routine development with a clear spec, but R&D demands something different: the ability to work in conditions where the spec is something you must formulate yourself as you go. You can try running such a project with juniors, mid-levels, or offshore contractors, but there's a high probability the result will be painful. R&D demands a high degree of self-organization and SELF-discipline from the team, and those only come with experience. At the same time, the team needs a creative atmosphere, because the best ideas will come from people who are genuinely INTERESTED. This process is practically impossible to manage effectively through micromanagement and pre-defined formal methodologies. This creates a paradox: cutting costs on people will end up costing you more. At the same time, an R&D team should be compact, so that communication overhead doesn't consume all your resources.

AI

Neural networks are excellent for automating routine work and conducting quick intermediate micro-research. They're also extremely useful for creating side artifacts: documentation, demos, tests, etc.

But there's a nuance. AI works great in the zone of the known - it generalizes patterns from already existing solutions. R&D, by definition, operates in the zone of the unknown. AI is not (yet) capable of generating truly new ideas - it can only combine existing ones within a limited range. This makes it a powerful accelerator for an experienced R&D specialist who knows which questions to ask. But a poor substitute for such a specialist.

Fully replacing R&D specialists is not yet possible. But AI has already become an excellent tool in the hands of an experienced researcher - and the significance of this tool continues to grow.

Crisis-Mode R&D

Consider a situation where R&D becomes not the source of a crisis, but the answer to one. When the market collapses, a technology becomes obsolete, or an unexpected competitor arrives - it's exactly R&D thinking that enables rapid adaptation.

Crisis-mode R&D differs from planned R&D in three ways:

Speed over quality. You don't need a perfect product - you need a working prototype that proves the viability of a new model. MVP in the literal sense.
Resources are limited. Crisis typically means a slashed budget. Paradoxically, this sometimes helps: constraints force more inventive solutions and cut through all the noise.
High risk tolerance. When there's almost nothing left to lose, space opens up for experiments that would be unthinkable in "peacetime."

In essence, a well-established R&D process is your insurance against crises. A team accustomed to working with uncertainty doesn't freeze up when that uncertainty shows up uninvited. They already know how to ask the right questions, build hypotheses, and validate them quickly.

Summary

R&D is not an anomaly in the production process that needs to be "survived." It's a natural and inevitable part of it, especially in industries where the technological landscape changes faster than you can update your documentation. Trying to squeeze research tasks into the framework of a linear production pipeline is one of the most expensive mistakes a business can make.

Key principles to remember:

Acknowledge R&D tasks as a separate category - don't hide behind generic processes
Accept uncertainty as a working factor, not a hostile anomaly
Invest in people - R&D is done by people, not processes
Prepare a Plan B and define kill-criteria in advance
Measure real progress, not the illusion of progress
Use AI as an accelerator, not as a substitute for thinking

And above all: R&D is about managed risk. And the ability to manage risk is what separates engineering from gambling.

What's Actually Wrong with Web Components?

Alex M — Tue, 14 Apr 2026 20:05:49 +0000

Short answer -- nothing fundamental. Web Components are a set of browser-native APIs that solve real problems in web development. They let you do things that are either impossible or unnecessarily complex without them. And when a task goes slightly beyond standard requirements and needs a creative approach, Custom Elements give you a level of flexibility that framework-specific abstractions simply don't offer.

Yet somehow, the narrative online keeps cycling back to "Web Components are a failure". I've been using these APIs in production for years -- starting from the early Polymer drafts, through the spec evolution, and up to modern Lit and my own library Symbiote.js. Over that time I've shipped large real-time dashboards with graph data flowing through WebSockets, collections of hundreds of thousands of items, and plenty of simpler projects. So I have opinions, and they come from practice.

One thing before we start: every engineering decision is a trade-off. There are no perfect technologies (if someone claims otherwise, they're selling something). When evaluating any tool, we weigh pros and cons. The existence of cons doesn't automatically invalidate the pros. Each trade-off has a concrete cost. If that cost is acceptable for your case -- the technology deserves serious consideration.

Myths That Won't Die

Some criticisms of Web Components are simply inaccurate.

"You can only pass strings to Web Components." This one references attributeChangedCallback and suggests JSON-parsing attribute values. But HTML attributes are part of HTML markup -- they're always strings, for any element, not just custom ones. If you need to pass complex data to a component at runtime, use property setters, getters, or Proxies. Standard JS. Every modern framework can set properties on DOM elements through their template syntax, and plain DOM API works just as well. Confusing attributes (HTML serialization) with properties (JS runtime) is a fundamental misunderstanding of how the browser works.

"Shadow DOM isolation is a problem." Shadow DOM isolates a component's internals from external CSS. That's its purpose. If you don't need isolation -- don't use Shadow DOM. Custom Elements and Shadow DOM are independent APIs. You can use Custom Elements with Light DOM just fine, and many production component libraries do exactly that. When you do want Shadow DOM, you still have CSS custom properties (design tokens) and ::part() for controlled styling from outside. Adopted Style Sheets handle shared styles across instances without duplication -- supported in all modern browsers.

"The lifecycle starts at DOM attachment." It doesn't. A Custom Element's lifecycle starts at the constructor. You can create elements in memory, manipulate them within a DocumentFragment through standard DOM API, and only attach them when ready. This is fundamental to virtualization patterns.

Nuances Worth Understanding

These aren't dealbreakers, but they're real and worth knowing about.

Global name registry. Custom element names share a single flat namespace per document. This is true. The fix is simple: use prefixes (or postfixes) in naming conventions. If a collision happens, the browser throws a clear error at registration time, not a silent failure. You can catch it in integration tests. You can subclass and re-register. Flat namespaces are one of the oldest patterns in computing -- from object keys to domain names. It works fine with minimal discipline.

connectedCallback / disconnectedCallback re-firing. Moving an element from one DOM location to another triggers both callbacks. This is by design -- the element literally disconnects and reconnects. A single boolean flag on first initialization handles this. It's a one-line solution for a rarely-encountered scenario. The ability to track DOM lifecycle from inside the component is one of the most powerful features of the standard.

No de-registration. Once registered, a custom element stays registered for the life of the document. True. The browser stores a reference to the constructor. Memory cost is negligible, performance impact is zero. De-registration would actually create harder problems: what happens to existing instances? Which class is active? The current behavior is predictable.

The Real Gotcha

There is one aspect that genuinely surprises newcomers. When the browser parses HTML in a streaming fashion, connectedCallback fires as soon as it encounters the opening tag -- before the element's children are parsed. DOM queries for child elements return nothing at that point.

The fix: load your script with defer or type="module". Both ensure execution after parsing completes. In Symbiote.js, there's a dedicated renderCallback lifecycle hook that guarantees child DOM access.

The inverse scenario exists too: you might get a reference to an element before its class is registered. customElements.whenDefined(name) returns a Promise for exactly this case.

This async behavior can be confusing if you're not aware of it. But it's the same category as losing this context in callbacks -- once you know the pattern, you handle it automatically.

AI Tooling and Core Standards

Here's an angle that rarely comes up in Web Components discussions. Modern AI coding assistants -- LLMs, autocomplete models, chat-based agents -- have been trained on massive amounts of web platform documentation. The DOM API, Custom Elements, Shadow DOM, HTML templates, CSS custom properties: these are extensively documented on MDN, in W3C specs, and across millions of tutorials and StackOverflow answers.

When you write a Custom Element using standard APIs, AI tools understand what you're doing. They can generate connectedCallback logic, suggest attribute observation patterns, autocomplete CSS custom property usage. The entire surface area of these APIs is well-represented in training data.

Framework-specific abstractions accumulate across versions. React Hooks have different idioms than class components. Angular standalone components differ from NgModule-based patterns. Vue 2 Options API vs. Vue 3 Composition API. Each version shift creates a window where AI models produce outdated or mixed-version code.

Web Components API has been stable. connectedCallback works today exactly as it did years ago. That stability maps directly to reliable AI assistance.

SEO and Shadow DOM

Search engines have improved their ability to process JavaScript-rendered content, but there's still a practical distinction. Content in Light DOM is part of the main document tree -- crawlers parse it the same way they parse any HTML. Content inside Shadow DOM sits in a separate tree.

Google's crawler can execute JavaScript and reach into Shadow DOM in many cases, but other search engines and social media parsers (OpenGraph scrapers, link previews) often cannot. If your page content, headings, structured data or link anchors live inside Shadow DOM, you're limiting their visibility.

The practical approach: use Custom Elements without Shadow DOM for content-bearing components or place such content in Light DOM slots. Keep your semantic HTML, headings and paragraphs in Light DOM where every crawler can reach them. Reserve Shadow DOM for UI widgets that don't carry indexable content -- toolbars, media players, interactive controls.

This is a real architectural advantage. You get component encapsulation at the JS level (Custom Elements), semantic HTML for crawlers and accessibility tools, and styling flexibility through the cascade -- all without a build step that transforms your markup beyond recognition.

What Only Web Components Can Do

Enough about trade-offs. What are the capabilities that no framework can replicate?

HTML-to-runtime binding at the node level.

Frontend developers tend to forget that HTML is the foundation. A page starts as a text document, often assembled server-side, where no JS abstractions exist yet. Custom tags in that document are native markers for your JS integration. They provide natural mounting points and an XML-compatible structure that works with standard HTML -- no proprietary template syntax, no vendor-specific compilation step. A server written in any language can emit <my-widget data-id="42"></my-widget> without knowing anything about your frontend stack. Try doing that with a React component.

For example, this native binding radically simplifies SSR (Server-Side Rendering). Look at the architectural overhead required to hydrate a Next.js or Nuxt application: serialization boundaries, matching virtual DOM trees, and shipping a heavy hydration engine. Compare that to the Symbiote.js SSR approach: the server simply produces standard HTML with custom tags and declarative attributes. When it reaches the browser, the Custom Element initializes, detects the pre-rendered children, and attaches its logic directly to the existing DOM nodes. There is no virtual tree to reconcile -- the HTML structure itself tells the runtime exactly what to do. No mismatch errors by design, no extra bundle size.

Atomic lifecycle management.

Custom Elements let you know, from inside the component, when it enters or leaves the DOM. Component appeared -- you know. Component removed -- you know. Regardless of what created it or what triggered a re-render.

Without Custom Elements, lifecycle management is always external. You need a runtime to search the DOM for integration points, decide when to initialize, and decide when to clean up. That runtime has to be loaded, parsed, and executed before any component becomes alive. In React, this is ReactDOM scanning for a root element and owning the entire subtree. In Angular, it's the platform bootstrap and zone.js. These aren't free -- they add tens of kilobytes of code just to answer the question "when does this piece of UI exist?"

Custom Elements answer that question natively. connectedCallback fires when the element enters any document -- a React app, a static HTML page, a server-rendered document, an email template rendered in an iframe. No library runtime required. No teardown logic to wire up from outside. The browser tells the component directly, and the component handles itself.

A universal component model.

Custom Elements are the base layer that everything else can build on. Libraries like Lit or Symbiote.js add convenience (reactive state, templating, etc). UI kits build design systems. Complex widgets encapsulate business logic. Micro-frontends compose applications from independent deployables. All of these benefit from a standardized component API with built-in documentation on MDN, universal browser support, and zero lock-in. A Custom Element works inside React, Angular, Vue, Svelte, plain HTML pages -- or alongside other Custom Elements. No wrapping, no adapters, no compatibility layers for the most cases.

Unmet Expectations

A lot of frustration with Web Components comes from hoping they'd be a native, highly-optimized replacement for React or Angular. They're not meant to be. The browser gives you a low-level component primitive. What you build on top of it is up to you.

That mismatch between expectation and reality doesn't make the standard bad. It means the standard solves a different problem than people assumed. And the problem it does solve -- a universal, framework-agnostic component model with native lifecycle tracking -- has no viable alternative in any library or framework today.

If you want to see these ideas in practice, check out Symbiote.js -- a lightweight library built on Custom Elements that adds very flexible reactive state and data binding while keeping you close to the platform.

Lit vs Symbiote.js

Alex M — Mon, 23 Mar 2026 15:54:47 +0000

Hi, DEV!

If you work with Web Components, you've probably heard of Lit. It's the most popular library in this space, maintained by the Google team, and it does its job well. So why would I write an article about an alternative?

Because Symbiote.js takes some fundamentally different architectural decisions - and even if you personally never plan to use it, some of these approaches are genuinely interesting and might change how you think about component design. I'm Alex, the maintainer of Symbiote.js, and I want to walk you through the key differences, being as fair as possible to both sides.

Lit and Symbiote.js both produce standard Custom Elements. They can coexist on the same page - alongside raw native web components - without any conflicts. This isn't "pick one forever"; you could literally use both in the same project.

At a Glance

	Symbiote.js 3.x	Lit 3.x
Core size (brotli)	~5.9 kb	~5.1 kb
Dependencies	0 runtime	0 runtime
Shadow DOM	Opt-in	Default
SSR	Built-in	Experimental (`@lit-labs/ssr`)
Routing	Built-in	Not included
State management	Built-in	Separate (`@lit/context`)
Build step	Not required	Not required

Both are lightweight. Lit's core is ~1 kb smaller, but Symbiote's 5.9 kb already includes state management, list rendering (Itemize API), computed properties, and exit animations - things that in Lit require additional packages.

Templates: the Biggest Difference

This is where the two libraries diverge most. And honestly, this is the part I find most interesting from an architectural standpoint.

What Lit Does

In Lit, templates are JavaScript expressions bound to this:

render() {
  return html`
    <p>${this.message}</p>
    <button @click=${this.onClick}>Click</button>
  `;
}

The html tag returns a TemplateResult - a special object processed by Lit's rendering pipeline. Templates live inside render(), they reference this, and they re-evaluate on every update cycle.

What Symbiote Does Differently

Symbiote templates are plain HTML strings. They don't reference this at all:

MyComponent.template = html`
  <p>{{message}}</p>
  <button ${{onclick: 'onClick'}}>Click</button>
`;

The html function produces an actual HTML string with bind= attributes. It's standard template literal syntax - no special objects, no rendering pipeline.

Why does this matter?

Templates become portable. Since a template is just an HTML string, it can live in a separate file, arrive from an API, or sit in the HTML document itself. The same component can even swap templates at runtime via use-template:

<my-component use-template="#compact-view"></my-component>
<my-component use-template="#detailed-view"></my-component>

Templates can be pure HTML with zero JavaScript:

<div bind="textContent: myProp"></div>
<button bind="onclick: handler; @hidden: !flag">Click me</button>

This bind attribute is all you need. A CMS editor, a no-code tool, or a server-side template engine can generate this markup - the component will find the bindings and wire everything up. The template is not coupled to any execution context.

Server-Side Rendering: One Module vs Three Packages

This is another area where the approaches differ significantly.

Lit SSR

Lit's SSR lives in @lit-labs/ssr (experimental). To get it working, you need:

@lit-labs/ssr - the server renderer
@lit-labs/ssr-client - client-side hydration support
@lit-labs/ssr-dom-shim - DOM polyfills for Node.js

And there are rules: lit-element-hydrate-support.js must load before the lit module. Server and client renders must produce identical output - mismatches cause errors. Lit SSR doesn't handle async work natively. The output contains  comment markers for template re-association.

Symbiote SSR

One module. No hydration mismatches. No comment markers:

import { SSR } from '@symbiotejs/symbiote/node/SSR.js';

await SSR.init();
await import('./my-app.js');

let html = await SSR.processHtml('<my-app></my-app>');
SSR.destroy();

The trick is architectural: the server writes bind= attributes into the HTML (clean, standard HTML - no framework markers). The client reads those attributes and attaches reactivity. There's no diffing step, so there's nothing to mismatch. It's impossible by design.

Set isoMode = true on a component and it figures out what to do: if server content exists, hydrate; if not, render from template. One flag, no "use client" directives, no conditional logic:

class MyComponent extends Symbiote {
  isoMode = true;
  count = 0;
  increment() { this.$.count++; }
}

MyComponent.template = html`
  <h2 ${{textContent: 'count'}}>0</h2>
  <button ${{onclick: 'increment'}}>Click me!</button>
`;

This exact code runs on the server and the client. Streaming is supported too via SSR.renderToStream().

Data Management: Decorators vs Prefix Tokens

The Lit Way

Lit uses decorators for reactive properties:

class MyEl extends LitElement {
  @property() name = '';
  @state() _count = 0;
}

For data sharing across components, there's @lit/context - a separate package implementing the W3C Context Community Protocol:

// Provider
@provide({context: myContext})
@property() data = {};

// Consumer  
@consume({context: myContext})
@property() data;

For anything global, you bring your own state management (Redux, MobX, signals, etc.).

The Symbiote Way

Symbiote has a built-in layered data context system. Each layer is identified by a prefix token in the template:

Token	Context	Example
(none)	Local state	`{{count}}`
`^`	Parent, pop-up (DOM tree walk)	`{{^parentTitle}}`
`*`	Shared (by `ctx` attr)	`{{*sharedCount}}`
`APP/`	Named global	`{{APP/user}}`
`--`	CSS custom property	`{{--label}}`
`+`	Computed	`'+sum': () => ...`

Here's what I find genuinely elegant about this: the template is the wiring. A component can bind to an external data context without a single line of component logic - just a prefix in the template. No decorator setup, no provider/consumer classes, no subscription boilerplate. Write {{APP/user}} and it's connected. Write {{^parentAction}} and it walks up the DOM to find the handler.

For example, shared context between components:

<upload-btn ctx="gallery"></upload-btn>
<file-list  ctx="gallery"></file-list>
<status-bar ctx="gallery"></status-bar>

class UploadBtn extends Symbiote {
  init$ = { '*files': [] }
  onUpload(newFile) {
    this.$['*files'] = [...this.$['*files'], newFile];
  }
}

class FileList extends Symbiote {
  init$ = { '*files': [] }
}

Three components, one shared *files state. No parent orchestrator, no event bus, no prop drilling. Just ctx="gallery" in the markup.

Shadow DOM: Default vs Opt-In

Lit uses Shadow DOM by default. Every component gets style isolation. To opt out, you override createRenderRoot() { return this; } - it works, but it's clearly an escape hatch.

Symbiote flips this: Light DOM is the default. Shadow DOM is opt-in, per component. Set renderShadow = true or define shadowStyles - shadow root is created. Don't - and your component renders in Light DOM.

This is more than a preference. For widgets embedded in third-party pages, mandatory Shadow DOM means the host application can't restyle your component - even when they need to. An opt-in model lets you choose isolation where it's valuable and openness where it's not.

Symbiote supports both simultaneously on the same component: rootStyles for Light DOM and shadowStyles for Shadow DOM.

CSS as a Data Source

This is probably the most unusual Symbiote feature. Components can read CSS custom properties directly into their reactive state:

my-widget {
  --label: 'Upload files';
}

@media (max-width: 768px) {
  my-widget {
    --label: 'Upload';
  }
}

MyWidget.template = html`
  <button>{{--label}}</button>
`;

CSS custom properties are read once on initialization - they set the starting state. Since browsers don't provide a universal signal for custom property changes, runtime updates require calling this.updateCssData() explicitly (for example, from a ResizeObserver or after toggling a class). It's not fully automatic, but the initialization alone is already powerful: different CSS classes, media queries, or host stylesheets can set different starting configurations for the same component - all without JavaScript.

You can even assign shared context groups via CSS:

.gallery-section { --ctx: gallery; }

Lit supports CSS custom properties crossing shadow boundaries, but it doesn't have a mechanism to use CSS values as component state.

Build Tooling

Both libraries technically work without a build step. But in practice, Lit's developer experience is built around TypeScript decorators (@property(), @state(), @customElement()). The docs, the examples, most community code - all assume a TypeScript compiler.

Symbiote uses standard JavaScript throughout - ESM, class fields, template literals. No decorators, no transpilation. It supports importmap-based dependency sharing with CDN imports:

<script type="importmap">
{
  "imports": {
    "@symbiotejs/symbiote": "https://esm.run/@symbiotejs/symbiote"
  }
}
</script>
<script type="module" src="./my-app.js"></script>

No bundler, no node_modules, works in the browser directly. When you need a bundler for production - esbuild, Rollup, or any standard tool will do.

What Lit Does Better

I said I'd be fair, so:

Community and ecosystem. Lit has a large, active community, extensive documentation, and wide adoption. Google uses it internally. If you need Stack Overflow answers and community plugins, Lit has far more momentum.
Maturity. Lit has been around longer (through Polymer → LitElement → Lit transitions) and has gone through more production battle-testing.
Slightly smaller core. ~5.1 kb vs ~5.9 kb - though the practical difference evaporates once you add context, lists, and routing to a Lit project.
Slightly faster initial render. Symbiote needs to look up the DOM environment after a component connects - reading context from its position in the tree, resolving pop-up bindings, checking CSS data. This makes its initial render a bit slower than Lit's. The gap is not dramatic, but it's noticeable in benchmarks. Once rendered, both libraries perform comparably for updates.

Developer Experience

Both libraries use html tagged template literals, so standard IDE syntax highlighting for HTML-in-JS works equally well in both. Lit has a dedicated VS Code plugin (lit-plugin) that adds type checking and completion inside templates.

Symbiote takes a different approach: instead of IDE tooling, it ships with a built-in devMode runtime messaging system. Enable it and you get warnings about broken bindings, missing context properties, and type mismatches - directly in the console, at the moment they occur. It's not an IDE plugin, but it catches the same class of problems at runtime.

Should You Try It?

If you're building widgets that embed into any environment, micro-frontends without framework coupling, or component libraries that need to work in React, Angular, Vue, and plain HTML - Symbiote's architectural choices solve real problems.

If you're building a single-stack application where all components live in one codebase and you want maximum community support, Lit is a perfectly solid choice.

And remember: they produce standard Custom Elements. You can mix Lit, Symbiote, and raw native web components on the same page without any conflicts. The choice isn't exclusive.

Even if you don't plan to use Symbiote.js right now, some of the ideas - templates as portable HTML strings, one-prefix data binding across contexts, CSS as a data source - are worth knowing about. Different approaches expand how we think about component architecture. And if any of this was interesting, a ⭐ on GitHub really helps us Open Source developers keep going.

Links:

GitHub
Documentation
Full comparison doc
Live Examples
JSDA-Kit - companion all-in-one tool with SSR, SSG, bundling, live serving and import maps generation

Symbiote.js - Superpower For Web Components

Alex M — Tue, 17 Mar 2026 13:55:24 +0000

Hi, DEV!

My name is Alex, and I'm the maintainer of Symbiote.js - a library for building UI components and isomorphic applications using the latest web standards.

Today I'm going to talk about our important major update - version 3.

The Idea in Few Words

Symbiote.js is a lightweight (~5.9 kb brotli) wrapper around Custom Elements that adds reactivity, templates, and data layer management. No Virtual DOM, no special compiler, no mandatory build step - you can plug components right from a CDN.

But the most important thing is not the size or the absence of dependencies. The main thing is loose coupling. The entire design of the library is built around a crucial idea: a component can beforehand not know who configures it, what surrounds it, and in what context it is used. Configuration and data can come from HTML markup, from CSS, from a parent component in the DOM tree, or from a dedicated data context - and the component simply checks what it's ready to bind to, finding itself in a specific place at a specific time, and enters into a symbiosis.

Another important point: I know many developers are afraid to get involved with Shadow DOM. Well, in Symbiote.js, Shadow DOM is an optional feature. You can freely apply the most conservative approaches to styling, use the isolation layer only where necessary, and implement any hybrid scheme with maximum flexibility and efficiency.

Why Loose Coupling is Important

Loose coupling is not just an abstract architectural principle. These are concrete scenarios where hard dependencies between components create real problems:

Embeddable widgets. Your component has to work on someone else's site - and you don't control its stack, CSS, and build process. If a widget requires a specific framework, provider, or build pipeline, you will complicate your life and the lives of others. If it gets configured via HTML attributes or CSS, it will easily fit anywhere.
Micro-frontends. Several teams are building different parts of the same application. This works much better when components communicate via declarative contracts (HTML attributes, CSS variables, named data contexts) rather than direct JS imports and shared memory objects.
CMS and no-code platforms. A content manager or designer configures a component via HTML markup or CSS without touching JavaScript. This is possible only if the component knows how to get configuration from these sources.
Multi-team development. One team makes a design system, another - product features. The fewer explicit dependencies between modules, the fewer merge conflicts.
Gradual migration. You can't rewrite everything at once. Symbiote allows you to embed new components into an existing React, Angular, Vue, Svelte or jQuery application - without wrappers, adapters, and double renders, organizing data exchange seamlessly.
Runtime-dedicated modules without conditional logic. Since all binding in Symbiote.js is key-based (text strings like 'app/theme', '*files', '^onAction'), you can create modules that are specific to a runtime environment (server, browser, worker) without wrapping them in if/else blocks. For example, the server imports node-imports.js and the browser imports browser-imports.js - both register components that bind to the same named context keys. Modules don't import each other, don't check typeof window, and don't share objects in memory. They connect indirectly, through matching data keys. This is composition without coupling.

Symbiote.js is designed so that all these scenarios work out of the box. Below are the specific mechanisms.

Everything described below can be seen in action in the reference application with a live demo - a universal app with SSR streaming, SPA routing, declarative server-side Shadow DOM, localization, and basic patterns for connecting to reactive data. No bundlers, no build pipelines - pure ESM + import maps.

You can also see examples and play with live code without installation here: Live Examples

Configuration outside JavaScript

Most UI libraries dictate a similar and familiar way of configuring components - via props or attributes passed by a parent JS component. Symbiote.js expands this model: components can be configured from multiple data sources. All of them work equally transparently.

Describing bindings in HTML attributes

Any Symbiote.js template can be written as regular HTML that knows absolutely nothing about the JavaScript context:

<div bind="textContent: myProp"></div>
<button bind="onclick: handler; @hidden: !flag">Click me</button>

The bind attribute is exactly the declarative binding of an element to the reactive state of the component. You can write it by hand in an HTML file, generate it on the server, or create it in any template engine. The component's JavaScript code doesn't care - it will see bind in the DOM, substitute data, and connect handlers.

The html helper in JS files simply generates these attributes from a more convenient syntax:

html`<button ${{onclick: 'handler'}}>Click me</button>`
// → <button bind="onclick: handler">Click me</button>

The template can be stored wherever and however you like: in a JS file, in an HTML document, on the server. It is not tied to the execution context.

Configuration from CSS

This is perhaps the most unusual feature. Components can read CSS variables to initialize their state:

my-widget {
  --label: 'Upload files';
}

@media (max-width: 768px) {
  my-widget {
    --label: 'Upload';
  }
}

class MyWidget extends Symbiote {...}

MyWidget.template = html`
  <button>{{--label}}</button>
`;

The component uses --label from CSS. Change the theme - parameters change. A media query triggers - an adaptive template is applied. Switch a class on a container - new configuration.

Why do this? Advanced themes, responsiveness without additional JS window listeners, localization, or simply passing parameters to embedded widgets from a host app's stylesheet.

External templates

A component can use a template defined anywhere in the HTML document:

class MyComponent extends Symbiote {
  allowCustomTemplate = true;
}

<template id="custom-view">
  <h1>{{title}}</h1>
  <p>{{description}}</p>
</template>

<my-component use-template="#custom-view"></my-component>

This is useful when the component provides only data and handlers, and different markup variants form different representations in the DOM.

Component communication without prop drilling

Symbiote.js has several mechanisms for component communication that do not require explicit passing of data from parent to child or between instances.

Shared context (`ctx` + `*`)

Components can be grouped via an HTML attribute - same as the native HTML name attribute groups radio buttons:

<upload-btn ctx="gallery"></upload-btn>
<file-list  ctx="gallery"></file-list>
<status-bar ctx="gallery"></status-bar>

class UploadBtn extends Symbiote {
  init$ = { '*files': [] }
  onUpload(newFile) {
    this.$['*files'] = [...this.$['*files'], newFile];
  }
}

class FileList extends Symbiote {
  init$ = { '*files': [] }
}

Three components, one shared data context gallery and a *files field. Without a shared parent component, without prop drilling, without an event bus. Put ctx="gallery" in the markup - components are linked, done.

The group can also be assigned via CSS:

.gallery-section {
  --ctx: gallery;
}

<div class="gallery-section">
  <upload-btn></upload-btn>
  <file-list></file-list>
</div>

This is layout-driven grouping: the visual container defines the logical relationship between components.

An obvious use case: a complex widget where, for example, the file upload interface and the upload progress bar are in different parts of the host application's DOM tree.

Pop-up binding (`^`)

A component can access the properties of the nearest ancestor in the DOM tree - without imports, without knowing about the specific parent:

class ToolbarBtn extends Symbiote {}

ToolbarBtn.template = html`
  <button ${{onclick: '^onAction'}}>{{^label}}</button>
`;

^onAction - Symbiote will go up the DOM and find the first component that has onAction registered in its state. Like a CSS cascade, only bottom-up, for data and handlers.

This allows creating reusable "dumb" components that adapt to the context of use.

Named data contexts

For situations where global or feature-dedicated state is needed, 3 lines of code is all it takes:

import { PubSub } from '@symbiotejs/symbiote';

// app/app.js - register once
PubSub.registerCtx({
  darkTheme: true,
  toDoList: [],
}, 'app');

In any component:

// Access:
this.$['app/darkTheme'] = false; // write
console.log(this.$['app/darkTheme']); // read

// Subscription:
this.sub('app/toDoList', (items) => {
  console.log('Tasks:', items);
});

Without a store, without a provider, without useContext.

SSR and Universal Components

The killer feature of version 3 is server-side rendering. One flag, one code, one component, works everywhere, on the server and on the client:

class MyComponent extends Symbiote {
  isoMode = true;
  count = 0;
  increment() {
    this.$.count++;
  }
}

MyComponent.template = html`
  <h2 ${{textContent: 'count'}}></h2>
  <button ${{onclick: 'increment'}}>Click me!</button>
`;
MyComponent.reg('my-component');

isoMode = true - if there is server content, the component hydrates it. If not, it renders the template from scratch. Without conditions, without 'use client'.

On the server:

import { SSR } from '@symbiotejs/symbiote/node/SSR.js';

await SSR.init();
await import('./my-app.js');
let html = await SSR.processHtml('<my-app></my-app>');
SSR.destroy();

Hydration mismatches are impossible in principle, by design - there is no diffing. The server writes bind= attributes into the markup, the client reads them and attaches reactivity. No kilometer-long JSONs for hydration.

Components with Shadow DOM are also supported in SSR via the Declarative Shadow DOM (DSD) mechanism.

Static Site Generation (SSG)

The same SSR mechanism works for static generation - SSR.processHtml() returns a string that you simply write to a file:

import { SSR } from '@symbiotejs/symbiote/node/SSR.js';
import fs from 'node:fs';

await SSR.init();
await import('./my-app.js');

let html = await SSR.processHtml(mainTemplate);
fs.writeFileSync('dist/index.html', html);

SSR.destroy();

No separate SSG framework required. The reference app uses exactly this approach - npm run ssr generates a fully rendered dist/index.html that can be opened directly in a browser or deployed to any static hosting (e.g. GitHub Pages). Client-side JS takes over from there and the app becomes an SPA.

Fun fact: recently I came across yet another heavily upvoted comment on Reddit claiming that Custom Elements are a purely browser API and that rendering web components on the server is impossible. So, friends, here we are easily doing the impossible. In general, web components as a group of standards are surrounded by many myths and misconceptions - and Symbiote helps fight those misconceptions.

What else is in the new version?

Computed properties - derived state properties with dependency tracking.
Exit animations - CSS enter and exit animations using @starting-style and [leaving].
SPA Router - an optional module with path-based URLs, parameters, guards, and lazy loading.
Keyed itemize - key-based reconciliation for lists, running multiple times faster for immutable data.
CSP & Trusted Types - out-of-the-box compatibility with strict CSP headers.
Dev mode - verbose warnings about problems in bindings and hydration.

Bundle Size

Size is not just a badge number. It is concrete loading time for your real users.

Library	Minified	Gzip	Brotli
Symbiote.js (core)	18.9 kb	6.6 kb	5.9 kb
Symbiote.js (full, with AppRouter)	23.2 kb	7.9 kb	7.2 kb
Lit 3.3	15.5 kb	6.0 kb	~5.1 kb
React 19 + ReactDOM	~186 kb	~59 kb	~50 kb

In the 5.9 kb base bundle, Symbiote gives you reactivity, data contexts, dynamic lists, animations, computed properties, hydration - all the most important stuff. For comparable functionality in Lit or React, you'll need additional packages. And I won't even mention SSR.

Summary

Symbiote.js is a library that significantly expands the capabilities of web components while staying close to the platform and standards. Configuration from CSS, binding via HTML attributes, data contexts without direct links between components in JS, minimal boilerplate, optimal DX. Components don't know about each other, but work together - on the client and on the server.

If you need widgets that embed into any environment, micro-frontends without extra hassle, complex hybrid framework-agnostic applications, or a reusable component library for different projects - take a look at Symbiote.js.

Even if you don't plan to use the library itself right away, but saw some interesting approaches - give the project a star, it really helps us Open Source developers not to lose heart.

JavaScript Distributed Assets - simple but powerful

Alex M — Thu, 11 Dec 2025 17:10:46 +0000

Here's the idea: take standard JavaScript modules (ESM) and turn them into direct endpoints for generating any text-based web assets — HTML files, CSS, SVG, or even JSON and Markdown — using a simple file naming convention with a default export as a string (JavaScript Template Literal). Sounds super simple and kinda like PHP, right? But what does this actually give us?

Let's dive into why JSDA (JavaScript Distributed Assets) might just be the thing that makes web development "great again" after a thousand wrong turns.

Basic Example

// Create a file called index.html.js

// Import a method to access data (optional):
import { getPageData } from './project-data.js';

// Fetch the necessary data (optional):
const pageData = await getPageData();

// Export the final HTML document:
export default /*html*/ `
<html>
<head>
  <title>${pageData.title}</title>
</head>
<body>
  <h1>${pageData.heading}</h1>
</body>
</html>
`;

This will automatically transform into plain HTML:

<html>
<head>
  <title>Page Title</title>
</head>
<body>
  <h1>Page Heading</h1>
</body>
</html>

Conventions

JSDA is all about following these simple conventions:

To define the output file type, use the pattern *.<type>.js, for example my-page.html.js, styles.css.js, image.svg.js, etc.
To define static generation entry points, use the pattern index.<type>.js, for example index.html.js, index.css.js, index.svg.js, etc.
A JSDA file must be a standard ESM module containing a default export as a string (export default '...')
The directory structure of output files mirrors the source structure (we get file-system-based routing out of the box):

src/
├── index.html.js          → dist/index.html
├── styles/
│   └── index.css.js       → dist/styles/index.css
└── assets/
    └── logo/
        └── index.svg.js   → dist/assets/logo/index.svg

JSDA as an Evolution of JAMStack

Simplifying things is actually pretty hard. When we strip away the excess, it feels like we might be missing something important. But in practice, it's often the opposite — extra elements in a system make it less stable and more vulnerable. Simplification is an art that might seem trivial in hindsight. But it really isn't.

When Netlify CEO Matt Biilmann proposed the JAMStack architectural concept back in 2015, that's exactly what he did — he simplified. Think about it: why do we need a CMS and a database, with all their vulnerabilities and server resource consumption, if the server ultimately just needs to serve static files? Why does a server need complex logic if we can generate the necessary assets at build time? Why not serve all static files as fast, efficiently, and securely as possible through a CDN, minimizing load and dramatically improving scalability? And most importantly—why overcomplicate things when we can achieve better results by simplifying? A pretty counterintuitive way of thinking at the time, but absolutely right.

However, in my opinion, JAMStack is too general a concept — a set of high-level recommendations that barely touch on implementation details and don't propose specific solutions to tasks that can have their own complexity. Many people still believe JAMStack has significant limitations, but that's not true — we can combine it with any other practices in any arbitrary combinations.

JSDA follows the same philosophy but with more technical substance. We take the native capabilities of the web platform (Node.js + browser) and existing standards, and without adding any new redundant entities, we solve problems that traditionally require much bulkier solutions — all while not limiting ourselves in terms of possibilities.

Hybrid Approach

If JAMStack is mostly about SSG (Static Site Generators), then JSDA plays on both fields — as an architecture applicable for generating both static and dynamic content. On top of that, JSDA doesn't restrict you from using any auxiliary technologies if needed.

Traditionally, we distinguish the following web application modes:

SPA (Single Page Application) – everything is controlled by client-side JavaScript, the DOM tree is fully created dynamically on the client.
SSR (Server Side Rendering) – the server pre-renders the page, which is then "hydrated" on the client with JavaScript.
SSG (Static Site Generation) – generating HTML files at build time, which are then served as static content.
Dynamic page generation – the server generates HTML files on request, and the result can be cached.

These approaches don't exclude each other. Each has its strengths and weaknesses, but they can be combined effectively. In complex scenarios, for instance, documentation pages or promo materials can be fully static, product pages can be partially pre-rendered on the server and partially contain dynamic widgets (f.e. shopping cart), while a user's dashboard can be fully implemented as an SPA.

And the JSDA stack is exactly suited for such complex scenarios, while remaining simple and minimalistic itself.

Async Operations (Top Level Await)

According to the ESM specifications, modules are asynchronous and support top-level async calls — Top level await. This means that when generating assets, we can make requests and fetch data across the entire chain of imports and dependencies. We can access databases, external APIs, the file system, and so on. And here's the cool part: we don't have to deal with async complexity ourselves — it's "masked" behind standard ESM mechanisms. By simply importing a dependency, we can be sure that all its data is fetched during module resolution. In my view, this is a very powerful yet underrated platform capability.

Caching

According to the standard, ESM modules are automatically cached in runtime memory upon resolution. This makes the generation process more efficient by avoiding redundant operations when reusing a module. If, on the other hand, you want to control caching and get fresh data from the import chain, you can use unique module identifiers (addresses) during import, like this:

const data = (await import(`./data.js?${Date.now()}`)).default;

You can also use query parameters accessible inside the module via import.meta, for example:

const userId = import.meta.url.split('?')[1];
const data = (await import(`./user-data.js?id=${userId}`)).default;

String Interpolation

Another cool thing we get "for free" is the ability to compose complex result strings. This native "templating engine" lets you build any complex markup or structure from components, reuse them, and inject any logic during generation. Against this backdrop, the trendy server components from the React and Next.js ecosystem look like overcomplicated nonsense.

SSR and Web Components

But how do we bring markup to life on the client? How do we bind DOM elements to data and handlers? We've got everything we need for this too — no need to invent anything extra. The solution is a standard group of specifications known as Web Components. Let me show you a simplified example of how this works.

On the server, we create the following markup:

import getUserData from './getUserData.js';

let userId = import.meta.url.split('?user-id=')[1];
const userData = await getUserData(userId);

export default /*html*/ `
<my-component user-id="${userId}">
  <div id="name">${userData.name}</div>
  <div id="age">${userData.age}</div>
</my-component>
`;

On the client, we register a CustomElement:

// getUserData function can be isomorphic
import getUserData from './getUserData.js';

class MyComponent extends HTMLElement {
  connectedCallback() {
    this.userNameEl = this.querySelector('#name');
    this.userAgeEl = this.querySelector('#age');
    this.userId = this.getAttribute('user-id');

    // Refine and bind data if needed
    getUserData(this.userId).then((data) => {
      this.userNameEl.textContent = data.name;
      this.userAgeEl.textContent = data.age;
    });
  }
}

window.customElements.define('my-component', MyComponent);

That's it! And no horrible __NEXT_DATA__ like in Next.js. The identifier for the "hydrated" node is our custom tag, which easily takes control of its DOM section. The browser handles everything through the CustomElements lifecycle. Remember — Web Components don't necessarily have to include Shadow DOM.

But what if there are lots of components with their own nested hierarchies? That's also simple—here's another example.

This time, a simple recursive function will draw us structured HTML:

import fs from 'fs';

/**
 * 
 * @param {String} html source HTML 
 * @param {String} tplPathSchema component template path schema (e.g., './ref/wc/{tag-name}/tpl.html')
 * @param {Object<string, string>} [data] rendering data
 * @returns {Promise<String>} rendered HTML
 */
export async function wcSsr(html, tplPathSchema, data = {}) {
  Object.keys(data).forEach((key) => {
    html = html.replaceAll(`{[${key}]}`, data[key]);
  });

  const matches = html.matchAll(/<([a-z]+[\w-]+)(?:\s+[^>]*)?>/g);
  for (const match of matches) {
    const [fullMatch, tagName] = match;
    let tplPath = tplPathSchema.replace('{tag-name}', tagName);
    let tpl = '';

    // Support component templates in different formats:
    if (tplPath.endsWith('.html')) {
      tpl = fs.existsSync(tplPath) ? fs.readFileSync(tplPath, 'utf8') : '';
    } else if (tplPath.endsWith('.js') || tplPath.endsWith('.mjs')) {
      try {
        tpl = (await import(tplPath)).default;
      } catch (e) {
        console.warn('Template not found for ', tagName);
      }
    }

    if (tpl) {
      if (!tpl.includes(`<${tagName}`)) {
        tpl = await wcSsr(tpl, tplPathSchema, data);
      } else {
        tpl = '';
        console.warn(`Endless loop detected for component ${tagName}`);
      }
    }
    html = html.replace(fullMatch, fullMatch + tpl);
  }

  return html;
}

For more fully-fledged work with Web Components, you can use any popular library. Personally, I use Symbiote.js, as it's adapted for working with execution-context-independent HTML templates (and more).

File Transformations

Converting JSDA files to text-based web assets is clear enough, but here's the next question: how do we represent regular text files in JSDA format?

Super easy:

import fs from 'fs';

export default fs.readFileSync('./index.html', 'utf8');

Before exporting the file content, you can perform any intermediate transformations, for example, adding the right color palette to SVG or even doing automatic document translation through an LLM call.

CDN, HTTPS Imports, and npm

Let's get back to the ESM standard and its wonderful capabilities—specifically, the ability to load modules directly from a CDN via HTTPS. This is fully supported in both Node.js and the browser. At the CDN level (or even your own endpoint), automatic intermediate bundling and minification of modules can happen. That's how many popular specialized code delivery CDNs work — jsDelivr, esm.run, esm.sh, cdnjs, and many others. This lets you efficiently manage external dependencies and separate deployment cycles for complex system components.

For managing such dependencies, a super useful tool is the native browser technology importmap. Forget about all those clunky things like Module Federation — the platform already gives us everything we need.

Also, for working with JSDA dependencies (especially in a server context), good old npm works perfectly, giving us version control out of the box.

Distributed Composition

Everything mentioned in the previous section explains the "Distributed" part in the JSDA acronym. Simple and clear composition models are super important at the ecosystem level, where solution providers may be loosely connected to each other.

In the JSDA ecosystem, creating integrable solutions is really easy because you can always rely on the most basic standards and specifications without reinventing the wheel.

Security

One of the key security mechanisms in the JSDA stack is SRI (Subresource Integrity) — integrity verification of JSDA dependencies through hashing.

Isomorphism

At the very beginning, I mentioned PHP, and you might be wondering: if JSDA works almost like PHP, why not just use PHP?

First off, PHP is a hypertext preprocessor. Working with output formats other than HTML (XML) isn't always as painless as you'd like. PHP simply doesn't have a full equivalent to template literals like JS does.

Second, JavaScript is — whether you like it or not — the only programming language on the web that's fully and natively supported on both server and client.

Third, and most importantly, by using one language you can reuse the same entities in server and client code, write so-called "isomorphic" code, and SIGNIFICANTLY save on all development-related processes, including the mental ones in your head. You don't have to switch between languages, you don't have to write tons of separate configs, and your project is easier to test and maintain with fewer resources.

Thanks to isomorphism and a unified language, JSDA, while primarily a server technology, can easily and almost seamlessly be applied on the client when needed.

TypeScript

You can't get by without TS in modern development. However, TypeScript itself, being an important ecosystem tool for static analysis, contains a bunch of complexities and controversial aspects that surface as soon as you try to do something more intricate. If you've ever developed your own libraries — you'll immediately know what I'm talking about.

The author of these lines has come to use type declarations directly in JS code in JSDoc format, along with additional *.d.ts files, as the most balanced TypeScript practice. And I'm not alone in this — I'm seeing more and more experienced developers doing the same.

Applied to JSDA, this approach gives the following benefits:

No additional build steps: each module can be a standalone endpoint
The code that runs is exactly the code you wrote — no messing with sourceMap bugs during debugging
No issues with following standards (for example, ESM identifiers include file extensions — in TS this isn't mandatory)
JSDoc is more convenient for commenting + allows automated documentation generation, which is what it was designed for anyway

But if that's not your thing — you can totally use TypeScript syntax, it's perfectly compatible with JSDA principles.

AI

When working with AI assistants in development, we face one problem that for some reason isn't talked about much yet. AI tends to reproduce popular approaches and patterns without deep analysis of their efficiency and applicability in a specific case. AI is still pretty bad at that simplification thing I mentioned earlier. React became too bloated and slow? Doesn't matter — AI will suggest using it simply because there are more code examples online. In this regard, AI behaves like a junior developer, unable to take responsibility for architectural decisions that require making choices. Meanwhile, AI itself globally needs token consumption optimization, and this could well be reflected in the technologies we use. The simplicity of our solutions, including reducing the entities we operate with, should positively influence this situation. That's why it's important to create new minimalistic patterns like JSDA, which should overall have a positive impact on the industry.

Tools

Until now, I've been talking about JSDA as a set of conventions and an architectural principle, without tying it to specific tools and not forcing anyone to use anything particular. Of course, for anyone to actually use all this, there needs to be an ecosystem of solutions that let you quickly spin up a project and get first results as fast as possible. That's exactly what I've been working on lately. I'd love to get the community involved and move forward — together.

Here's what we have at the moment:

JSDA Manifest – concept description
JSDA-Kit – isomorphic toolkit for working with the JSDA stack
Symbiote.js – library for efficient work with Web Components, enabling very flexible HTML handling
JSDA repository template for quick start

Of everything listed, Symbiote.js is the most "mature" project—the rest is in active development, but you can try it out right now.

Also, we are working on a specialized CDN that, in addition to preliminary bundling and minification of modules, will automatically issue ready files in the final format (HTML, CSS, SVG, Markdown, JSON and so on).

Zen of Image Publishing

Alex M — Tue, 18 Mar 2025 14:23:05 +0000

Hello! Today I'd like to talk about the problem of publishing images. Why talk about this at all? Every day, millions of people publish millions, or even billions of images - what's there to discuss? Surely for a web developer, especially an experienced one, this isn't a problem at all. Well, not quite.

I'll start by describing the perspective from which I personally look at this issue. Perhaps this will add some color to the technical narrative.

I'm a full-stack developer who specializes in projects with a significant R&D focus. I often need to publish side artifacts of my work, such as web pages with documentation, technical articles, interactive demos, prototypes and experiments, promotional pages, and so on. Naturally, all of this needs to be illustrated with interface screenshots, diagrams, various render examples, and other cat photos.

At the same time, I prefer approaches and practices that minimize context switching and the proliferation of entities I have to interact with. This allows me to be more effective. I write docs and articles directly in my IDE, in markdown format, and store them in git. Building and publishing to the web happens automatically through git hooks and actions. This makes collaboration with technical colleagues comfortable, and our common business processes more lightweight. Ideally, I want images to be part of this zen too. But...

The first "chicken and egg" question: to place an image on a page, you first need to get its URL. The simplest way, at first glance, is a relative path. You simply save the image somewhere in your project structure and publish it along with other files.

CDN

We don't want to store images in git. I hope you don't either. Especially if there are many of them. Because it increases repository size, slows down cloning and synchronization, increases build time, and so on. We want the images to be separate, somewhere in the cloud. Preferably in a special CDN, to avoid burning extra traffic from our main server and to speed up page loading for our respected readers and users. Using such CDNs has long been an established best practice.

We face a new question: how do we reconcile our lightweight workflow with the need to interact with a separate external service? After all, we still need convenient collaboration and automation, and that feeling of superiority over those who do everything manually through various inconvenient third-party UIs...

What else needs to be considered: CDN services typically create a flat storage structure where there's only a unique identifier for the uploaded asset and nothing more. Yes, often you can get additional metadata through a separate request using your API access key, but this isn't always convenient or applicable.

Adaptivity

In today's world, it's not enough to just insert an <img> tag with a src="..." attribute. We need to take care of users with different screens having different pixel densities. Otherwise, some will see "blur" while others will download more useless megabytes (which we'll pay for). We also need to take care of the optimal format (webp, avif, etc.). And on top of everything else, we need different image sizes simultaneously for different possible layouts (mobile, desktop, etc.).

It's good that CDN services handle the preparation of multiple variants, and we don't need to worry about their generation. But the HTML insertion code that takes everything into account becomes quite cumbersome, and we don't want to write it manually each time. Instead, we want to have a convenient tool that will do this automatically, in accordance with our settings.

Dream Web Media Asset Management

So, let me describe my ideal solution within the described goals. Here's an approximate list of what I want:

Collaborative work with the project's media collection through Git (but without uploading original images to the repository)
Automatic synchronization of local media directory with CDN (Like in Dropbox, roughly: drop files in a folder, and they automatically fly to the cloud)
Mandatory support for local directory structure (mapping nested folder addresses to file ID in CDN)
Generation of HTML insertion code with support for adaptiveness, lazy loading, and other modern features (srcset, sizes, loading="lazy")
Ability to sort and filter images by metadata
Ability to view and edit cloud collections without the need for all process participants to have local file copies
Ability to download and save local copies when needed
Storage of upload data in a format convenient for use in CI/CD pipelines and any other automatic processing (JSON)
Locally available web management interface without the need to create an additional account and authorize in a separate service
Binding cloud collections to projects, as well as the ability to use shared resources across different projects
Solution lightness. Absence of endless dependency lists. Simplicity for auditing and modifications
Independence from CDN service provider

A Bit More Personal History

I've been dealing with the technical side of this image kitchen for a long time. Once, I led a startup: we were making a service for publishing 360-photos. 360-photos is an interactive display method that allows you to view an object from all sides using a sequence of photos taken from different angles. You've probably seen this on some online store pages where products can be rotated with the mouse. That startup didn't survive, but it left behind rich experience applicable in many aspects. A peculiarity of that project was uploading a VERY large number of images by users: more than a hundred source photos might be needed for just one interactive publication.

Some time later, I was responsible for developing a set of widgets for uploading and displaying files at a company - a specialized CDN provider, one of those I mentioned above.

Besides this, I constantly experiment and publish something, both for my current projects and for fun. And despite all my experience, I haven't found a ready-made solution that would fully satisfy both myself and my team. At one perfect moment, we finally got fed up with this, and we decided to make our own.

CIT - Cloud Images Toolkit

I don't want to be accused of self-promotion, so I'll immediately clarify that we're talking about a free Open Source tool that isn't monetized in any way. My main goal is to share with the audience the story of a specific solution, as well as the approaches that we, as a team, developed in the process. Goal number two is to try to get feedback and motivation for further development of a useful tool.

So, CIT (Cloud Images Toolkit) is a web developer's workspace tool that allows automating the process of working with media content in web projects. It includes a utility for synchronizing a local directory with CDN, as well as a web interface for viewing and managing image collections.

Project GitHub link: https://github.com/rnd-pro/cloud-images-toolkit

At the current stage, CIT is adapted to work with the Cloudflare Images CDN service but is, in principle, independent of it. If there's interest, we can add built-in support for any other providers. But adapting it for your service is not a complicated matter, and you can add it yourself if needed. Later I plan to write a simple instruction on how to do this in Node.js.

Installation:

npm install --save-dev cloud-images-toolkit

Configuration (cit-config.json) in the project root:

{
  "syncDataPath": "./cit-sync-data.json",
  "imsDataPath": "./ims-data.json",
  "imgSrcFolder": "./cit-store/",
  "apiKeyPath": "./CIT_API_KEY",
  "projectId": "<YOUR_PROJECT_ID>",
  "imgUrlTemplate": "https://<YOUR_DOMAIN>/images/{UID}/{VARIANT}",
  "previewUrlTemplate": "https://<YOUR_DOMAIN>/images/{UID}/{VARIANT}",
  "uploadUrlTemplate": "https://api.cloudflare.com/client/v4/accounts/{PROJECT}/images/v1",
  "fetchUrlTemplate": "https://api.cloudflare.com/client/v4/accounts/{PROJECT}/images/v1/{UID}/blob",
  "removeUrlTemplate": "https://api.cloudflare.com/client/v4/accounts/{PROJECT}/images/v1/{UID}",
  "variants": ["120", "320", "640", "860", "1024", "1200", "2048", "max"],
  "imgTypes": ["png", "jpg", "jpeg", "webp", "gif", "svg"],
  "wsPort": 8080,
  "httpPort": 8081
}

What to pay attention to here:

imgSrcFolder - path to the local directory with images, which should be added to .gitignore, along with the file specified in apiKeyPath;

Image size variants and their formats are set in the config. During synchronization, CIT automatically generates all variants for each image using URL templates. It's important that your CDN supports automatic resizing and format conversion. In the case of Cloudflare Images, this is done in the service settings. Variant names should contain the image size in pixels, or the keyword max for the original. For example, if your template uses an image with a width of 320px, then you need to add variant 320 and variant 640 for screens with double pixel density.

Mapping of the local directory structure is implemented through a string containing the local path to the image. For filtering images in the UI, its substring is used, so it's desirable to ensure that folder names are unique where possible and the overall collection structure is meaningful.

IMS - Interactive Media Spots

CIT supports generating interactive widgets using your cloud images. For this, the OpenSource (MIT) widget library - IMS (https://github.com/rnd-pro/interactive-media-spots) is used.

Conclusion

If you have questions about implementation and usage - write, I'll be happy to answer them in the comments. The project is very young and is currently actively used as our internal working tool, so, of course, I'll be glad for any feedback, stars on GitHub, and suggestions for improvement or collaboration.

And of course, we have plenty of our own plans for developing the tool. For example, built-in image generation using AI, prompt management, auto-generation of descriptions (alt) for better SEO, support for video collections (streaming video), a dashboard section for working with IMS object collections, splitting the media collection description file into parts and managing different collections... And so on.

Thank you for your attention.

Symbiote.js 2.0

Alex M — Wed, 17 Jan 2024 15:37:41 +0000

I'm happy to announce the release of a new version of the wonderful front-end library Symbiote.js! Never heard of it? It's time to get acquainted.

Symbiote is a compact but very powerful library for creating web components and applications based on them. Yes, I know, we already have React, Vue, Svelte, LitElement and more. And maybe it’s not very clear why delve into anything else... But don’t rush to conclusions, the Symbiote has something to offer you.

Concept

Unlike many popular solutions, Symbiote.js takes the path of extending standard browser APIs. It is NOT trying to replace the web platform and become a new meta-platform, to create a new syntax, or reinvent the wheel in any other way. It does not require special compilers, parsers or special environment tools. The symbiote only needs a browser and JavaScript, but otherwise it is absolutely agnostic and can work both on its own and in combination with many popular and familiar technologies.

Also, a feature of Symbiote.js is that components created with it, use the DOM as the basis of their runtime. They are capable of analyzing the actual context of their use and can determine for themselves how to behave in each specific case. This makes Symbiote.js an excellent choice for creating widgets, organizing micro-frontends, creating meta applications and UI component libraries.

It is also worth noting that Symbiote.js is very flexible and extensible. It does not hide entities behind a thick layer of opaque abstractions, but, on the contrary, makes it possible to conveniently interact with them. If you are familiar with the DOM API, you already know almost everything you need and can easily create your own base class for application components with the functionality you need.

Symbiote.js is the answer to the question: - what can be squeezed out of standard HTML, JavaScript and CSS? And this answer is - You can squeeze out a lot. More than bare React and its closest, in terms of popularity, competitors can do.

In order not to be unfounded, I will give an example with such a difficult topic as SSR (Server Side Rendering). Since Symbiote templates are just HTML, which can be directly parsed by the browser without any additional processing, you can generate the base document markup for your Symbiote application with almost anything: from various CMS and JAMStack generators, to using simple template literals in Node.js or even static files directly. All you need to further “hydrate” (revitalize) the result is one single flag in the code of your wrapper component: ssrMode = true. That's all! There is no need to pre-generate HTML from JSX templates, no special placeholders and no magical “server components”. Here you can see how it works live: https://symbiotejs.org/2x/playground/ssr-hydration/

A simple example

Here I will give a basic example from the official documentation:

import Symbiote, { html, css } from 'https://esm.run/@symbiotejs/symbiote';

export class MyComponent extends Symbiote {

  init$ = {
    count: 0,
    increment: () => {
      this.$.count++;
    },
  }

}

MyComponent.template = html`
  <h2>{{count}}</h2>
  <button ${{onclick: 'increment'}}>Click me!</button>
`;

MyComponent.rootStyles = css`
  my-component {
    color: green;
  }
`;

MyComponent.reg('my-component');

As you can see, everything is quite simple and familiar: state initialization, component template, styles, event handlers... No conceptual complexity. You've most likely already encountered all of this, in one form or another.

DX

At the heart of Symbiote's DX strategy (Developer Experience) is the idea that the vulgar minimization of characters printed by the developer does not equal convenience in itself. Yes, compact code and minimal boilerplate are very good (and the code of Symbiote applications does not violate general trends), but what is much more important is an understanding of what the developer sees in front of him and a clear mental model behind the development process. This is why, personally, I really don’t like fashionable “black boxes” that hide details beyond their most banal and superficial use. There are ALWAYS problems lurking in these “dark waters”. And the more “magical” your framework is, the more difficult it is to solve these problems. And sometimes, almost all development in such environments comes down to solving problems created in previous iterations.

In Symbiote.js, almost everything you see should already be familiar to you, directly or indirectly. Unless you're new to frontend. And if you are a beginner, then you can learn the necessary basics on popular sites with documentation on modern specifications, for example MDN.

Patterns

This section is directly related to the previous one. To implement reactivity and work with data, Symbiote uses an extremely simple and understandable pub/sub pattern (Publish–subscribe). Most changes happen synchronously, and surprise surprise, this works, in most cases, faster than the approach of accumulating changes and then rendering asynchronously. Much faster, judging by the benchmarks.

In many ways, Symbiote follows principles that favor the creation of a Loosely Coupled Architecture, which is hardwired into the DNA of the web platform. The Symbiote encourages you to create business abstractions (independent components) rather than abstractions above the platform and alternatives to native APIs that further connect your entities.

Ecosystem

For any core library, an ecosystem of ready-made solutions is important. And often, this is an argument against using something new. And here the Symbiote also has a strong position. The fact is that due to its proximity to the platform, it can easily work with ready-made solutions for this platform and not require any special treatment. I have never had any problems with integrations, and I have already done a lot of them, from working with WebGL, to online code editors, complex UIs for working with graph data, and more.

Speaking about development environment tools, we have the same picture. An approximate and sufficient setup is described on the project website: https://symbiotejs.org/#biome

And the Symbiote does a lot of things perfectly on its own and does not require any additional dependencies at all. For example, you don’t need to look for libraries for rendering complex dynamic tables and lists (itemize API does a great job with this), you don’t need external solutions for application localization (there are several very simple and compact ways to do this), you don’t need external state managers (you you can connect them, but Symbiote has everything you need without them, and even more). And so on. Examples can also be seen on the website: https://symbiotejs.org/#playground

Summary

I understand perfectly well that new front-end libs are now of little interest to anyone, in general. But I think Symbiote.js can be seen as an alternative to the black box trend, as a dedicated solution for widgets, and as an example of how the use of modern standards is changing approaches. And therefore, it is worthy of your attention, at least in general terms, for the self development and outlook.

I often communicate with other developers, conduct interviews and read posts with comments on specialized resources. And I often come across the opinion that there are libraries “for large projects” and “for the soul.” Some use it for their main work, others for personal projects. Many people like Symbiote.js, but most often it is automatically classified as the second category of solutions for “small” personal projects. It's hard for me to agree with this. Recently, my team completed another, very large project using Symbiote.js and we did not regret our choice for a second.

Thanks for your attention, and don't be sorry for the stars on GitHub, developers will be very pleased to know that they are not “screaming into the void.”

Forem: Alex M

Symbiote.js: superpowers for Web Components

Composition

Low-code / no-js

R&D: The Art of Managing Uncertainty in Software Development

Preamble

What Is R&D?

Managed Chaos

The Focus Trap

Plan B

Fresh Eyes

The Start-Pause-Stop System

R&D Metrics

Team Requirements

AI

Crisis-Mode R&D

Summary

What's Actually Wrong with Web Components?

Myths That Won't Die

Nuances Worth Understanding

The Real Gotcha

AI Tooling and Core Standards

SEO and Shadow DOM

What Only Web Components Can Do

Unmet Expectations

Lit vs Symbiote.js

At a Glance

Templates: the Biggest Difference

What Lit Does

What Symbiote Does Differently

Server-Side Rendering: One Module vs Three Packages

Lit SSR

Symbiote SSR

Data Management: Decorators vs Prefix Tokens

The Lit Way

The Symbiote Way

Shadow DOM: Default vs Opt-In

CSS as a Data Source

Build Tooling

What Lit Does Better

Developer Experience

Should You Try It?

Symbiote.js - Superpower For Web Components

The Idea in Few Words

Why Loose Coupling is Important

Configuration outside JavaScript

Describing bindings in HTML attributes

Configuration from CSS

External templates

Component communication without prop drilling

Shared context (ctx + *)

Pop-up binding (^)

Named data contexts

SSR and Universal Components

Static Site Generation (SSG)

What else is in the new version?

Bundle Size

Summary

JavaScript Distributed Assets - simple but powerful

Basic Example

Conventions

JSDA as an Evolution of JAMStack

Hybrid Approach

Async Operations (Top Level Await)

Caching

String Interpolation

SSR and Web Components

File Transformations

CDN, HTTPS Imports, and npm

Distributed Composition

Security

Isomorphism

TypeScript

AI

Tools

Zen of Image Publishing

CDN

Adaptivity

Dream Web Media Asset Management

A Bit More Personal History

Shared context (`ctx` + `*`)

Pop-up binding (`^`)