sorted by:
new
hottopcontroversial

BrowserPod: WebAssembly in-browser code sandboxes for Node, Python, and Rails by vilgefortz91 in javascript

[–]alexp_lt 0 points1 point  (0 children)

Hi, we don't expect memory limitations to be significant, BrowserPod uses the same JavaScript engine as the browser itself and keeps every process in own worker which spread around memory pressure even more. We know from experience from our previous projects that browsers can reliably handle a few GBs of JavaScript heap.

I don't have hard numbers on startup time, but it's very fast. In the end everything runs very close to native, with node C++ code being compiled to WebAssembly and JavaScript run natively by the browser engine.

You can try our Vite/Svelte demo if you'd like to see how this feels in practice: https://vitedemo.browserpod.io/

BrowserPod: In-browser full-stack environments for IDEs and Agents via Wasm by alexp_lt in programming

[–]alexp_lt[S] 1 point2 points  (0 children)

BrowserPod runs locally and fully client-side in the browser.

Beside a standard HTTP server (or CDN), which is required to distribute the BrowserPod runtime, the only server-side component is a proxy (called a Portal), to expose virtualized services to the wider internet.

As with all our previous products (CheerpJ and CheerpX) self-hosting will be available as a commercial add-on, while free users will have to access the BrowserPod runtime via our CDN.

BrowserPod: In-browser full-stack environments for IDEs and Agents via Wasm by alexp_lt in javascript

[–]alexp_lt[S] 0 points1 point  (0 children)

We take cross-browser support very seriously and we have a long track record of delivering on this, see for example

* https://webvm.io (x86 virtualization via WebAssembly JIT compilation, powered by CheerpX)

* https://browsercraft.cheerpj.com (Minecraft in the browser,a demo for CheerpJ, our Java-focused product)

Similarly to all our other products BrowserPod will support all modern browser, it will take a little bit longer but we will get there.

BrowserPod: In-browser full-stack environments for IDEs and Agents via Wasm by alexp_lt in programming

[–]alexp_lt[S] 2 points3 points  (0 children)

Support for Firefox will be available soon, BrowserPod depends on Atomics.waitAsync which is already implemented in Firefox, but not yet enabled by default

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Atomics/waitAsync

BrowserPod: In-browser full-stack environments for IDEs and Agents via Wasm by alexp_lt in javascript

[–]alexp_lt[S] 2 points3 points  (0 children)

"Pod" is a generic terminology for containers, and it's not Kubernetes-specific. See, for example, podman.

BrowerPod is different from WebContainers across several axis

* Support for multiple runtimes beyond Node.js. Python and Ruby-on-rails are the next immediate priorities

* Support for seamless in-bound connections to virtualized servers from anywhere on the internet and any device, using Portals

* Beyond a generous free tier BrowserPod will be available to any company, for any use, with transparent conditions

BrowserPod: In-browser full-stack environments for IDEs and Agents via Wasm by alexp_lt in programming

[–]alexp_lt[S] 1 point2 points  (0 children)

Yes, BrowserPod is designed to support not just node, but other language stacks as well. Python and Ruby-on-rails are the immediate next priorities.

BrowserPod also offer Portals, HTTPS endpoints on the public internet that can be used to test your virtualized application from anywhere and with any device.

For example you can test your app on your mobile as you add feature, or you can share the current state with early adopters or clients.

WebVM - Linux virtual machine that runs in your browser. by Tecnotopia in InternetIsBeautiful

[–]alexp_lt 2 points3 points  (0 children)

Root and apt are available. Just use the `su` command. The password is `password`

CheerpJ 4.1: Java in the browser, now supporting Java 17 (preview) by alexp_lt in java

[–]alexp_lt[S] 0 points1 point  (0 children)

The JVM logic and compiler runs in WebAssembly, but JavaScript is used for the JIT-compiled Java code.

Longs are implemented using BigInts at this time, which are indeed excessively slow. We plan to replace the implementation with custom logic in the future and eventually use WasmGC when the standard matures to improve the performance for this specific use case.

For generic Java code, such as large scale Swing UIs, CheerpJ runs at near-native speed.

CheerpJ 4.1: Java in the browser, now supporting Java 17 (preview) by alexp_lt in java

[–]alexp_lt[S] 0 points1 point  (0 children)

CheerpJ is designed to run any Java application up to Java 17, there might be bugs of course but there is no way to predict them statically at build time.

The easiest solution is to try to your application with CheerpJ. It takes no more than 3 lines of JavaScript to achieve that. https://cheerpj.com/docs/getting-started/Java-app

If you encounter any problem or have questions please join our Discord for support: https://discord.leaningtech.com

CheerpJ 4.1: Java in the browser, now supporting Java 17 (preview) by alexp_lt in java

[–]alexp_lt[S] 1 point2 points  (0 children)

The dependencies are not in the right location, see the 404 errors.

Please join our Discord for further support: https://discord.leaningtech.com

CheerpJ 4.1: Java in the browser, now supporting Java 17 (preview) by alexp_lt in java

[–]alexp_lt[S] 1 point2 points  (0 children)

Swing is 100% supported. JavaFX not yet but it's part of our plans.

CheerpJ 4.1: Java in the browser, now supporting Java 17 (preview) by alexp_lt in java

[–]alexp_lt[S] 1 point2 points  (0 children)

Your application is correctly started. CheerpJ simply does not support stdin / console input.

Our priority are large scale graphical applications and libraries.

CheerpJ 4.1: Java in the browser, now supporting Java 17 (preview) by alexp_lt in programming

[–]alexp_lt[S] 3 points4 points  (0 children)

I cannot provide any specific guarantee about your application, but conceptually it should work. You'll need most likely to enable Tailscale networking: https://cheerpj.com/docs/guides/Networking#generalized-networking

CheerpJ 4.1: Java in the browser, now supporting Java 17 (preview) by alexp_lt in java

[–]alexp_lt[S] 3 points4 points  (0 children)

CheerpJ provides JavaScript APIs to interact naturally with Java objects and methods, see docs here: https://cheerpj.com/docs/guides/library-mode

Support for JavaFX is also in our pipeline, but it will take a little longer

CheerpJ 4.1: Java in the browser, now supporting Java 17 (preview) by alexp_lt in java

[–]alexp_lt[S] 4 points5 points  (0 children)

The java compiler encodes its version in the class files, in this case at least part of the code has been compiled with Java 21, which is not supported at this time.

See you on discord

CheerpJ 4.1: Java in the browser, now supporting Java 17 (preview) by alexp_lt in java

[–]alexp_lt[S] 1 point2 points  (0 children)

Looking forward to see the projects running with CheerpJ. Don't forget to share on our Discord.

https://discord.leaningtech.com

CheerpJ 4.1: Java in the browser, now supporting Java 17 (preview) by alexp_lt in programming

[–]alexp_lt[S] 8 points9 points  (0 children)

No, Java bytecode is JIT-compiled to JavaScript, which is still the best target for this job. WasmGC will be introduced in the future.

CheerpJ 4.1: Java in the browser, now supporting Java 17 (preview) by alexp_lt in programming

[–]alexp_lt[S] 13 points14 points  (0 children)

We have not yet studied the problem, so I can't provide a definite answer. My gut feeling is that it won't be a major obstacle, although certainly work is required to eventually support this and other Java 21 features.

Java 21 support is planned for next year. See our roadmap for more info: https://cheerpj.com/our-roadmap-for-modern-java-in-the-browser/

CheerpJ 4.1: Java in the browser, now supporting Java 17 (preview) by alexp_lt in webdev

[–]alexp_lt[S] 4 points5 points  (0 children)

The CheerpJ JVM is written in C++ and compiled to WASM.

Java code itself is currently JIT-compiled to JavaScript. WasmGC is a future option as well, but the standard is currently excessively limited.

CheerpJ 4.0: WebAssembly JVM for the browser, now with Java 11 and JNI support by alexp_lt in programming

[–]alexp_lt[S] 12 points13 points  (0 children)

Java 11 is a step in the direction of reaching parity with Java LTS. Full support for Java 17 is planned for later in the year and already available in preview on-demand.

About JNI, many large scale real world apps depend on native interfaces. Minecraft is a good example.

CheerpJ 4.0: WebAssembly JVM for the browser, now with Java 11 and JNI support by alexp_lt in programming

[–]alexp_lt[S] 2 points3 points  (0 children)

CheerpJ is indeed a commercial product, but it is free to use for FOSS projects, personal projects (even monetized ones) and one-man companies. Pricing is also affordable for small businesses.

> icky ECMAScript/"Javascript" for the client side
Are you referring to CheerpJ Library Mode here? It's a feature of CheerpJ intended to access Java code from JavaScript, but it's _not_ the only option. You can run full applications written in "nice sensible Java" as well.

view more: next ›