Blazor WebAssembly/Server: Work with Everything

Making Blazor work with everything, plus WebAssembly on the server

Real-world software projects often involve combining many technologies. So, is modern Blazor powerful and flexible enough for your team's needs? In this demo-heavy talk, Steve will show how:

- Blazor WebAssembly/Server can seamlessly embed libraries and logic written in other languages such as Rust or C/C++
- Blazor WebAssembly/Server components can be used inside other SPA frameworks such as React or Angular (or vice-versa)
- Blazor components can be used not only for web projects, but also shared with native apps for macOS, iOS, Android, and Windows (including WPF and WinForms)

These capabilities should equip your team to take on the most ambitious projects with confidence.

We'll then look further into the future and consider how WebAssembly is moving beyond the browser and is pitched to become a foundational element of cloud-native server apps. You'll be among the first to see an experimental new approach to compiling .NET applications into WASI-compliant universal binaries that can run on any OS or processor, robustly sandboxed and with great performance.

#blazor #webassembly #wasm 

Boa: An Embeddable and Experimental Javascript Engine Written in Rust

Boa

This is an experimental Javascript lexer, parser and interpreter written in Rust. Currently, it has support for some of the language.

Contributing

Please, check the CONTRIBUTING.md file to know how to contribute in the project. You will need Rust installed and an editor. We have some configurations ready for VSCode.

Debugging

Check debugging.md for more info on debugging.

Web Assembly

This interpreter can be exposed to JavaScript! You can build the example locally with:

npm run build

In the console you can use window.evaluate to pass JavaScript in. To develop on the web assembly side you can run:

npm run serve

then go to http://localhost:8080.

Usage

• Clone this repo.
• Run with cargo run -- test.js where test.js is an existing JS file with any JS valid code.
• If any JS doesn't work then it's a bug. Please raise an issue!

Example

Command-line Options

USAGE:
    boa [OPTIONS] [FILE]...

FLAGS:
    -h, --help       Prints help information
    -V, --version    Prints version information

OPTIONS:
    -a, --dump-ast <FORMAT>       Dump the abstract syntax tree (ast) to stdout with the given format [possible values: Debug, Json,
                                  JsonPretty]

ARGS:
    <FILE>...    The JavaScript file(s) to be evaluated

Live Demo (WASM)

https://boa-dev.github.io/boa/playground/

You can get more verbose errors when running from the command line.

Development documentation

You can check the internal development docs at https://boa-dev.github.io/boa/doc.

Conformance

To know how much of the ECMAScript specification does Boa cover, you can check out results running the ECMASCript Test262 test suite here.

Roadmap

See Milestones.

Benchmarks

See Benchmarks.

Profiling

See Profiling.

Changelog

See CHANGELOG.md.

Communication

Feel free to contact us on Discord.

Author: Boa-dev
Source Code: https://github.com/boa-dev/boa 
License: MIT, Unlicense licenses found

#javascript #rust #webassembly #wasm 

Running JavaScript, Python, and Ruby in WebAssembly

Running JavaScript, Python, and Ruby in WebAssembly

In this tutorial, Michael will discuss the approaches and latest progress of Wasm support of scripting languages, like JS, Python, and Ruby

Wasm was designed to run applications written in compiled languages such as C/C++, Rust, Swift, etc. However, as Wasm gains popularity, there are increasing demands to run Wasm applications in scripting languages such as JavaScript, Python and Ruby. Compared with native interpreters (or dynamic compilers), Wasm offers benefits to both devs and ops. Dev: Wasm is a polyglot environment that supports mixing high-performance compiled languages and easy-to-use scripting languages. For example, with Wasm, devs can safely wrap Rust functions in a JS API. Op: Wasm is a sandbox with OS access. It can be managed as a standalone container or be embedded in a host. Native scripting language VMs need to be wrapped in other runtimes (eg node) and Docker containers. Wasm can achieve significant savings in computing resources. In this talk, Michael will discuss the approaches and latest progress of Wasm support of scripting languages, like JS, Python, and Ruby. He will cover language interoperability, ecosystem (eg packages and modules) support, and performance characteristics. Finally, Michael will also briefly discuss Wasm support status for popular managed languages such as Java and .Net.

#javascript #python #ruby #webassembly #wasm

State Management with Blazor WebAssembly

Blazor: Flavors of State Management with Blazor WebAssembly

In this tutorial, I will cover the simple state management flavours with Blazor WebAssembly and then progress towards something more tasty like the Redux pattern. 

Working with Blazor WebAssembly applications we often overlook the importance of appropriate state management. Without a good understanding and the right strategy, our applications can end up polluted with components that behave badly and we end up regretting the bad choices.

In this session, I will cover the simple state management flavours and then progress towards something more tasty like the Redux pattern. We will see what there is to like and dislike about each flavour. Next, we will take a step back and determine the appropriate seasoning of state management to pair with our application. You will leave this session having sampled all the wonderful flavours and be able to make great decisions to have the best development experience.

#blazor #webassembly #wasm #dotnet #redux

What is Spin | Introducing Spin

Spin is a framework for building and running event-driven microservice applications with WebAssembly (Wasm) components. With Spin, we’re trying to make it easier to get started with using WebAssembly on the server so that we can all take advantage of the security, portability, and speed WebAssembly provides when it comes to running microservices.

Structure of a Spin Application

1. A Spin application manifest (spin.toml) file which defines where your WebAssembly components live and what triggers them.
2. One or more WebAssembly components.

Spin executes the component(s) as a result of events being generated by the trigger(s) defined in the spin.toml file.

Example Spin Application

The following illustrates how to define an HTTP application.

HTTP Handler

This hello_world function written in Rust defines a component that takes a Request and returns a Result<Response>.

#[http_component]​
fn hello_world(_req: Request) -> Result<Response> {​
    Ok(http::Response::builder()​
        .status(200)​
        .body(Some("Hello, Fermyon!".into()))?)​
}​

Spin Manifest

Once the code is compiled to a WebAssembly component, it can be referenced in a spin.toml file to create an HTTP application like below.

spin_version = "1"
name = "spin-hello-world"
trigger = { type = "http", base = "/" }
version = "1.0.0"

[[component]]
id = "hello"
source = "<path to compiled Wasm module>"
[component.trigger]
route = "/hello"

Running a Spin Application

Running this application with the spin CLI is as simple as using the spin up command. Because a trigger type of http is specified in the spin.toml, spin up will start a web server:

$ spin up
Serving HTTP on address http://127.0.0.1:3000
Available Routes:
  hello: http://127.0.0.1:3000/hello

Any time a request is made on the /hello route, it will invoke the hello_world function. Adding another component is as simple as adding another [[component]] stanza to the spin.toml file.

Original article source at https://spin.fermyon.dev/ 

#spin #webapp #microservices #webassembly #wasm 

Rust, WebAssembly & Spin | Building Microservices

Building microservices with WebAssembly, Rust and Spin

In this tutorial, you'll learn how to create fast, secure and portable Microservices with WebAssembly, Rust and Spin. 

Spin is a framework for building and running event-driven microservice applications with WebAssembly (Wasm) components.

With Spin, we’re trying to make it easier to get started with using WebAssembly on the server so that we can all take advantage of the security, portability, and speed WebAssembly provides when it comes to running microservices.

In this session, we will introduce the WebAssembly component model, and how Fermyon uses it together with Rust to create fast, secure, and portable microservices.

#rust #webassembly #wasm #spin #microservice #webapp 

Rust Smart Contract Library for Elrond's VM

elrond-wasm-rs

Rust smart contract library designed for Elrond's VM. Also provides a debugging mode with mocks.

Examples

For examples on how to use the Elrond WASM framework, see https://github.com/ElrondNetwork/elrond-wasm-rs/tree/master/contracts/examples

IDE

The framework is designed to be easiest to use with the Elrond IDE VSCode extension: https://marketplace.visualstudio.com/items?itemName=Elrond.vscode-elrond-ide

Manual build

To build a smart contract without the IDE, run the following command in the contract crate:

./build-wasm.sh

In case this doesn't work, you might not have rustc configured properly. Try:

rustup toolchain install nightly
rustup default nightly
rustup target add wasm32-unknown-unknown

Debugging

Step-by-step debugging of smart contracts is possible in VSCode. To do this, it is required to have a separate debug crate and to have tasks.json and launch.json in .vscode properly configured. See https://github.com/ElrondNetwork/elrond-wasm-rs/tree/master/contracts/examples for examples on how to set this up.

Advanced

To debug macros:

cargo +nightly rustc --bin wasm -- -Z unstable-options --pretty=expanded > demacroed.rs

To check wasm size:

twiggy top -n 20 target/wasm32-unknown-unknown/release/wasm.wasm

Download Details:
Author: ElrondNetwork
Source Code: https://github.com/ElrondNetwork/elrond-wasm-rs
License: GPL-3.0 license

#elrond #rust #wasm  #blockchain  #smartcontract 

Go-canvas: Library to Use HTML5 Canvas From Go-WASM

go-canvas

go-canvas is a pure go+webassembly Library for efficiently drawing on a html5 canvas element within the browser from go without requiring calls back to JS to utilise canvas drawing functions.

The library provides the following features:

• Abstracts away the initial DOM interactions to setup the canvas.
• Creates the shadow image frame, and graphical Context to draw on it.
• Initializes basic font cache for text using truetype font.
• Sets up and handles requestAnimationFrame callback from the browser.

Concept

go-canvas takes an alternate approach to the current common methods for using canvas, allowing all drawing primitives to be done totally with go code, without calling JS.

standard syscall way

In a standard WASM application for canvas, the go code must create a function that responds to requestAnimationFrame callbacks and renders the frame within that call. It interacts with the canvas drawing primitives via the syscall/js functions and context switches. i.e.

laserCtx.Call("beginPath")
laserCtx.Call("arc", gs.laserX, gs.laserY, gs.laserSize, 0, math.Pi*2, false)
laserCtx.Call("fill")
laserCtx.Call("closePath")

Downsides of this approach (for me at least), are messy JS calls which can't easily be checked at compile time, forcing a full redraw every frame, even if nothing changed on that canvas, or changes being much slower than the requested frame rate.

go native way

go-canvas allows all drawing to be done natively using Go by creating an entirely separate image buffer which is drawn to using a 2D drawing library. I'm currently using one from https://github.com/llgcode/draw2d which provides most of the standard canvas primitives and more. This shadow Image buffer can be updated at whatever rate the developer deems appropriate, which may very well be slower than the browsers animation rate.

This shadow Image buffer is then copied over to the browser canvas buffer during each requestAnimationFrame callback, at whatever rate the browser requests. The handling of the callback and copy is done automatically within the library.

Secondly, this also allows the option of drawing to the image buffer, outside of the requestAnimationFrame callback if required. After some testing it appears that it is still best to do the drawing within the requestAnimationFrame callback.

go-canvas provides several options to control all this, and take care of the browser/dom interactions

• User specifies the go render/draw callback method when calling the START function. This callback passes the graphical context to the render routine.
• Render routine can choose to return whether any drawing took place. If it returns false, then the requestAnimationFrame callback does nothing, just returns immediately, saving CPU cycles. (No point to copy buffers and redraw if nothing has changed) This allows the drawing to be adaptive to the rate of data changes.
• The 'start' function accepts a maxFPS parameter. The library will automatically throttle the requestAnimationFrame callback to only do redraws or image buffer copies to this max rate. Note it MAY be slower depending on the Render time, and the requirements of the browser doing other work. When a tab is hidden, the browser regularly reduces and may even stop call to the animation callback. No critical timing should be done in the render/draw routings.
• You may pass 'nil' for the render function. In this case all drawing happens totally under the users control, outside of the library. This may be more useful in future when WASM supports proper threading. Right now however, testing shows it is slower as all work is in the one thread, and you lose the scheduling benefits of the requestAnimationFrame call.

Drawing therefore, is pure go. i.e.

func Render(gc *draw2dimg.GraphicContext) bool {
    // {some movement code removed for clarity, see the demo code for full function}
    // draws red 🔴 laser
    gc.SetFillColor(color.RGBA{0xff, 0x00, 0x00, 0xff})
    gc.SetStrokeColor(color.RGBA{0xff, 0x00, 0x00, 0xff})

    gc.BeginPath()
    gc.ArcTo(gs.laserX, gs.laserY, gs.laserSize, gs.laserSize, 0, math.Pi*2)
    gc.FillStroke()
    gc.Close()
return true  // Yes, we drew something, copy it over to the browser

If you do want to render outside the animation loop, a simple way to cause the code to draw the frame on schedule, independent from the browsers callbacks, is to use time.Tick. An example is in the demo app below.

If however your image is only updated from user input or some network activity, then it would be straightforward to fire the redraw only when required from these inputs. This can be controlled within the Render function, by just returning FALSE at the start. Nothing is draw, nor copied (saving CPU time) and the previous frames data remains.

Known issues !

There is currently a likely race condition for long draw functions, where the requestAnimationFrame may get a partially completed image buffer. This is more likely the longer the user render operation takes. Currently think how best to handle this, ideally without locks. Turns out this is not an issue, due to the single threaded nature. Eventually if drawing is in a separate thread, this will have to be handled.

Demo

A simple demo can be found in: ./demo directory. This is a shameless rewrite of the 'Moving red Laser' demo by Martin Olsansky https://medium.freecodecamp.org/webassembly-with-golang-is-fun-b243c0e34f02

Compile with GOOS=js GOARCH=wasm go build -o main.wasm

Includes a Caddy configuration file to support WASM, so will serve by just running 'caddy' in the demo directory and opening browser to http://localhost:8080

Live

Live Demo available at: https://markfarnan.github.io/go-canvas

Future

This library was written after a weekend of investigation and posted on request for the folks on #webassembly on Gophers Slack.

I intend to extend it further, time permitting, into fully fledged support package for all things go-canvas-wasm related, using this image frame method.

Several of the ideas I'm considering are:

•  Support for layered canvas, at least 3 for 'background', 'action' and 'user interaction'
•  Traps & helper functions for mouse interactions over the canvas
•  Unit tests - soon as I figure out how to do tests for WASM work.
•  Performance improvements in the image buffer copy - https://github.com/agnivade/shimmer/blob/c073303a81ab9a90b6fc14eb6d90c3a1b930025e/load_image_cb.go#L40 has been suggested as a place to start.
•  Detect if nothing has changed for the frame, and if so, don't even recopy the buffer, saving yet more time. May be useful for layers that change less frequently.
•  Multiple draw / render frames to fix the 'incomplete image' problem. -- Not actually a problem
•  Tidy up the close/end frame functionality to properly release resources on page unload and prevent 'browser reload errors' due to missing animation callback function.
•  Update for Go 1.13 and Go Modules
•  Add FPS Calculator metric

Others ? Feedback, suggestions etc. welcome. I can be found on Gophers Slack, #Webassembly channel.

Mark Farnan, February 2020

Author: Markfarnan
Source Code: https://github.com/markfarnan/go-canvas 
License: Apache-2.0 license

#go #golang #canvas #html5 #wasm 

Dia Data Key/Value Oracle Written using Wasm

DIA WASM oracle

This project contains the diadata Key/Value oracle written using wasm, can be deployed to supported substrate chains.

Functions of the wasm oracle

get : Gets the latest value of the asset symbol with timestamp

set : Sets latest value of asset, requires price and timestamp. Can be called only by the owner of contract

setup instructions for cargo contract

https://github.com/paritytech/cargo-contract

Deployed Contract

Network: Astar testnet (Shibuya) : YpfUaqH4zMcEo8Kw1egpPrjAGmBDWu1VVTLEEimXr2Kzevb

Running Oracle Service

Set required environment variables

PRIVATE_KEY=
UNLOCK_PASSWORD=
CONTRACT_ADDRESS=
RPC_ADDRESS=
SYMBOLS=

after setting up environmnet variables run these command to start service

cd oracle
npm run build
npm run start

Download Details:
Author: diadata-org
Source Code: https://github.com/diadata-org/dia-wasm-oracle
License:

#dia #rust  #web3  #defi  #blockchain #wasm #oracle #substrate 

WebAssembly Landscape 2022

WebAssembly Landscape 2022

The technology landscape for Wasm is growing every day. Join me for a tour of WebAssembly, where we will analyze areas of rapid growth for Wasm to predict the future of application development. Wasm is finding a home in every layer of the technical stack. When it comes to creating plugins and adding extensibility to projects, Wasm is rapidly becoming the de facto solution with excellent support for multiple languages. Another trend is serverless where we are seeing Wasm revolutionize application development via actor and event-driven architectures. Looking towards the future, it's not hard to imagine Wasm becoming the default runtime for the entire stack. Imagine applications compiled to Wasm, distributed and networked with a Wasm filter, admitted by a Wasm Open Policy Agent rule, versioned using a Wasm native package manager, Wasm clients that run on any device in the web or edge device, and the expressions used to operate on data are driven by Wasm.

#webassembly #wasm #programming 

What is WebAssembly? It's the Future of Web Development

WebAssembly is the Future of Web Development

Javascript has been around for over 20 years now. It's time for a change. WebAssembly was released in 2017, and is now supported by all major browsers. More and more people are starting to use it. Is a web revolution coming?

WebAssembly — Future of Web Development?

Google Maps is pretty cool, right? You can zoom in at any arbitrary point on the planet or peak at your neighbour’s terrace pool, which you always have been jealous of. All of these can be done right there in your browser. Have you ever wondered how it works?

Streaming an entire globe’s worth of images, data, 3D models so efficiently in your browser is a wonder by itself. How can Google achieve that when most of the websites have trouble even loading those annoying popups? Indeed, this wouldn’t be possible with plain old Javascript.

In a nutshell, the answer is WebAssembly! While most websites use Javascript, HTML, and some server-side framework to load and display data, Google Maps or Google Earth uses Web Assembly to run native binary code on the browser. Web Assembly is faster than any possible web framework or language out there, and in this article, we will dive into its know-how.

History of WebAssembly

Before we learn more about the working of WebAssembly, first let’s understand why it was created. It all started when a team of developers in Mozilla in 2015 worked to make Javascript more efficient to support heavy applications like Video Games on the web. In this process, they created WebAssembly, which was initially demonstrated to execute Unity’s Angry Bots game on the web.

So what is WebAssembly?

Let’s look at the description given on the official website of web assembly:

‘WebAssembly (abbreviated Wasm) is a binary instruction format for a stack-based virtual machine. Wasm is designed as a portable compilation target for programming languages, enabling deployment on the web for client and server applications.’

In simpler terms, WebAssembly is a new type of code, which is written in .wasm format and is very close to Machine language. The Wasm file is converted into a binary instruction (file written in 0s and 1s) and then compiled and rendered on the webpage. Since the WebAssembly file is very similar to C or Machine Language, it is fast in execution, which makes it a powerful tool for running heavy applications like Video Games, Video Files, 3D models, Porting Desktop Applications, etc.,

This has a massive impact on the way websites made. WebAssembly allows you to run programs written in various languages like C++, Rust, Python, Java, etc., on the web with near-native speeds. Developers are no longer restricted to the usage of the Javascript language to make web applications.

WebAssembly is statically typed, uses linear memory, and is stored in binary format. All of these features allow wasm files to be rendered on the web at near-native speed, i.e., the speed you would get if you run the program on a command line. That’s amazing, right? What’s more impressive is that now you are not restricted to the usage of only JS based libraries. The ability to support existing tools and libraries to use in the browser and the associated potential support for speedup is the main features that make WebAssembly so enthralling.

JavaScript and WebAssembly

The above diagram shows how a typical JS code is parsed and rendered on the web. JavaScript is a dynamically typed language in which variable types don’t need to be mentioned upfront or compiled ahead. It does make JS really easy to use and write, but the obvious drawback is that the JS engine has to do a lot more work to make the code work. It has to parse, compile, and optimize the code as it’s being run. On the other hand, WebAssembly is a statically typed code, which means, unlike JS, the engine doesn’t need to speculate during compilation about what types the various variables have. Most of the optimization is also done during the compilation period before it even reaches the browser. Memory is managed manually, just like in languages C/C++. All of these give much better performance and reliability.

So, the question now emerges that is WebAssembly the perfect replacement for JavaScript?

Well, the answer is ‘not exactly.’ WebAssembly was never created to replace or compete with JavaScript. It was an additional tool which was designed to improve the web platform by making it more powerful. It is intended to complement JS language and allowing developers to take advantage of multiple languages.

It is also not necessarily true that JavaScript is slow in all cases.

“What?? But till now, you were telling WebAssembly is faster!”

Yes, I have, but let’s understand this in more detail.

In most cases, the total Web Assembly files are more extensive than JS files (without even considering that JS files can be mainly compressed). This means that if you have a slower internet connection, then JavaScript will run faster for you. The situation may change if you are working with an extensive application in which WebAssembly is faster.

Once the WebAssembly files are cached in the browser, they load faster than the corresponding JS code, but the gain is meagre. The reason for this low gain is that JavaScript code loads and starts very quickly. WebAssembly (compiled with full optimization) is not always faster than JavaScript during execution, and when WebAssembly is faster, the gain can be small.

There might be specific tasks for which you are searching libraries in JS but not might find one. But these libraries might be present in C/C++, Rust, etc. So, WebAssembly will help tap into the new language environment.

If you find a gap in the web platform that has been filled many times in another language but not on the web or not in JS, Web Assembly might be your saviour.

Both JS and WebAssembly have the same peak performance. They are equally fast. But, it is easier to stay on the fast path with WebAssembly than it is with JS. This is primarily because of the way the WebAssembly engine works.

That’s why WebAssembly is an additional tool to go alongside JavaScript rather than its replacement.

Let’s build our first WebAssembly App!

So, after reading about WebAssembly and learning about its know-how, let’s build a simple Todo List application using WebAssembly.

For this tutorial, I will use Blazor WebAssembly, a client-side library that uses the .NET framework to build interactive Web UIs with C# instead of JavaScript.

Requirements for this project: .NET 5.0 SDK or later installed on your OS.

First, we need to make a basic structure for our web assembly project. Fortunately, Blazor provides a straightforward way to do so.

Just move to the directory where you want to create your project and open a new command line terminal in that folder. In the command line, write the following code. (Make sure you have .NET 5.0 SDK or later installed in your system)

‘dotnet new blazorserver -o TodoList’

Here the preceding name ‘TodoList’ is the name of your root directory for the project. Change directories to the TodoList folder using the command,

 cd TodoList

We want to create a new Razor component in the Pages folder (Razor is a markup syntax that lets you embed server-side code written in C# on web pages). Write the following command in your command line.

‘dotnet new razorcomponent -n Todo -o Pages’

This command will create a new Todo.razor file in the Pages folder of your project. Now let’s add our Todo component to our Navbar. Navigate to Shared/NavMenu.razor and open the NavMenu component file.

In the NavMenu.razor file, add the following block of code.

<li class="nav-item px-3">
    <NavLink class="nav-link" href="todo">
        <span class="oi oi-list-rich" aria-hidden="true"></span> Todo
    </NavLink>
</li>

In the above code, we add a NavLink for our Todo Component. Save this file. Now try to build and run this basic structure initially. In your command line, go to the root directory of your project (TodoList in this case) and type the command:

dotnet watch run

It will open your web application on the route https://localhost:5001. To Navigate to Todo Component, click on the TodoList option on the sidebar. Your web application should look like this till now:

As you can see, the Todo page is empty because we haven’t yet added any TodoItem. So let’s create a file in our root directory (TodoList in this case) called TodoItem.cs. Type the following C# code for the TodoItem class:

public class TodoItem
{
    public string Title { get; set; }
    public bool IsDone { get; set; }
}

Return to the Todo component (Pages/Todo.razor). Then a field for the todo items in an ‘@code’ block. The Todo component uses this field to maintain the state of the todo list. After that add an unordered list markup and a foreach loop to render each todo item as a list item (<li>).

@page "/todo"

<h3>Todo</h3>

<ul>
    @foreach (var todo in todos)
    {
        <li>@todo.Title</li>
    }
</ul>

@code {
    private IList<TodoItem> todos = new List<TodoItem>();
}

Our website will also require a UI element for adding the todo items to the list. So, add a text input and a button below the unordered list.

@page "/todo"

<h3>Todo</h3>

<ul>
    @foreach (var todo in todos)
    {
        <li>@todo.Title</li>
    }
</ul>
<!-- Input fields for adding new Todo Items -->
<input placeholder="Something todo" />
<button>Add todo</button>

Save the TodoItem.cs file and the updated Pages/Todo.razor file. As you can see in the command line, the web page automatically updates as you save any file in your project. The browser temporarily loses its connection to the app and then reloads the page when the connection is re-established.

As of now, the Add Todo button does nothing because we haven’t attached any event handler with the button. So, let’s do that.

Add an AddTodo method to the Todo component and register it for button selections using the @onclick attribute. The AddTodo C# method is called when the button is selected.

To get the new todo item’s title, add a newTodo string field at the top of the @code block and bind it to the text input value using the bind attribute in the <input> element.

Update the AddTodo method to add the TodoItem with the specified title to the list. Clear the value of the text input by setting newTodo to an empty string.

<input placeholder="Something todo" @bind="newTodo" />
<button @onclick="AddTodo">Add todo</button>

@code {
    private IList<TodoItem> todos = new List<TodoItem>();
    private string newTodo;

    private void AddTodo()
    {
        if (!string.IsNullOrWhiteSpace(newTodo))
        {
            todos.Add(new TodoItem { Title = newTodo });
            newTodo = string.Empty;
        }
    }
}

Now, if we suppose complete any task from our Todos list, we should have an option to delete them, right? So, let’s add that functionality. We will keep a checkbox to track whether the task is completed or not.

To do that, add a check box input for each todo item and bind its value to the IsDone property. Change @todo.Title to an <input> element bound to @todo.Title.

<ul>
    @foreach (var todo in todos)
    {
        <li>
            <input type="checkbox" @bind="todo.IsDone" />
            <input @bind="todo.Title" />
        </li>
    }
</ul>

How would we check whether the above conditions work or not? A straightforward solution is to add an option alongside the heading, which shows the number of todo items that aren’t complete.

<h3>Todo (@todos.Count(todo => !todo.IsDone))</h3>

The completed Todo component (Pages/Todo.razor) will look something like this:

@page "/todo"

<h3>Todo (@todos.Count(todo => !todo.IsDone))</h3>

<ul>
    @foreach (var todo in todos)
    {
        <li>
            <input type="checkbox" @bind="todo.IsDone" />
            <input @bind="todo.Title" />
        </li>
    }
</ul>

<input placeholder="Something todo" @bind="newTodo" />
<button @onclick="AddTodo">Add todo</button>

@code {
    private IList<TodoItem> todos = new List<TodoItem>();
    private string newTodo;

    private void AddTodo()
    {
        if (!string.IsNullOrWhiteSpace(newTodo))
        {
            todos.Add(new TodoItem { Title = newTodo });
            newTodo = string.Empty;
        }
    }
}

And the final Site looks like this:

Hurray!! You made your first Web Assembly project. See, that wasn’t hard, right? Okay, Now it is the end of the article but the start of your learning journey into this amazing and powerful technology that would revolutionize the way we use our web. Do check out the resources given below to learn more about Web Assembly.

#javascript #webassembly #wasm #webdev 

resvg-js 2.0: A High-Performance SVG Renderer and Toolkit

resvg-js

resvg-js is a high-performance SVG renderer and toolkit, powered by Rust based resvg and napi-rs.

Features

• Fast, safe and zero dependencies.
• Convert SVG to PNG, includes cropping, scaling and setting the background color.
• Support system fonts and custom fonts in SVG text.
• v2: Gets the width and height of the SVG and the generated PNG.
• v2: Support for outputting simplified SVG strings, such as converting shapes(rect, circle, etc) to <path>.
• v2: Support WebAssembly.
• No need for node-gyp and postinstall, the .node file has been compiled for you.
• Cross-platform support, including Apple M1.

Installation

Node.js

npm i @resvg/resvg-js

Browser(Wasm)

<script src="https://unpkg.com/@resvg/resvg-wasm"></script>

Example

This example will load Source Han Serif, and then render the SVG to PNG.

node example/index.js

Loaded 1 font faces in 0ms.
Font './example/SourceHanSerifCN-Light-subset.ttf':0 found in 0.006ms.
✨ Done in 55.65491008758545 ms

SVG	PNG
CC BY 3.0: Niabot	CC BY 3.0: Niabot

Usage

Node.js

const { promises } = require('fs')
const { join } = require('path')
const { Resvg } = require('@resvg/resvg-js')

async function main() {
  const svg = await promises.readFile(join(__dirname, './text.svg'))
  const opts = {
    background: 'rgba(238, 235, 230, .9)',
    fitTo: {
      mode: 'width',
      value: 1200,
    },
    font: {
      fontFiles: ['./example/SourceHanSerifCN-Light-subset.ttf'], // Load custom fonts.
      loadSystemFonts: false, // It will be faster to disable loading system fonts.
      defaultFontFamily: 'Source Han Serif CN Light',
    },
  }
  const resvg = new Resvg(svg, opts)
  const pngData = resvg.render()
  const pngBuffer = pngData.asPng()

  console.info('Original SVG Size:', `${resvg.width} x ${resvg.height}`)
  console.info('Output PNG Size  :', `${pngData.width} x ${pngData.height}`)

  await promises.writeFile(join(__dirname, './text-out.png'), pngBuffer)
}

main()

WebAssembly

Although we support the use of Wasm packages in Node.js, this is not recommended. The native addon performs better.

Browser

<script src="https://unpkg.com/@resvg/resvg-wasm"></script>
<script>
  ;(async function () {
    // The Wasm must be initialized first
    await resvg.initWasm(fetch('https://unpkg.com/@resvg/resvg-wasm/index_bg.wasm'))
    const opts = {
      fitTo: {
        mode: 'width', // If you need to change the size
        value: 800,
      },
    }

    const svg = '<svg> ... </svg>' // Input SVG, String or Uint8Array
    const resvgJS = new resvg.Resvg(svg, opts)
    const pngData = resvgJS.render(svg, opts) // Output PNG data, Uint8Array
    const pngBuffer = pngData.asPng()
    const svgURL = URL.createObjectURL(new Blob([pngData], { type: 'image/png' }))
    document.getElementById('output').src = svgURL
  })()
</script>

See playground, it is also possible to call Wasm in Node.js, but there is a performance penalty and this is not recommended.

Benchmark

Running "resize width" suite...
  resvg-js(Rust):
    12 ops/s, ±22.66%   | fastest 🚀

  sharp:
    9 ops/s, ±64.52%    | 25% slower

  skr-canvas(Rust):
    7 ops/s, ±3.72%    | 41.67% slower

  svg2img(canvg and node-canvas):
    6 ops/s, ±16.94%    | slowest, 50% slower

Support matrix

	node12	node14	node16	npm
Windows x64	✓	✓	✓
Windows x32	✓	✓	✓
Windows arm64	✓	✓	✓
macOS x64	✓	✓	✓
macOS arm64(M1)	✓	✓	✓
Linux x64 gnu	✓	✓	✓
Linux x64 musl	✓	✓	✓
Linux arm gnu	✓	✓	✓
Linux arm64 gnu	✓	✓	✓
Linux arm64 musl	✓	✓	✓
Android arm64	✓	✓	✓
Android armv7	✓	✓	✓

Test or Contributing

• Install latest Rust
• Install Node.js@10+ which fully supported Node-API
• Install wasm-pack

curl https://rustwasm.github.io/wasm-pack/installer/init.sh -sSf | sh

Build Node.js bindings

npm i
npm run build
npm test

Build WebAssembly bindings

npm i
npm run build:wasm
npm run test:wasm

Roadmap

I will consider implementing the following features, if you happen to be interested, please feel free to discuss with me or submit a PR.

•  Support async API
•  Upgrade to napi-rs v2
•  Support WebAssembly
•  Output usvg-simplified SVG string
•  Support for getting SVG Bounding box
•  Support for generating more lossless bitmap formats, e.g. avif, webp, JPEG XL

Release package

We use GitHub actions to automatically publish npm packages.

# 1.0.0 => 1.0.1
npm version patch

# or 1.0.0 => 1.1.0
npm version minor

Download Details: 
Author: yisibl
Source Code: https://github.com/yisibl/resvg-js 
License: MPL-2.0 license
#nodejs #svg #rust #wasm #node 

WASM Light Client bundled Substrate Wallet for Balance Transfers

Lichen (working title, previously "Substrate Light UI")

Lichen is a light-client-based, in-browser wallet for Substrate.

The Light UI is meant to be an intuitive interface for beginner users to easily interact with various Substrate chains. It is provided in two forms:

• A Chrome/Firefox browser extension
• A desktop application, built with Electron

Both provide the same functionalities and use the same UI, feel free to choose the medium that suits you best.

A very alpha version of the browser extension can be found in the Github Releases page.

You can also check out the master branch and build from source.

Overview

As of v0.3.0, the main functions are as follows:

•  Identity management - manage accounts and addresses, including ability to create, edit, restore, backup, and forget them.
•  Transfer balance - send and receive funds in the currency of the relevant substrate chain.
•  Embed a light client in a browser extension, and let Light UI be the user interface of this extension.

And here is a rough roadmap of what's coming next (see the v0.4.0-MVP milestone for details):

•  Handle changing:
  •  provider,
  •  chain spec,
  •  user uploaded light client WASM blob or chain spec.
•  Provider injection inside dapps.
•  Improve overall beginner-friendliness (e.g. #67).

Build from sources

Dependencies

Make sure you have yarn >= 1.13.0 and nodejs >= 10.10.0. Then run

git clone https://github.com/paritytech/substrate-light-ui
cd ./substrate-light-ui
yarn install

Run the Browser Extension

yarn build:extension

Then install the extension:

• Chrome:
  • go to chrome://extensions/
  • ensure you have the Development flag set
  • "Load unpacked" and point to packages/extension-app/build
  • if developing, after making changes - refresh the extension
• Firefox:
  • go to about:debugging#addons
  • check "Enable add-on debugging"
  • click on "Load Temporary Add-on" and point to packages/extension-app/build/manifest.json
  • if developing, after making changes - reload the extension

Run the Electron App

For now, you need to bundle a Substrate node manually into the Electron app. To do so, first build a Substrate node for your platform (note: it can of course be a Polkadot/Kusama node, or any other Substrate node), and copy it as ./packages/electron-app/static/substrate:

cp /path/to/polkadot ./packages/electron-app/static/substrate

Then run:

yarn build:electron

The building might take some time, but you should see an Electron application after a while.

Troubleshooting: If it hangs on a white screen in Electron even though it has compiled and has been syncing for a long time, then simply choose 'View > Reload' (CMD + R on macOS) from the Electron menu.

Contributing

We welcome any and all contributions whether it is in the form of raising an issue, filing a PR, or participating in the discussions. Please read the Contributing Docs first.

Run with Hot-Reloading

If you would like to run this project with hot-reloading, use the following commands:

• yarn start:ui: If you would only like to modify the UI, run this command and visit http://localhost:3000
• yarn start:electron: Run the Electron app with hot reloading

Download Details:
Author: paritytech
Source Code: https://github.com/paritytech/substrate-light-ui
License: Apache-2.0 License

#blockchain #javascript #typescript  #polkadot  #smartcontract  #substrate #wasm 

Llvm fork to Experiment with Code Size Optimizations For Wasm

The LLVM Compiler Infrastructure

This directory and its sub-directories contain source code for LLVM, a toolkit for the construction of highly optimized compilers, optimizers, and run-time environments.

The README briefly describes how to get started with building LLVM. For more information on how to contribute to the LLVM project, please take a look at the Contributing to LLVM guide.

Getting Started with the LLVM System

Taken from https://llvm.org/docs/GettingStarted.html.

Overview

Welcome to the LLVM project!

The LLVM project has multiple components. The core of the project is itself called "LLVM". This contains all of the tools, libraries, and header files needed to process intermediate representations and convert them into object files. Tools include an assembler, disassembler, bitcode analyzer, and bitcode optimizer. It also contains basic regression tests.

C-like languages use the Clang front end. This component compiles C, C++, Objective-C, and Objective-C++ code into LLVM bitcode -- and from there into object files, using LLVM.

Other components include: the libc++ C++ standard library, the LLD linker, and more.

Getting the Source Code and Building LLVM

The LLVM Getting Started documentation may be out of date. The Clang Getting Started page might have more accurate information.

This is an example work-flow and configuration to get and build the LLVM source:

Checkout LLVM (including related sub-projects like Clang):

git clone https://github.com/llvm/llvm-project.git

Or, on windows, git clone --config core.autocrlf=false https://github.com/llvm/llvm-project.git

Configure and build LLVM and Clang:

cd llvm-project

cmake -S llvm -B build -G <generator> [options]

Some common build system generators are:

• Ninja --- for generating Ninja build files. Most llvm developers use Ninja.
• Unix Makefiles --- for generating make-compatible parallel makefiles.
• Visual Studio --- for generating Visual Studio projects and solutions.
• Xcode --- for generating Xcode projects.

-DLLVM_ENABLE_PROJECTS='...' --- semicolon-separated list of the LLVM sub-projects you'd like to additionally build. Can include any of: clang, clang-tools-extra, libcxx, libcxxabi, libunwind, lldb, compiler-rt, lld, polly, or debuginfo-tests.

For example, to build LLVM, Clang, libcxx, and libcxxabi, use -DLLVM_ENABLE_PROJECTS="clang;libcxx;libcxxabi".

-DCMAKE_INSTALL_PREFIX=directory --- Specify for directory the full path name of where you want the LLVM tools and libraries to be installed (default /usr/local).

-DCMAKE_BUILD_TYPE=type --- Valid options for type are Debug, Release, RelWithDebInfo, and MinSizeRel. Default is Debug.

-DLLVM_ENABLE_ASSERTIONS=On --- Compile with assertion checks enabled (default is Yes for Debug builds, No for all other build types).

cmake --build build [-- [options] <target>] or your build system specified above directly.

The default target (i.e. ninja or make) will build all of LLVM.

The check-all target (i.e. ninja check-all) will run the regression tests to ensure everything is in working order.

CMake will generate targets for each tool and library, and most LLVM sub-projects generate their own check-<project> target.

Running a serial build will be slow. To improve speed, try running a parallel build. That's done by default in Ninja; for make, use the option -j NNN, where NNN is the number of parallel jobs, e.g. the number of CPUs you have.

For more information see CMake

Consult the Getting Started with LLVM page for detailed information on configuring and compiling LLVM. You can visit Directory Layout to learn about the layout of the source code tree.

Download Details:
Author: paritytech
Source Code: https://github.com/paritytech/llvm-wasm-codesize
License:

#blockchain  #polkadot  #smartcontract  #substrate #wasm 

Instrument and Transform Wasm Modules for Polkadot

wasm-instrument

A Rust library containing a collection of wasm module instrumentations and transformations mainly useful for wasm based block chains and smart contracts.

Provided functionality

This is a non exhaustive list of provided functionality. Please check out the documentation for details.

Gas Metering

Add gas metering to your platform by injecting the necessary code directly into the wasm module. This allows having a uniform gas metering implementation across different execution engines (interpreters, JIT compilers).

Stack Height Limiter

Neither the wasm standard nor any sufficiently complex execution engine specifies how many items on the wasm stack are supported before the execution aborts or malfunctions. Even the same execution engine on different operating systems or host architectures could support a different number of stack items and be well within its rights.

This is the kind of indeterminism that can lead to consensus failures when used in a blockchain context.

To address this issue we can inject some code that meters the stack height at runtime and aborts the execution when it reaches a predefined limit. Choosing this limit suffciently small so that it is smaller than what any reasonably parameterized execution engine would support solves the issue: All execution engines would reach the injected limit before hitting any implementation specific limitation.

Contribution

Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in wasm-instrument by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any additional terms or conditions.

Download Details:
Author: paritytech
Source Code: https://github.com/paritytech/wasm-instrument
License: View license

#blockchain  #polkadot  #smartcontract  #substrate #wasm