HN user
https://github.com/yuri91
if anyone is curious about the technical details, I recently gave a talk about BrowserPod's architecture at the Wasm I/O conference. The recordings of the talks are being published on their YT channel (https://www.youtube.com/playlist?list=PLP3xGl7Eb-4P9UDywG2NO...), but mine is not there yet.
I work on a project that does exactly that (and more): https://browserpod.io/.
Currently it supports Node, but we plan to add Python, Ruby, git, and more.
You can see it in action in this demo: https://vitedemo.browserpod.io
More info here: https://labs.leaningtech.com/blog/browserpod-10
Ah and kudos to Syrus and his team for this release. Edge.js's architecture seems to have many similarities with BrowserPod. I see it as proof that we are both going in the right direction!
So using agents forces (or at least nudges) you to use go and tailwind, because they are simple enough (and abundant in the training data) for the AI to use correctly.
Does this mean that eventually in a world where we all use this stuff, no new language/framework/library will ever be able to emerge?
Competing with the existing alternatives will be too hard. You won't even be able to ask real humans for help on platforms like StackOverflow because they will be dead soon.
On the Web, you can do that today. This is what https://webvm.io does for example. It jit-compiles Wasm modules at runtime from the original X86.
For reference, when loading https://browsercraft.cheerpj.com for the first time (up to loading a world), my browser downloaded ~32MB.
The second time almost nothing.
Looking forward to progress on the memory control proposal(s). Another reason to want more than 4GB of memory is to have more address space, assuming that you have the ability to map it. With that capability Wasm64 could be useful also for apps that don't plan to use a huge amount for real.
it does if you log in with Tailscale (networking tab in the side bar).
The terminal-based https://webvm.io has it pre-installed but the graphical demo running Alpine does not.
Luckily, the package manager also works so you can install it with `apk add curl`
It is a bit unfair to Wasmer, because it incur in the (presumed) overhead of `wasmer run ...`, but I could not figure out if the actual clang binary is directly available after it is downloaded the first time.
very unscientific benchmark of `clang hello.c`, after a few runs to make sure the code is downloaded/cached:
jslinux: 4.7s
wasmer: 1.3s
webvm: 1.2s
It's now possible to run Java Web Start applications fully in the browser without any plugins: https://cheerpj.com/cheerpj-jnlp-runner/
It's based on CheerpJ, a JVM that runs in the browser (using JS and Wasm).
Could you elaborate on how you solved the issue? A link to the relevant code would be nice.
Actually, it was in wasi-libc: https://github.com/WebAssembly/wasi-libc/blob/main/libc-bott...
I don't necessarily disagree, but implementing these things in your custom runtime is easy. I am more interested in how they achieved them in the more constrained browser environment.
I am curious about the browser compatibility layer.
Does it support networking? (And if so, is it using a proxy to connect to the internet or is it using a virtualized network layer that stays in the browser?)
How is fork implemented? (Asyncify all the code?)
I was looking at the Github org page (https://github.com/wasix-org), but I can't figure out where this stuff is.
This is exactly what we do in Webvm: https://leaningtech.com/webvm-virtual-machine-with-networkin...
I agree. I implemented a subset of WASI, and the best resource was an autogenerated C header with function signatures and very terse comments, buried in the WASI SDK repo.
Yeah I mean, I wouldn't trust the accuracy of its answer. But I find it funny that it agrees that OpenAI should comply.
I asked ChatGPT what it thinks about this ruling:
As an AI language model, I do not collect personal data directly as I do not have access to user information. However, I understand that OpenAI, the company that developed and manages the platform, has been ordered to temporarily limit the processing of data of Italian users and is under investigation by the Italian Data Protection Authority.
As an AI language model, my purpose is to provide conversational assistance and generate human-like text based on the input provided by the user. My training data is sourced from publicly available text on the internet and does not specifically target any individual or collect personal data.
I understand that OpenAI has been accused of not providing adequate information to users regarding the collection and storage of personal data and not having a legal basis for such collection. I cannot comment on OpenAI's specific policies and practices regarding data collection and storage, as I am not privy to such information.
However, I believe that it is important for companies to prioritize user privacy and to comply with data protection regulations. I hope that OpenAI will take the necessary measures to address the concerns raised by the Italian Data Protection Authority and implement appropriate safeguards to protect the personal data of its users.
Indeed, as I said it can be a downside.
What we usually suggest is to compile most of the application to Wasm (which is also the default), and move the parts that most interact with the outside world to JS.
This can actually result in a speedup if it avoids multiple back-and-forths between JS and Wasm, which is common if you use a Browser/JS api from Wasm.
Disclaimer: I work on Cheerp.
We do include the C (Musl) and C++ (Clang's libcxx) standard libraries.
And we do have some custom LLVM passes to improve code size and performance (See for example [1] and [2]).
But the main selling point in my opinion is the ability to target JavaScript, and (almost) freely mix data and code compiled to either JS or Wasm.
Emscripten can also target JS, but it still retains the linear memory model of Wasm (or X86, Arm, ...), which means that what you get in the end is a big TypedArray and operations on it using basic types.
With Cheerp, code compiled to JS uses an object memory model: a C++ object will become a garbage-collected JS object. While this has some limitations (you can't do unsafe casts and treat your memory like it's a big array, because it isn't), it allows seamless integration with the Browser (or any third-party) APIs:
- You can store a DOM element directly in your C++ objects (instead of doing everything through tables)
- You can directly manipulate JS Strings instead of constantly converting back and forth to C strings
- You can create nice zero-overhead interfaces to use your C++ classes from manually written JS
- Or, you can just write your whole program in C++, including callbacks for DOM events and whatnot
And you can still compile the peformance-sensitive or type-unsafe parts of your code to Wasm (losing access to some convenience in exchange for speed).
You can get an idea from the Pong tutorial [3], although it's a bit of a contrived example to showcase what can be done.
[1] https://medium.com/leaningtech/partialexecuter-reducing-weba...
[2] https://docs.leaningtech.com/cheerp/Cheerp-PreExecuter.html
[3] https://docs.leaningtech.com/cheerp/Cheerp-Tutorial-Mixed-mo...
That is also possible: https://docs.leaningtech.com/cheerpj/Getting-Started
See "Converting an applet"
Here you go: https://chrome.google.com/webstore/detail/cheerpj-applet-run...
CheerpJ does exactly that: it ships a full JVM implementation (including Swing/AWT, Threads, ...) that runs in JS/Wasm inside your browser. The Applet Runner extension detects applets in the page and runs them through CheerpJ.
The example that you list seems to work.
By "Wasm JIT API in JavaScript" I mean a native way for the browser to support the JIT use-case.
Generating entire modules works, but it has a number of issues.
For example, you need to carefully decide how big your modules are going to be:
- Too small, and you end up compiling many many modules, which eventually crashes the browser if you don't dispose of the old ones
- Too big (many functions batched together), and you have too much latency before your code is available to run
Being able to compile a single function to add to an existing module (or something like that) would help a lot.
This is a nice overview on how to achieve just-in-time compilation in Wasm, and the demo is pretty cool. Good work!
We use similar techniques to power Webvm[1], an X86 Virtual Machine that runs linux programs in the browser.
A proper Wasm JIT API in JavaScript would be even better of course, but as the article says, cool things are already possible right now.
I expect to see more projects doing Wasm just-in-time compilation in the future (I believe that V86[2] also already does it)
Actually even C++ can benefit from this.
In LLVM C++ coroutines compile down to functions with the "musttail" attribute, that right now is not possible to express in Wasm [1].
It is also useful to efficiently implement stuff like interpreters, where you use it as a way to jump to the code of the next instruction directly (Wasm has only structured control flow, but you can see a tail call as a sort of jump/goto instruction)
[1] https://discourse.llvm.org/t/supporting-coroutines-without-t...
Well the comparison here is between openldap and lldap. I would use either as a backend for Authelia.
But I found Authelia reasonably simple to use too.
I have been using lldap for a while (paired with Authelia), and it is a real godsend.
I feel like I need a PhD to configure openldap, while this was as out of the box as it gets.
Kudos to the devs!
The article mentions WebAssembly as having the same issue as spir-v with structured control flow, but actually in Wasm it is quite a bit better, because you are allowed to break/continue from an arbitrarily nested block.
This allows you to convert any reducible CFG without losing runtime performance, and only pay a price for irreducible ones (which are somewhat rare).
Shameless plug: I wrote an article about solving the structured control flow problem in WebAssembly -> https://medium.com/leaningtech/solving-the-structured-contro...
If you are interested, here is the article I wrote about that particular project: https://medium.com/leaningtech/porting-a-c-multiplayer-game-...