DEV Community: Alex M

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.”

DEV Community: Alex M

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

CIT - Cloud Images Toolkit

IMS - Interactive Media Spots

Conclusion

Symbiote.js 2.0

Concept

A simple example

DX

Patterns

Ecosystem

Summary

Shared context (`ctx` + `*`)

Pop-up binding (`^`)