apignotti

7 ms·

31.
by apignotti 8mo ago
It is true that BrowserPod is currently focused on browsers environment, but there is nothing preventing the technology from running on native as well. It would requite some work, but nothing truly challenging :-)
32.
by apignotti 8mo ago
Hi, if you like the idea of Wasm sandboxing you might be interested in what we are working on: BrowserPod :-) https://labs.leaningtech.com/blog/browserpod-beta-announceme... https://browserpod.io
33.
by apignotti 8mo ago
The browser is the most effective environment to distribute and isolate applications. We have built technologies for years to leverage these capabilities to run legacy Java (CheerpJ) and x86 binaries (Cheerpx / WebVM). We are soon goin
34.
by apignotti 9mo ago
Firefox should work just fine, I tried it right now. Consider dropping in our Discord for further help: https://discord.leaningtech.com
35.
by apignotti 9mo ago
We use WebAssembly aggressively at Leaning Technologies across our tools. WebAssembly makes it possible to: * Run x86 binaries in the browser via JIT-ting ( https://webvm.io ) * Run Java applications in the browser, including Mine
36.
by apignotti 10mo ago
We’re launching BrowserPod today in open beta, after a month-long closed beta with early adopters. BrowserPod is an in-browser code sandbox for dev environments built on WebAssembly, that runs Node.js directly in the browser with no cloud p
37.
BrowserPod: WebAssembly in-browser code sandboxes for Node, Python, and Rails(labs.leaningtech.com)
4 points by apignotti 10mo ago|1 comments
38.
Show HN: BrowserPod – Instant in-browser Node.js environments with public URLs(vitedemo.browserpod.io)
1 points by apignotti 11mo ago|0 comments
39.
by apignotti 1y ago
Indeed, it's not. It's possible we might decide to release the code in the future, but for the time being we are keeping it proprietary.
40.
by apignotti 1y ago
What you describe is 100% possible. Rails is one of our priorities. PHP is also easy to achieve.
41.
by apignotti 1y ago
React native can indeed target the We. Instead we are referring to running the native build toolchain for react native, which is required to build android apps, in the browser.
42.
by apignotti 1y ago
We are working on it. Firefox is currently unsupported due to Atomics.waitAsync being not yet enabled by default. Safari on the other hand has some subtle inconsistent behavior at the edge between getters, global variables and `this`. Brows
43.
BrowserPod: In-browser full-stack environments for IDEs and Agents via WASM(labs.leaningtech.com)
63 points by apignotti 1y ago|15 comments
44.
by apignotti 1y ago
Hi, thanks for the mention :-) Lead dev of CheerpJ and CTO of Leaning Technologies here. Happy to answer any question from the community.
45.
by apignotti 1y ago
BigInts are the current solution. There are other solutions as well.
46.
CheerpJ 4.1: Java in the browser via WebAssembly with Java 17 support(cheerpj.com)
4 points by apignotti 1y ago|1 comments
47.
by apignotti 1y ago
I suspect something else is amiss here, since it is not the first time this happens. And, in full transparency, we don't engage in any manipulation of upvote count. We try to play as fair as possible here and in other communities.
48.
by apignotti 1y ago
The legacy use case is indeed very important, but there are many other opportunities that can come from using Java libraries as part of Web apps. CheerpJ provide "Library mode": an API to natively interact with Java objects from J
49.
by apignotti 1y ago
Sent straight down to 3rd page from the very first position in home. I assume there must be some internal "send this down to hell" button.
50.
by apignotti 1y ago
I see the post has been killed by moderators. I would like to be contacted to discuss why this is the case. Our content is of obvious interest to the community and we always engage in productive ways. What is the problem here?
51.
by apignotti 1y ago
CheerpJ does out-of-the-box support HTTP/HTTPS requests using fetch when the application uses the standard Java UrlConnection APIs. Of course the requests must be to the same domain (which a common case) or to a domain which is CORS en
52.
by apignotti 1y ago
Yes, any JVM language should work. We did some experiments with Kotlin specifically in the past.
53.
by apignotti 1y ago
Applets were executed completely outside of the browser sandbox. An absolute disaster from the security standpoint. CheerpJ is effectively just a very sophisticated JavaScript/WebAssembly library and it plays by the rules of the browse
54.
by apignotti 1y ago
As a matter of fact we have internally achieved 1.16.5. The Java side of things works out-of-the-box, but LWJGL3 JNI code uses some subtle techniques that are yet supported in public builds of CheerpJ. Now that we have Java 17 support we ex
55.
by apignotti 1y ago
The target of the JIT compiler is indeed JavaScript, since WasmGC is still too limited. This is fundamentally an implementation detail though, when we adopt WasmGC there will be no user visible change beside a potential performance improvem
56.
by apignotti 1y ago
Thanks. Architecturally, beside the unmodified Minecraft and LWJGL jars, this demo uses the original JNI code from LWJGL, compiled from C++ to WebAssembly.
57.
by apignotti 1y ago
Does anyone know if there is work on the idea of letting MCP-like "servers" run on the client-side? I.e. in the same browser tab as ChatGPT or Claude? This specific example would make much more sense if it could run sandboxed clie
58.
CheerpJ 4.0: WebAssembly JVM for the browser, now with Java 11 and JNI support(labs.leaningtech.com)
1 points by apignotti 1y ago|0 comments
59.
by apignotti 1y ago
Shameless plug: CheerpJ is our solution to run any JVM language in the browser, including Clojure. Reflections, Multithreading and Swing / AWT apps are all supported. https://labs.leaningtech.com/blog/cheerpj-4.0
60.
CheerpJ 4.0: WebAssembly JVM for the browser, now with Java 11 and JNI support(labs.leaningtech.com)
5 points by apignotti 1y ago|0 comments

More ›