shared-everything-threads
biome
shared-everything-threads | biome | |
---|---|---|
2 | 23 | |
18 | 10,694 | |
- | 11.0% | |
7.2 | 9.9 | |
3 days ago | 4 days ago | |
WebAssembly | Rust | |
GNU General Public License v3.0 or later | Apache License 2.0 |
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.
shared-everything-threads
-
Prettier $20k Bounty was Claimed
The roadmap I linked above. The WASI folks have done a poor job at communicating, no doubt, but I'm surprised someone like yourself literally building a competitor spec isn't following what they are doing closely.
Just for you I did some googling: see here[0] for the current status of WASI threads overall, or here[1] and here[2] for what they are up to with WASI in general. In this PR[3] you can see they enabled threads (atomic instructions and shared memory, not thread creation) by default in wasmtime. And in this[4] repository you can see they are actively developing the thread creation API and have it as their #1 priority.
If folks want to use WASIX as a quick and dirty hack to compile existing programs, then by all means, have at it! I can see that being a technical win. Just know that your WASIX program isn't going to run natively in wasmtime (arguably the best WASM runtime today), nor will it run in browsers, because they're not going to expose WASIX - they're going to go with the standards instead. so far you're the only person I've met that thinks exposing POSIX fork() to WASM is a good idea, seemingly because it just lets you build existing apps 'without modification'.
Comical you accuse me of being polarizing, while pushing for your world with two competing WASI standards, two competing thread creation APIs, and a split WASM ecosystem overall.
[0] https://github.com/bytecodealliance/jco/issues/247#issuecomm...
[1] https://bytecodealliance.org/articles/wasmtime-and-cranelift...
[2] https://bytecodealliance.org/articles/webassembly-the-update...
[3] https://github.com/bytecodealliance/wasmtime/pull/7285
[4] https://github.com/WebAssembly/shared-everything-threads
-
WASI Support in Go
The answer is: it's complicated. Which is most of the time the answer in the WASI world.
For this case it's complicated because some runtime supports https://github.com/WebAssembly/threads which mostly contains things like the spec for atomic but not the actual "threads" specs and then some runtimes (i.e wasmtime) also supports https://github.com/WebAssembly/wasi-threads which is one version of the threads. But a new proposal came into play https://github.com/abrown/thread-spawn so ... it's complicated.
biome
-
I switch from Eslint to Biome
{ "$schema": "https://biomejs.dev/schemas/1.7.0/schema.json", "organizeImports": { "enabled": true }, "files": { "ignore": ["package.json", "package-lock.json"] }, "linter": { "enabled": true, "rules": { "recommended": true, "style": { "noUnusedTemplateLiteral": "off" } } }, "formatter": { "indentStyle": "space", "indentWidth": 4, "lineWidth": 320 }, "javascript": { "formatter": { "semicolons": "asNeeded" } } }
- Fast, Declarative, Reproduble and Composable Developer Environments Using Nix
- Biome – fast JavaScript linter and formatter
-
What is the most useful project you've ever worked on?
It is great to see that so many users are enthusiastic about Biome. It is really gratifying to work on a project that is appreciated and useful to the community.
[0] https://biomejs.dev/
- Biomejs.dev (previously Rome-tools by Meta)
-
Build a Vite 5 backend integration with Flask
Once you build a simple Vite backend integration, try not to complicate Vite's configuration unless you absolutely must. Vite has become one of the most popular bundlers in the frontend space, but it wasn't the first and it certainly won't be the last. In my 7 years of building for the web, I've used Grunt, Gulp, Webpack, esbuild, and Parcel. Snowpack and Rome came-and-went before I ever had a chance to try them. Bun is vying for the spot of The New Hotness in bundling, Rome has been forked into Biome, and Vercel is building a Rust-based Webpack alternative.
-
Why is Prettier rock solid?
> My only bad experience with prettier, besides the incredible slowness (orders of magnitude slower than ruff)
Ruff is based on the same foundations that Biome (https://biomejs.dev/). Although Biome doesn't support all languages that Prettier supports, you should give a try, it is fast.
- RFC: Biome Plugins
-
BiomeJS 2024 Roadmap
I am also confused by this goal, I've started a discussion in the repo to get some clarity on intent and direction there: https://github.com/biomejs/biome/discussions/1642
-
Tailwind CSS: Automatic Class Sorting with Prettier
Biome [0], a fast Prettier-compatible formatter, is currently working on adding class sorting [1]. We expect to ship the feature with the next release (on February). We are discussing which options to provide for the feature (mainly on the Discord of Biome).
[0] https://biomejs.dev/
What are some alternatives?
prettier-plugin-curly - Prettier plugin to enforce consistent brace style for all control statements. 🥌
prettier - Prettier is an opinionated code formatter.
proposals - Tracking WebAssembly proposals
rspack - A fast Rust-based web bundler 🦀️
awesome-eslint - A list of awesome ESLint plugins, configs, etc.
tools - Unified developer tools for JavaScript, TypeScript, and the web
wasi-threads
prettier-plugin-sort-imports - A prettier plugin to sort imports in typescript and javascript files by the provided RegEx order.
prettier-rpc - Single-file build of prettier with JSON-RPC communication
jest - Delightful JavaScript Testing.
tsc-files - A tiny tool to run `tsc` on specific files without ignoring tsconfig.json
ava - Node.js test runner that lets you develop with confidence 🚀