IDE in the browser is the future, similar to how people no longer install Microsoft Excel and instead use Google spreadsheet. Github codespaces, replit, hony.ai ... will replace installing VScode.
The browser certainly has unparalleled deployment advantages. Though for sustained use, I would recommend going desktop (there's a download link on the page). Java still does good desktop. :-)
Or maybe using new "Web Apps" feature like MacOS has to turn web app into desktop.
The trick is to untangle the mental equivalence of runs-in-the-browser versus mobile code (code on demand) and/or cloud-thingy-accessed-via-thin-client, which are all orthogonal concepts. To often these get confused. But just like you give people a Java, Python, whatever bundle comprising an app that targets its associated runtime, you can give people a bundle to download and launch from their own computer where the $RUNTIME it's meant to be launched with is /usr/bin/firefox (or whatever).
(And no, this doesn't require browser support for unstable/experimental APIs like Chrome's newest proposed APIs for filesystem access. There are ways to get by with HTML5 stuff that's well-supported by every mainstream browser released in this decade.)
I hate to break it to you - excel is still the king in the spreadsheet world. Excel has decades of momentum to start with, and still gets continual upgrades. Moreover modern excel can also be web-based like Google and honestly it has very powerful features
Is this using canvas graphics? I don't think I've ever seen that before for a modern web app. Reminds me of the Mac OS 9 in the browser demo. Can we get SnapCode running in there?
Yes, every window is a canvas. All painting is done with an adapter so it uses DOM painting in the browser and Java Swing Graphics2D painting on the desktop. It's pretty much pixel perfect identical though.
I think this is some kind of CDN caching issue - that reference was removed from the launch file last week (but I've gotten a couple other reports). How did you work around it?
Thanks! SnapCode is actually 100% client based right now. It downloads the jars and the CheerpJ JVM browser runtime and runs on the local machine. Files are stored in the browser index-db.
There is a preview feature for using drop box and I'm looking into using local file system APIs, but its not really there yet.
Fascinating technology - it's good to see good ol' Swing and Graphics2D being used to target browsers in the same way React Native has gone the other way and allowed swapping the DOM renderer for a native renderer. I have a couple of questions, though. What is the pricing strategy? (Programmers who'd use it will grumble that its not FOSS, then those same programmers will grumble when the maintainers quit maintaining it. I suggest ignoring the grumbling entirely.) It's also a bit awkward in that my sense is that most (enterprise) UI programming is done with web tech, and has been for at least 10 years. Where are these Swing programmers going to come from?!
SnapCode is actually using SnapKit (https://github.com/reportmill/SnapKit) which can run on either WebAPI/DOM (in browser) or Swing (desktop). In the browser this helps slim the download and improve performance by using more browser native code.
For pricing, SnapCode is free for individual use and will remain so. Perhaps there will be funding opportunities from large organizations or for embedding use cases to help provide for the continued health of the product and community.
27 comments
[ 1.5 ms ] story [ 80.7 ms ] threadOr maybe using new "Web Apps" feature like MacOS has to turn web app into desktop.
<https://wiki.triplescripts.org/wiki/NOT#Not_a_cloud_IDE>
The trick is to untangle the mental equivalence of runs-in-the-browser versus mobile code (code on demand) and/or cloud-thingy-accessed-via-thin-client, which are all orthogonal concepts. To often these get confused. But just like you give people a Java, Python, whatever bundle comprising an app that targets its associated runtime, you can give people a bundle to download and launch from their own computer where the $RUNTIME it's meant to be launched with is /usr/bin/firefox (or whatever).
(And no, this doesn't require browser support for unstable/experimental APIs like Chrome's newest proposed APIs for filesystem access. There are ways to get by with HTML5 stuff that's well-supported by every mainstream browser released in this decade.)
https://infinitemac.org/2000/Mac%20OS%209.0.4
The online version is working well in my testing.
I think this project would be a great environment for getting my kids into coding, thanks for making it.
There is a preview feature for using drop box and I'm looking into using local file system APIs, but its not really there yet.
For pricing, SnapCode is free for individual use and will remain so. Perhaps there will be funding opportunities from large organizations or for embedding use cases to help provide for the continued health of the product and community.
see also:
https://github.com/JetBrains/projector-client#readme
https://github.com/JetBrains/projector-demo#readme