DEV Community: Plopino

Preço certo, prazo antigo: como conferir as transições de uma proposta em HTML

Plopino — Fri, 02 Oct 2026 12:38:09 +0000

Uma proposta interativa pode mostrar o preço certo e, ao mesmo tempo, manter o prazo da opção anterior. É fácil não perceber isso quando cada botão é conferido separadamente.

Ao organizar um exemplo pequeno em HTML e JavaScript, o critério foi fazer preço, prazo e entregáveis saírem da mesma combinação de dados. São dois pacotes e duas revisões, com valores fictícios.

Primeiro, saber de onde vem cada resposta

O estado guarda as escolhas, não o resultado:

let revision = "first";
let plan = "essential";

Uma tabela contém as quatro combinações. Este recorte usa números em USD apenas para ilustrar o modelo, sem conversão para reais:

const proposals = {
  first: {
    essential: { price: 4800, weeks: 3 },
    complete: { price: 7200, weeks: 4 }
  },
  revised: {
    essential: { price: 5400, weeks: 4 },
    complete: { price: 8100, weeks: 5 }
  }
};

O registro atual é proposals[revision][plan]. Não existe uma variável extra para o preço, nem outra para o prazo. Assim, há menos valores que precisam ser mantidos em acordo.

O evento escolhe; a renderização atualiza

Em vez de cada botão atualizar um pedaço da página, os eventos mudam uma escolha e chamam a mesma função render().

No exemplo completo, essa função atualiza o resumo, reconstrói a lista de entregáveis e ajusta aria-pressed dos dois grupos de botões. Os textos entram com textContent, sem serem interpretados como HTML.

Isso também evita um comportamento estranho: trocar a revisão não volta o pacote para o básico. Quem está comparando o pacote completo continua nele. Só a revisão muda.

Essa escolha deixa a comparação mais fácil de acompanhar. Se um pacote não estiver disponível em uma revisão futura, a interface precisará tratar e explicar esse caso.

Conferir quatro resultados e depois percorrer o caminho

A tabela esperada é pequena:

Revisão	Pacote	Valor fictício (USD)	Prazo
Inicial	Básico	4800	3 semanas
Inicial	Completo	7200	4 semanas
Revisada	Básico	5400	4 semanas
Revisada	Completo	8100	5 semanas

Conferir essas linhas ajuda a encontrar um dado errado. Mas a interface tem memória entre os cliques: algum elemento pode ficar com o conteúdo da seleção anterior.

Por isso, vale percorrer Completo → Revisada → Básico → Inicial sem recarregar a página.

Em cada etapa, confira:

se o preço e o prazo correspondem à mesma combinação;
se a lista de entregáveis foi atualizada;
se o pacote escolhido foi mantido ao trocar a revisão;
se os dois grupos mostram o estado selecionado correto.

Não é preciso transformar esse exemplo em uma aplicação grande para conferir isso. Uma sequência curta já revela mais do que abrir cada combinação isoladamente.

O teclado também precisa entrar na conferência

Os controles usam elementos button. Tab muda o foco; Enter e Espaço ativam o botão. aria-pressed expõe a seleção.

O resumo usa aria-live="polite" e aria-atomic="true", para disponibilizar a atualização completa às tecnologias assistivas. Ainda é necessário conferir o comportamento nos leitores de tela usados pelo público; esses atributos, sozinhos, não garantem que toda a experiência esteja boa.

Prévia não é publicação

As duas revisões já estão no arquivo. O botão alterna o que aparece, sem salvar nem atualizar a página hospedada.

Por isso, “prévia da revisão” descreve melhor a ação. Para atualizar o conteúdo público, é necessário enviar o arquivo alterado e conferir o endereço que será compartilhado.

O exemplo ficou pequeno porque tem uma tarefa limitada: comparar escopo sem separar preço, prazo e entregáveis. A parte interessante é conferir se essa promessa continua verdadeira depois de vários cliques.

O artigo original em inglês traz o HTML e o JavaScript completos para reproduzir o exemplo. Aqui, o foco foi o raciocínio por trás da verificação das transições.

Vocês costumam testar os estados isolados primeiro ou já começam pelos caminhos que a pessoa pode percorrer?

Cambiar la versión de una propuesta sin perder el paquete elegido

Plopino — Fri, 02 Oct 2026 12:36:37 +0000

Al comparar dos versiones de una propuesta, ya hay bastante que recordar. Si cambio de versión y la página también cambia el paquete que había elegido, termino comparando dos cosas a la vez.

Ese detalle fue uno de los criterios al ordenar un pequeño ejemplo en HTML y JavaScript: dos paquetes, dos revisiones y un resumen con precio, plazo y entregables. Los importes son ficticios.

Dos decisiones, no cuatro botones independientes

La selección cabe en dos variables:

let revision = "first";
let plan = "essential";

Cambiar la revisión modifica únicamente revision. Cambiar el paquete modifica únicamente plan. No hay una razón para reiniciar la otra elección.

Un ejemplo mínimo de los datos sería este. Los importes están expresados en USD, solo para ilustrar la estructura:

const proposals = {
  first: {
    essential: { price: 4800, weeks: 3 },
    complete: { price: 7200, weeks: 4 }
  },
  revised: {
    essential: { price: 5400, weeks: 4 },
    complete: { price: 8100, weeks: 5 }
  }
};

function currentProposal() {
  return proposals[revision][plan];
}

El resultado se deriva de la selección. Guardar también el precio como estado crearía otra cosa que mantener sincronizada.

Un solo sitio para actualizar la interfaz

La tentación es poner un poco de lógica en cada botón: este cambia el precio, aquel cambia el plazo, otro reconstruye la lista. Cuesta ver si todos terminan dejando la página en el mismo estado.

La alternativa del ejemplo es que cada evento actualice una variable y llame a render(). Esa función obtiene el registro de la combinación actual y actualiza el resumen, los entregables y aria-pressed de los botones.

Para los textos se usa textContent. Un entregable es texto; no hace falta interpretarlo como HTML.

Hay una consecuencia útil: si estoy viendo el paquete completo y paso a la revisión, sigo viendo el paquete completo. El precio puede cambiar porque cambió el alcance, pero mi selección permanece.

Una tabla correcta no garantiza una transición correcta

Estos son los cuatro resultados esperados:

Revisión	Paquete	Precio ficticio (USD)	Plazo
Inicial	Básico	4800	3 semanas
Inicial	Completo	7200	4 semanas
Revisada	Básico	5400	4 semanas
Revisada	Completo	8100	5 semanas

Comprobar cada fila sirve para revisar los datos. Después conviene recorrer una secuencia:

Completo → Revisada → Básico → Inicial.

En cada paso, hay que comparar el precio, el plazo, los entregables y el estado seleccionado de ambos grupos. Así también se busca contenido que se haya quedado de la selección anterior.

Los controles son botones nativos. Se puede recorrer la interfaz con Tab y activarlos con Enter o Espacio. aria-pressed comunica la selección y una región aria-live="polite" anuncia el resumen. Eso no sustituye una prueba con lectores de pantalla.

El nombre del botón también forma parte del comportamiento

Las dos revisiones ya están en el archivo. El selector las muestra: no guarda cambios ni publica una actualización.

Llamarlo “vista previa de la revisión” ayuda a entender esa diferencia. Para modificar una página alojada, todavía hay que subir el archivo cambiado y comprobar el enlace público.

Es un detalle pequeño, pero el control no debería prometer una acción que no ha ocurrido.

La versión en inglés con el HTML y JavaScript completos incluye el ejemplo reproducible. Esta versión se centra en el criterio de conservar las elecciones durante la comparación.

¿En qué casos sí tendría sentido reiniciar el paquete al cambiar de versión? Por ejemplo, si un paquete deja de existir, haría falta explicar ese cambio en lugar de aplicarlo en silencio.

A tiny HTML proposal with two switches and one render function

Plopino — Fri, 02 Oct 2026 11:44:42 +0000

A proposal can look perfectly reasonable until you change one option. The price updates, but the delivery time still belongs to the old plan. Now the page is giving two different answers.

That is the small problem this example tackles: two packages, two revisions, and one consistent summary. It uses ordinary HTML and JavaScript. The company details and estimates are fictional.

The useful part is the shape of the state. You can reuse it for a quote calculator, a package comparison, or a project scope preview.

Keep the choices separate from the result

There are only two choices:

let revision = "first";
let plan = "essential";

The estimate is derived from those choices. It does not need another state variable.

const proposals = {
  first: {
    essential: {
      price: "$4,800", weeks: 3,
      items: ["Five responsive pages", "Contact form"]
    },
    complete: {
      price: "$7,200", weeks: 4,
      items: ["Five responsive pages", "Contact form", "Project gallery"]
    }
  },
  revised: {
    essential: {
      price: "$5,400", weeks: 4,
      items: ["Five responsive pages", "Booking flow", "Accessibility review"]
    },
    complete: {
      price: "$8,100", weeks: 5,
      items: ["Five responsive pages", "Booking flow", "Accessibility review", "Project gallery"]
    }
  }
};

Each combination has a complete record. That makes it possible to inspect the numbers and scope together before touching the interface.

These are fixed example estimates. A real pricing tool would need its own rules for currency, tax, and calculations.

Give every change the same path through the DOM

Here is the markup. Put it in the body of an HTML page, with the JavaScript below it in a script element.

<h1>Website proposal</h1>
<p>Fictional estimates for a scope comparison.</p>

<div role="group" aria-label="Proposal revision">
  <button type="button" data-revision="first" aria-pressed="true">First draft</button>
  <button type="button" data-revision="revised" aria-pressed="false">Revised scope</button>
</div>

<div role="group" aria-label="Choose a package">
  <button type="button" data-plan="essential" aria-pressed="true">Essential</button>
  <button type="button" data-plan="complete" aria-pressed="false">Complete</button>
</div>

<p id="summary" aria-live="polite" aria-atomic="true"></p>
<ul id="deliverables"></ul>

Both sets of buttons change a choice and call the same function:

function render() {
  const proposal = proposals[revision][plan];
  const revisionLabel = revision === "first" ? "First draft" : "Revised scope";
  const planLabel = plan === "essential" ? "Essential" : "Complete";

  document.getElementById("summary").textContent =
    `${revisionLabel}, ${planLabel}: ${proposal.price}; ${proposal.weeks} weeks.`;

  document.getElementById("deliverables").replaceChildren(
    ...proposal.items.map(item => {
      const li = document.createElement("li");
      li.textContent = item;
      return li;
    })
  );

  document.querySelectorAll("[data-revision]").forEach(button => {
    button.setAttribute("aria-pressed", String(button.dataset.revision === revision));
  });
  document.querySelectorAll("[data-plan]").forEach(button => {
    button.setAttribute("aria-pressed", String(button.dataset.plan === plan));
  });
}

document.querySelectorAll("[data-revision]").forEach(button => {
  button.addEventListener("click", () => {
    revision = button.dataset.revision;
    render();
  });
});

document.querySelectorAll("[data-plan]").forEach(button => {
  button.addEventListener("click", () => {
    plan = button.dataset.plan;
    render();
  });
});

render();

The click handlers are deliberately boring. They do not calculate prices, rewrite individual list items, or decide which buttons should look selected. Those changes happen together in render().

Selecting Complete and then Revised scope keeps Complete selected. Switching the revision does not quietly reset the package. That behavior follows directly from keeping the choices separate.

Using textContent also means a deliverable is inserted as text, rather than interpreted as HTML. If this later reads external data, that is a useful boundary to preserve.

Check the combinations, then the transitions

There are four expected results:

Revision	Package	Price	Delivery
First draft	Essential	$4,800	3 weeks
First draft	Complete	$7,200	4 weeks
Revised scope	Essential	$5,400	4 weeks
Revised scope	Complete	$8,100	5 weeks

Checking each row catches incorrect data. Checking a sequence catches stale UI. Try Complete → Revised scope → Essential → First draft, and compare the summary, deliverables, and pressed button states after each step.

Then use only Tab, Enter, and Space. Native buttons provide the keyboard interaction; aria-pressed exposes the selected state. The polite live region makes the combined price and delivery summary available to assistive technology. That is a starting point, and it still needs testing with the screen readers and browsers your audience uses.

A revision preview needs an honest label

Both revisions in this page are already in the JavaScript object. The switch previews them. It does not save anything, publish a new version, or update a hosted page.

That distinction matters when sharing a prototype. Label the control as a preview, keep the estimates fictional, and test the actual public URL after deployment. A working local file cannot tell you whether the recipient's link works.

The page stays small because it has a small job: let someone compare scope without allowing the price, timeline, and deliverables to drift apart.

AI disclosure: This article and the adapted code example were generated by an AI agent from an existing HTML example. The example was checked in a browser before publication.

MCP or CLI? Choose by Who Controls the Workflow

Plopino — Thu, 24 Sep 2026 02:21:10 +0000

Suppose a tool can publish a built site. Should it offer a command line interface, an MCP server, or both?

The tempting answer is “MCP for AI, CLI for humans.” That is too simple: agents can run commands, and people can ask an MCP client to call tools. A better question is who decides the next step, and where does the data live?

Start with the caller

Choose a CLI when the caller already has a repeatable sequence: build, test, publish, inspect the result. A shell script or CI job can pass a path, use an exit code to detect failure, and parse JSON when it needs a URL or identifier. The command is also easy to run and debug locally.

# Illustrative command, not a package name
publisher publish ./dist --json

Choose an MCP tool when an assistant needs to discover an operation and call it as part of a conversation. A tool such as publish_page can declare that it accepts content and filename, then return a structured result. The assistant can use that result in its next step. MCP gives the client a standard way to list and call tools; it does not make a publication automatically safe or correct.

Situation	Starting point
A fixed deployment job publishes the same build output	CLI
A developer wants one command after a local build	CLI
An assistant drafts a small page and asks to publish it	MCP tool accepting content
An assistant works with a local directory and its assets	Local MCP tool accepting a path, or CLI
A remote assistant has no access to the developer's disk	MCP tool accepting file contents or another upload mechanism

These are starting points, not hard boundaries. If an agent already has a reliable terminal, invoking the CLI may be the simplest integration. If an application already speaks MCP, a tool can avoid teaching the assistant command syntax and output parsing.

Location matters more than the interface name

Consider a tool argument like publish_path({ path: "./dist" }). With a local MCP server launched over stdio, the server process can usually read that directory. With a remote MCP server over HTTP, ./dist means a path on the server, not the user's laptop. The same string has different consequences depending on the transport.

For a remote client, send the contents explicitly, or upload them through an API that provides a file handle to the server. For a local directory with many related assets, a local tool or CLI is often a better fit. The MCP transport documentation describes stdio and Streamable HTTP; the filesystem boundary follows from where each server runs.

Design the failure path, too

A useful CLI needs stable exit codes, script-friendly output, and a way to provide credentials without an interactive prompt. Keep human progress messages separate from machine-readable output. A useful MCP tool needs a precise input schema and a result that tells the client what succeeded or failed. For a stdio MCP server, stdout is the protocol channel, so ordinary logs belong elsewhere.

Publishing also deserves the same controls through either interface: make the destination clear, inspect what files will leave the machine, keep secrets out of the published bundle, and avoid returning a private claim or edit link as the public viewing URL. If an operation replaces an existing page, make that intent explicit in the arguments or flags.

If you offer both, share the operation

The two interfaces can sit on top of one publishing function. The CLI handles flags, terminal output, and exit codes. The MCP adapter handles tool definitions and structured results. Authentication, upload rules, size limits, and update behavior should come from the shared operation, so the two entry points do not quietly disagree.

My rule of thumb: use a CLI for a known sequence; use MCP when a tool-aware client is choosing actions; use a local interface for local paths. Then add the second interface only when a real caller needs it.

How do you draw that line in your own tools? Have you found cases where an agent calling a CLI works better than an MCP integration?

AI disclosure: An AI assistant drafted this article. The technical distinctions were checked against the MCP transport documentation and an implementation that exposes both CLI and MCP entry points. This post is intended as a discussion of interface design, not a product recommendation.

Things that were harder than expected building a drag-and-drop static host

Plopino — Tue, 15 Sep 2026 15:01:44 +0000

I built a small static host (plopino.com) with a boring
premise: drag a file onto a page, get a link. No account for the basic flow.

The feature list is short. What took the time was a handful of specific
problems. Here they are, in case they save you the same afternoon.

1. Path-based hosting means every relative link is your problem

Most drop-style hosts give each project a subdomain:
my-project.host.com. I went the other way. Every board lives under a path:

https://plopino.com/b/<boardId>/...

One route serves it. One TLS certificate. No per-board DNS, no wildcard cert
renewal, no waiting on propagation — the whole routing and TLS story stays
simple.

The bill comes due on relative links. A board is arbitrary user HTML, so a page
at /b/<id>/sub/page.html can contain anything:

<a href="../../other.html">
<img src="//cdn.example.com/x.png">
<a href="/absolute/path">
<a href="javascript:void(0)">

I need to know which of those stay inside the board and which don't, because
that decision drives both storage accounting and whether a board can reach
outside its own tree. The rule I landed on: data:, javascript:, mailto:,
tel:, blob:, protocol-relative (//x) and root-relative (/x) URLs are all
"not board-internal". Everything else resolves against the board root.

Root-relative is the one that trips people up. /style.css inside a board looks
like it should work, and it "works" in the sense that the browser requests
https://plopino.com/style.css — which is my site's path space, not the
board's. Treating it as external is the only safe reading.

2. Streaming the upload, and streaming the zip

The upload path uses Busboy with a couple of settings that matter:

Busboy({ headers: req.headers, preservePath: true, defParamCharset: 'latin1' })

preservePath is what makes folder drags work. When you drag a directory into a
browser, the multipart parts carry relative paths (site/css/main.css), and if
you let the parser flatten them to basenames you have thrown away the structure
before you ever see it.

Each file part streams straight to a temp file. Nothing is buffered in memory —
uploads are large enough that buffering a zip only to decompress it afterwards
would double peak memory for no benefit.

Zip extraction goes through yauzl in lazy mode:

yauzl.open(zipPath, { lazyEntries: true, decodeStrings: false }, ...)

lazyEntries keeps one entry in flight at a time instead of materialising the
central directory as an array of objects, which matters when someone uploads a
zip with a few thousand files. decodeStrings: false is the interesting one —
see below.

3. Filename encoding is still a mess in 2026

This is the part I underestimated.

Zip entries don't have a mandated encoding for filenames. The spec says CP437
unless a UTF-8 flag is set, but in practice you receive whatever the producing
tool felt like writing — and on Chinese Windows systems that frequently means
GB18030.

Meanwhile multipart filename parameters are specified as Latin-1-ish, with
RFC 5987's filename* as the escape hatch for anything else. Browsers are
inconsistent about which they send.

So there are two decode paths that have to agree:

filename* (RFC 5987) — Busboy already decodes this to Unicode correctly, use it as-is.
Plain filename — Busboy preserves the raw bytes as Latin-1, so I take those bytes and try UTF-8 first, falling back to GB18030 detection.

If you skip this, a user with a Chinese-locale machine uploads a folder and
every filename comes out as mojibake. From their side it looks like the site
corrupted their files.

4. Persistent workers, not per-request processes

Board thumbnails and Office previews both need a real renderer. The obvious
implementation — spawn one per request — is also the one that makes previews
feel slow and pins the CPU.

Both run in long-lived pools instead:

Office (docx / xlsx / doc) previews render in a persistent worker pool and are cached, so nothing blocks the main thread.
Thumbnails use one lazily-started headless Chromium, one page per task, at a fixed viewport, with a single-flight queue so a burst of new boards doesn't start a browser per request.

The thumbnail step also needed a bit of judgement that isn't obvious from the
outside: before screenshotting, it hides the preview page's own chrome (the
wordmark and download button) and collapses left-hand navigation. Otherwise
every card thumbnail has a tiny "Download" button burned into the corner,
and documentation-style boards show nothing but a sidebar.

5. A test that enforces translation key order

The UI ships in 20 languages including RTL Arabic and Persian.

The test that keeps this honest compares every dictionary against the English
one on three axes: the key set, the key order, and the placeholder names
inside each string.

assert.deepEqual(Object.keys(dict), EN_KEYS);          // set AND order
assert.equal(placeholders(dict[key]), placeholders(EN[key]));

Key order is the unusual one. Nothing forces a JS object literal to keep the
same ordering as another, and nothing breaks at runtime if it drifts — but a
dictionary that has drifted is a dictionary someone edited by hand and then
stopped maintaining. Asserting order means the file layout itself is part of the
contract, so a missing translation fails the suite instead of silently rendering
an English string into a Persian page.

The test also validates BCP-47 tag shape, direction (ltr/rtl), and that the
default language sorts first.

One more thing that follows from having 20 languages: the server injects
<title>, description, og:* and hreflang per language. Crawlers and social
scrapers don't run JavaScript, so a client-side i18n layer is invisible to them.
The page declares data-i18n-doctitle / data-i18n-docdesc on <html>, and the
server renders the real head from the dictionary.

6. Quotas, and moderation that runs on reports

Anonymous uploads are rate-limited per IP per day, and the counters are
persisted — a deploy does not hand everyone a fresh allowance. Signed-in users
get a larger allowance.

Moderation is report-driven: an abuse contact, a takedown path, and reports get
acted on. I'm spelling that out because it is the most predictable question
about a service that hosts arbitrary HTML from strangers.

A related decision that took longer than it should have: are uploaded boards
indexable? Blocking them entirely is the safe-feeling default, but it's wrong in
a subtle way — robots.txt-blocked URLs can't be crawled, so a private board's
URL can linger in search results as a bare link with no context. The site now
serves X-Robots-Tag: noindex on /b/ by default and removes it for public,
undeleted boards. Public boards are linkable-and-crawlable when someone shares
them; private, deleted and expired ones stay out. The sitemap lists zero boards
either way — I'm not turning my sitemap into a directory of user content.

What I'd tell someone starting this

Decide the URL shape on day one. Path vs subdomain changes the link-resolution code, the TLS story and the SEO story, and retrofitting it is miserable.
Treat filenames as hostile input from at least three encodings.
If you render anything user-supplied, keep the renderer warm and put a queue in front of it.
Write the i18n test before the fourth language, not after the tenth.

The service is at plopino.com if you want to try the
actual thing. It's not open source right now — mostly because I don't want to
hand out deployable copies while the abuse story is still unfinished.