Skip to content

Embed versions comparison

The new version of Wized's Embed runtime library has been completely rethought to focus on improving many of the key aspects of building web apps:

  • Performance.
  • Accessibility.
  • Extensibility.
  • Developer Experience.

To achieve these improvements we had to make some breaking changes to the way you build apps with Wized, hence why it was necessary to create a new version. This document will help you understand the differences between the two embeds and learn how to get started with Embed 2.0.

Performance improvements

Shameless plug, Embed 2.0 is fast. We've spent a lot of time optimizing the runtime library to make sure your apps are as fast as possible. Here's a comparison using the official js-framework-benchmark:

Performance benchmarks

See the full comparison table

Performance benchmarks full table

On average the new version is 55x faster, but it goes up to 300x faster in some types of operations. This makes your apps feel snappier and significantly improve your users' experience when using them.

We have achieved these improvements by using a new architecture that focuses on granular reactivity, which means that only the parts of your app that need to be updated will be updated. Here's a comparison of conditionally rendering items on a list between the two versions:

We won't stop here, we're constantly working on improving the performance of the runtime library and we'll keep you updated on our progress!

Developer Experience improvements

Function Editor

The Data Field Editor evolves to become the Function Editor.

While Embed 1.0 used a mix of text evaluation and a unique {{ moustache }} syntax for writing custom logic, Embed 2.0 fully embraces JavaScript and uses functions to evaluate all dynamic fields:

This new editor provides a much more powerful way to write custom logic with a full-fledged code editor with goodies like:

And much more. Discover everything about the new Function Editor here.

Real-time updates in the canvas

Thanks to the new granular reactivity system, the afftected elements on the page now update in real-time without requiring a full reload of the canvas:

Action improvements

Event Actions

Embed 2.0 introduces a new type of actions: Event Actions. These actions allow you to listen to global events that are not element-specific and trigger after-actions when they happen. You can find them in the action panel:

Event Actions

The following events are currently supported:

  • Custom Condition: perform actions when a custom condition is met.
  • Attribute Present: perform actions when an attribute is present on the page.
  • Request Finishes: perform actions when a request finishes.
  • Page Starts Loading: perform actions when a page starts loading.
  • Page Finishes Loading: perform actions when a page finishes loading.

New On Event action

You can now listen for any arbitrary event on your elements. Instead of providing pre-built actions like On Click or On Change, the new On Event action gives you more freedom and control:

On Event action

New Run Function after-action

You can now run any arbitrary logic after an event is triggered using the new Run Function after-action, which is great for integrating third party libraries or extending Wized's functionality with your own custom code.

Not only that, but thanks to the new reactivity model of Embed 2.0 you can even mutate the Data Store by simply updating the values right in the function:

(c, f, i, n, r, v, e, t) => {
  console.log('The user has clicked!'); += 1;
  c.has_interacted = 'true';

Wized will take care of reflecting those updates in your app, like triggering DOM renders, setting cookies or navigating the user.

Cool, right?

Set Visibility action

Although it may seem that the Set Visibility action behaves exactly the same in both versions, there's a key difference: in Embed 2.0 the elements that are hidden are removed from the DOM instead of relying on display: none styles. This means that:

  • Apps are kept performant by minimizing the amount of present DOM elements at a time.
  • CSS selectors like nth:child() work as expected.


It's important to keep in mind that now it's up to you to make sure that the elements don't have display: none applied when they must be visible.

Set Class action

The behavior of the Set Class action has also been modified. Instead of defining your logic in two different ways (Add Class & Remove Class), the new Set Class action works as most JavaScript frameworks out there: you define a class name and a condition, and the class will be dynamically added or removed depending on it.

Set Class

Request improvements

Unified requests panels

In Embed 1.0 requests were split into Data In and Data Out panels. In Embed 2.0 we've unified all requests into a single Requests panel to better represent the flow of data in web apps: browsers send requests to a server, and the server sends responses back.

Requests panel

Unified requests triggers and after-actions

Previously requests triggers and after-actions could be defined both in the Requests and in the Actions panels (via events). This caused your app's logic to be spread across different places, making it harder to understand and maintain.

In Embed 2.0 we've unified everything under the Actions panel. Together with elements' On Event action and Event Actions, you can now define all your requests lifecycle in a single place, keeping your app's logic clean and organized.

Unified requests

Improved request data structure

Accessing requests data used to be done like this:

  • r.REQUEST_NUMBER.d for the request data. Example: r.1.d.
  • r.REQUEST_NUMBER.$ for the request status fields. Example: r.1.$.isRequesting.

This approach introduced a few problems: it was hard to remember the request numbers, accessing the r object using a number is invalid JavaScript syntax and the field names were not descriptive enough.

In Embed 2.0 we've improved the request data structure to make it easier to access and understand. On top of that, we've tweaked the request status fields to follow the Response standard defined by the Fetch API:

r.REQUEST_NAME.dataThe response payload of the request. This is the data that was returned by the server. If the request has not been executed yet, this field will be null.
r.REQUEST_NAME.hasRequestedA boolean indicating whether the request has been executed or not.
r.REQUEST_NAME.isRequestingA boolean indicating whether the request is currently being executed or not.
r.REQUEST_NAME.statusThe HTTP status code of the response. If the request has not been executed yet, this field will be null.
r.REQUEST_NAME.statusTextThe status message corresponding to the HTTP status code of the response. If the request has not been executed yet, this field will be null.
r.REQUEST_NAME.okA boolean indicating whether the request was successful or not. This is equivalent to r.REQUEST_NAME.status >= 200 && r.REQUEST_NAME.status < 300. If the request has not been executed yet, this field will be null.

Improved REST file uploads

REST requests in Embed 2.0 are smart. Wized will automatically detect when you include a file in the Body and send the request as multipart/form-data, which is the standard way to upload files to a server.

In combination with Forms, this makes it super easy to implement file uploads in your apps:

Improved Firebase and Supabase integrations

Both Firebase and Supabase integrations have been improved to make them more powerful and easier to use. Amongst other things, we have:

  • Added support for dynamic document paths.
  • Added support for all kinds of data types.
  • Added support for all OAuth providers.
  • Improved the filtering capabilities.
  • Improved the real-time functionality.

And much more. See the full documentation for more information.

Deprecated Access Controls

Since the introduction of Event Actions, Access Controls are no longer necessary. Why?

If you think of it, when defining Access Controls Wized performed the following actions:

  1. Listened for a condition (i.e. an access token cookie present in the user's browser).
  2. If the condition failed, the user was redirected to a fallback page.

This is exactly what Event Actions do, but with a much more power and flexibility. Instead of being limited to a single condition, you can now listen for any arbitrary event and perform any arbitrary action when it happens.

Data Store improvements

Computed variables

Variables can now be defined as computed. This means that you can define a variable that depends on other variables and it will automatically update when any of the dependencies change.

Example: You can create a variable that depends on i.price_1 and i.price_2. Whenever one of these input fields changes, will be updated too:

(c, f, i, n, r, v, e, t) => {
  return i.price_1 + i.price_2; 

Here's the result:

Cookies can now be configured to have a custom lifetime in days. In addition to that you can also create cookies without a lifetime, which will make them session cookies that are deleted when the browser is closed.

Cookie lifetimes

Support for all types of inputs

In Embed 2.0 we've made sure that all types of inputs are supported, including edge cases like checkbox groups and multi-select dropdowns.

You can find a full list of supported input types here.

New f param - Forms

As mentioned above, one of the main focuses of Embed 2.0 is accessibility. Forms are the designated way to collect user input in web apps, providing interactive controls and an accessible way to submit data.

Similar to input fields (i), forms can now be accessed via the f keyword in the Data Store and the Function Editor.

To get started all you need to do is add the wized = "ELEMENT_NAME" HTML attribute to your <form> element. This will create a new form named f.ELEMENT_NAME in the Data Store and Wized will automatically populate it with the form's data any time it is submitted.

See Creating a form for more information.

New t param - Target

Any time you define a function that interacts with an Element Action, you can now access the target WizedElement via the t keyword.

This is useful for performing actions on the element via custom code, as well as accessing the element's attributes and properties or implementing advanced features like element-specific state.

New e param - Event

Any time you define a function that interacts with an On Event Action, you can now access the Event object via the e keyword.

This gives you extra super powers to build advanced functionalities like mouse tracking, keyboard shortcuts, etc.

New JavaScript API

The entire public facing JavaScript API has been redesigned to be more intuitive and powerful. Amongs many other things, you can now:

  • Access and mutate the Data Store.
  • Access any WizedElement instance and listen for granular events.
  • Await, execute and read any request.
  • Access the loaded project configuration.

You can find the full documentation here.

Automatic migration

As an effort to make the transition to Embed 2.0 as smooth as possible, we've created an automatic migration tool that will convert your Embed 1.0 projects to Embed 2.0.

This process is currently offered under request, so if you're interested in migrating your projects please contact us via the in-app chat and we'll be happy to help you out.


Automatic migrations are still a work in progress and not all use cases are yet supported. We are actively working on improving it and we'll keep you updated on our progress. Check out What's next to see the integrations that can't be migrated yet.

What's next

Not all functionalities from Embed 1.0 have been ported to Embed 2.0 yet. In particular, the following features are still missing:

  • Server-side REST requests. See this RFC for more information.
  • Stripe requests.
  • Airtable requests.
  • Notion requests.
  • Native support for Finsweet Attributes.

Our main focus right now is to implement all those missing features in the upcoming weeks. After that, we'll share a public roadmap with our plans for the future of Wized, which includes more DX improvements, new features and more.

Stay tuned!