spec
deno
Our great sponsors
spec | deno | |
---|---|---|
12 | 448 | |
3,061 | 92,907 | |
0.8% | 0.5% | |
8.3 | 9.9 | |
6 days ago | 4 days ago | |
WebAssembly | Rust | |
GNU General Public License v3.0 or later | MIT License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
spec
-
WASM Instructions
You can parse many things from this file, what are you trying to extract?
https://github.com/WebAssembly/spec/blob/main/document/core/...
-
The fastest word counter in JavaScript
Still strikes me as super sad JS never got SIMD support. It seemed like there were some strong candidate specs. On Node there are some add-on npm libraries that implement.
My understanding was the main protest was that we would get wasm & some certain implementers said they wanted to focus their energy on wasm.
That was well over half a decade ago & wasm is still in incredible infancy, with basically only statically linked capabilities in the spec.
Wasm SIMD proposal itself only merged into wasm in November 2021. https://github.com/WebAssembly/spec/pull/1391
It seems really unfortunate to have decided to keep JS the slow inferior language.
-
Is Blazor server and Blazor Webassembly going to be a big market? I am trying to figure out a niche to go with and I have some asp.net core mvc experience but I am working on a e-commerce .net6 Blazor Webassembly app.
Blazor and WASM itself (outside of dotnet) are relatively new tools and they already show impressive results. They will keep getting better with every release. E.g. this proposal https://github.com/WebAssembly/spec/blob/main/proposals/simd/SIMD.md which should bring WASM closer to "near native speed". Blazor already started working on it true.
-
Smolnes: A NES Emulator In
Big fan of this author's work.
They have a Gameboy emulator written in C, which can be compiled to WASM and run in the browser.
https://github.com/binji/binjgb
I learned a lot from the code.
Also I love this project with a bunch of demos in hand-written WebAssembly Text (WAT) format, which is like low-level Lisp that works only with raw memory, numbers, and minimal syntax.
https://github.com/binji/raw-wasm
Then I discovered the same author is quite active in the WebAssembly ecosystem, including specs and tooling. Fascinating stuff!
https://github.com/WebAssembly/spec
https://github.com/WebAssembly/wabt
-
Exploring WebAssembly, The Underlying Technology Behind Blazor WASM.
[The WebAssembly specification (https://webassembly.github.io/spec/) maintains that the standards apply to more than just the browser host, but also to any other compliant host runtime (what the specification refers to as an embedder).
-
Show HN: We are trying to (finally) get tail-calls into the WebAssembly standard
Heya,
(1) Thank you for implementing this in JSC!! I hope they take it, it makes it into Safari, and the tail-call proposal advances.
(2) I don't think you are exactly right about the call stack being observable via thrown exceptions. There's no formal spec for the v3 exceptions proposal yet, but in the documents and tests, there's nothing that would change in WebAssembly core to make the call stack observable. It's true that the proposal amends the JS API (but only the JS API) to describe a traceStack=true option; from Wasm's perspective I understand that's just an ordinary exception that happens to include an externref value (just like any other value) to which Wasm itself attaches no special significance. The engine can attach a stack trace if it wants, but there's no requirement (here) about what that stack trace contains or whether some frames might have been optimized out.
(3) I think the real reason that a Wasm engine can't implicitly make tail calls proper is that the spec tests forbid it, basically because they didn't want the implementation base to split by having some engines perform an optimization that changes the space complexity of a program, which some programs would have started to depend on (the spec tests say: "Implementations are required to have every call consume some abstract resource towards exhausting some abstract finite limit, such that infinitely recursive test cases reliably trap in finite time. This is because otherwise applications could come to depend on it on those implementations and be incompatible with implementations that don't do it (or don't do it under the same circumstances.)" More discussion here: https://github.com/WebAssembly/spec/issues/150
- WebAssembly 2.0 Working Draft
- A challenger to the throne of vector graphics. SVG is dead, long live TinyVG
-
Microsoft joins Bytecode Alliance to advance WebAssembly – aka the thing that lets you run compiled C/C++/Rust code in browsers
The WASM paper discusses that in the final section: https://github.com/WebAssembly/spec/blob/master/papers/pldi2017.pdf
-
Is there a small, well-specified language with lots of example programs?
WebAssembly has a formal specification that includes both operational semantics and natural language-based descriptions of everything in the language. The official repository also has a lot of tests. Besides tests, you should be able to find lots of examples by searching.
deno
-
Bun - The One Tool for All Your JavaScript/Typescript Project's Needs?
NodeJS is the dominant Javascript server runtime environment for Javascript and Typescript (sort of) projects. But over the years, we have seen several attempts to build alternative runtime environments such as Deno and Bun, today’s subject, among others.
-
Bun 1.1
https://github.com/denoland/deno/issues is the ideal place -- we try to triage all incoming issues, the more specific the repro the easier it is to address but we will take a look at everything that comes in.
-
I have created a small anti-depression script
Install Node.js (or Bun, or Deno, or whatever JS runtime you prefer) if it's not there
-
How QUIC is displacing TCP for speed
QUIC is very exciting, after seeing what it can do for performance in Cloudflare network and Cloudflare workers, I can't wait to finally see it in Deno[0] 1.41.
[0] https://github.com/denoland/deno/pull/21942#issuecomment-192...
-
Unison Cloud
So as an end user it's kind of like https://deno.com/ where you buy into a runtime + comes prepacked with DBs (k/v stores), scheduling, and deploy stuff?
> by storing Unison code in a database, keyed by the hash of that code, we gain a perfect incremental compilation cache which is shared among all developers of a project. This is an absolutely WILD feature, but it's fantastic and hard to go back once you've experienced it. I am basically never waiting around for my code to compile - once code has been parsed and typechecked once, by anyone, it's not touched again until it's changed.
Interesting. Whats it like upgrading and managing dependencies in that code? I'd assume it gets more complex when it's not just the Union system but 3rd party plugins (stuff interacting with the OS or other libs).
-
Deno in 2023
~90MB+ at this stage and do now allow compression without erroring out. Deploying ala Golang is not feasible at that level but could well be down the line if this dev branch is picked up again!
The exe output grew from from ~50MB to plus ~90MB from 2021 to 2024: https://github.com/denoland/deno/discussions/9811 which mean Deno is worse than Node.js's pkg solution by a decent margin.
-
Mini site for recommending songs using Svelte & Deno
Behind the scenes is a simple Sveltekit-powered server function to fetch a Spotify client token then find a user's recommendation playlist and its track information. A Deno edge function to performs this data fetch and renders server-side Svelte.
-
Supercharge your app with user extensions using Deno JavaScript runtime
If your application is written in JavaScript, integrating it with JavaScript extensions is a no-brainer. However, Secutils.dev is entirely written in Rust. How would I even begin? Fortunately, I recently came across an excellent blog post series explaining how to implement your JavaScript runtime in a Rust application with Deno:
- Deno, the next-generation JavaScript runtime
- Oxlint – written in Rust – 50-100 Times Faster than ESLint
What are some alternatives?
uwm-masters-thesis - My thesis for my Master's in Computer Science degree from the University of Wisconsin - Milwaukee.
ASP.NET Core - ASP.NET Core is a cross-platform .NET framework for building modern cloud-based web applications on Windows, Mac, or Linux.
Oberon - Oberon parser, code model & browser, compiler and IDE with debugger
typescript-language-server - TypeScript & JavaScript Language Server
meetings - WebAssembly meetings (VC or in-person), agendas, and notes
pnpm - Fast, disk space efficient package manager
component-model - Repository for design and specification of the Component Model
esbuild - An extremely fast bundler for the web
proposals - Tracking WebAssembly proposals
bun - Incredibly fast JavaScript runtime, bundler, test runner, and package manager – all in one
wit-bindgen - A language binding generator for WebAssembly interface types
Koa - Expressive middleware for node.js using ES2017 async functions