abuldauskas

I also noticed it. On million-points. MacBook Pro M2 on Firefox Nightly 148.0a1 (2026-01-09) (aarch64)

I don't really understand how this approach breaks what you are describing.

All I'm saying is that instead of hooks API being imported from React at global scope it could be provided as inputs into the components directly. They would still exist in the function body as you put it.

My only issue with Hooks has been that they are not inputs into the component. It's a step in the right direction of making React more functional I would just preferred less magic, personally.

  function Component(props, { useState, useContext }) { ... }

Node 11 now comes with v8 v7.0, does this mean Webassembly threads are supported? Or are they behind a flag?

I have not, this has been requested quite a bit though. My focus is currently on making sure the toolchain is stable and performant itself. It's likely that the performance of the compiled code is on par with other wasm vs JS comparisons though.

That's the thing though. We are all "us" here. We can all compile whatever we want to WebAssembly, that's the point of WebAssembly. One way of doing things doesn't take away from another.

Escaping JavaScript is not a perspective shared by all (most?), though.

It's has been a weird and interesting project, but that's not really a bad thing is it.

I wrote/maintain Walt. This question comes up a bunch.

The two projects are really similar no doubt. I can't speak for AssemblyScript, but my own motivation was simple. I wanted to learn WebAssembly and I wanted an accessible platform to do so with. At the time this wasn't really possible, tools like emscripten took forever to set up and were clunky to use. Plus I knew C already, I wanted to learn WebAssembly instead.

So where Walt is an attempt to write WebAssembly with a familiar syntax, AssemblyScript is an attempt to compile TypeScript to WebAssembly. To do so AssemblyScript comes with many more niceties/features out of the box IIRC, like optional(?) GC for example. Walt makes no such attempts and takes a more DIY approach.

Walt also has language extensions, via customizable syntax and compiler pipeline, where AssemblyScript is a TypeScript compiler more or less. My hope is that this allows for a babel-like situation for WebAssembly in the future via the tooling setup for Walt. I don't think this is a goal of AssemblyScript.

One of my major pain points with GitLab was its API. The lack of coherent API design ultimately made me lose hope in the product. For example I think it still lacks an ability to create threads on MRs. Until recently it wasn't possible to approve any MRs either, for 10+ versions of the product and 4+ versions of the api, but adding emoji was... The disjointed API made it nearly impossible to create quality tooling on top of GitLab, ultimately forcing us away from the product. It left a poor taste in my mouth, with a sense that there was no rhyme or reason to the direction of the platform, unfortunately.