Uhh... It seems very bad. I clicked "Run RMStudio DOM" in Chrome. It loaded dozens of java packages for half a minute, and then showed me a 90s looking splash screen with three buttons on it. None of them do anything.
I'm assuming I'm supposed to be seeing something else.
Edit: I tried "Run RMStudio Swing". That one actually loads eventually. I don't understand what kind of app it is, but it appears to leak DOM elements. I see 99 DOM elements when the editor first loads ("New"). Mousing back and forth over the menus for a few seconds makes the number of elements increase by hundreds, and it never goes back down.
As long as the app performs well, who cares how many layers of abstraction exist between the app logic and hardware? If it took like 2 seconds a button to register a click, then I would say the layers of abstraction are too numerous. But this app seemed very responsive - and all I would have to do to start it is navigate to a page in my browser.
This is exactly the thought I had. Applets were always a crashy mess. Who knew Java would eventually get into the browser via transpiler (if that's what this is...)
Anyone have a thought on how one might pronounce CheerpJ?
Java and JavaScript are not that different. We used to have a security testing engine that was written in Java and transpiled into JavaScript with our own compiler. It works and it was OK in the days when static typing was one of those things that were missing from modern JavaScript. We do not do this any more. Everything is JavaScript these days.
People often emphasize that their etymology is just incidental, but the similarities are definitely deeper than just the names. Why else would the creator have named it JavaScript?
Runs smoothly - almost indistinguishable from native. With webassembly (and I know this is in JS) and the general progression of the web platform and JS engines it seems to me that web apps will continue to grow in number and in popularity. I don't see why the web app should die.
Appears the tech behind this "cheerpj" a java transpiled to javascript[1] system that appears to contain all of openjdk including swing(!?!). That's kind of cool actually. But creating applications with such a system seems highly problematic. See for example GWT (google web toolkit)[2] which also transpiled java to javascript. I only see legacy GWT apps around nowadays, the world moved on. So I really don't see the appeal of this; unless you're a java shop hell bent on NOT learning modern frontend development.
Legacy systems that haven't migrated to some other front end yet. There would be a lot of companies in this situation. That said, I'm not convinced this is the best approach. I think I'd prefer rewriting parts at a time of a system that big.
Think bigger. Start a consulting company that just runs around and recompiles all people's old Java Swing crap into "web apps" like this one. Charge $10-50k / pop.
Get on the consulting gravy train by somehow allowing piecemeal callouts to "real dom" (kindof like an IFRAME from within JAVA) which lets you start rewriting bits and pieces into some angular.next framework.
By the time you finish converting the majority of their Swing to Angular conversion, angular will finally be deprecated (or dart-only, lulz) and you can set yourself up with a new and improved consulting company which will convert Angular to React as soon as the Java to Angular contract finishes up!
Sounds like a great instance of the old adage "Consulting: If you can't be part of the solution, there's good money to be made in prolonging the problem."
This version is all JavaScript - the WebAssembly version should be truly amazing. Though probably next year, when WebAssembly matures (adds threading and improved memory model, GC and more).
Cheerp really did it the right way - starting with the C++ compiler for the Java native runtime. This implementation of Java in the browser is very similar to a normal Java platform port - only in this case the platform is the browser. Compatibility and functionality is remarkable.
I get 40fps+ on my Retina iMac, dragging around composited images, 3D Graphs, and shapes with filter effects. Should only get better as CheerpJ improves (they're only getting started) and when WebAssembly support is fully enabled. It even runs fine on my iPad and phone. But follow the link and judge for yourself.
Swing, with all its warts, is so much saner than frontend frameworks. The existence of CheerpJ almost makes me want to write web apps in Java and then compile them to JS.
Vaadin [1], a fairly popular open-source Java UI framework, is still using GWT on the clientside, but it's more of an implementation detail given that the whole point of Vaadin is that you don't have to care about the clientside that much. And when you do, you can write your frontend stuff in Java. Of course that's less of a selling point than five years ago, and Vaadin has also been moving towards more easily interfacing with native JS code without GWT wrappers. (Disclosure: I'm a former Vaadin employee and core devteam member.)
I worked on a product that used the Vaadin framework for UI. It is a serious, production ready library that is written by some very sane and very intelligent people. The JavaScript hipsters would probably turn their nose up at it, but being purely objective I found it to be a good solution. I have also worked on a project that used React + Redux on the front-end so I believe I have a fairly balanced opinion.
pros:
- Server-side rendering can improve client-side performance, especially since it allows you to avoid N + 1 problems associated with many roundtrips to REST APIs
- Compatibility with all common browsers (Vaadin take responsibility for this basically)
- If your backend codebase is already Java, writing your UI code in Java can save time/reduce complexity (e.g. all your existing static analysis tools can now be applied to your frontend code as well)
- There are simple, well documented ways to wrap 3rd party JavaScript libraries. I was able to integrate VisJS as a custom component quite easily
cons:
- Server-side rendering comes with a non-trivial memory overhead that scales pretty linearly with no. of clients. This may or may not be a concern depending on your requirements
- In terms of writing elegant code, I found the experience much better with React + Redux, as best practices are essentially enforced here (pure functional code)
- You still have to get your hands dirty with CSS, although Vaadin does provide base themes like Valo if you so wish to use them
Actually new Google applications being shipped, like Docs and Inbox are using GWT, and its successor, J2CL.
J2CL (Java 2 Closure) and J2ObjC together permit cross platform application development to run shared code in the server, Web, Android, and iOS. This is not "write once, run anywhere" UI development, the UI layer is still native JS, (Java for Android), and hand-written Objective-C (iOS), but about 70% of the code (business logic layer) is shared between platforms as Java. Java is transpiled to heavily annotated Closure ES6 code (in theory it could be TypeScript) and optimized by the Closure Compiler, OR it's transpiled to Objective-C and imported into XCode.
This is not a React-Native approach, teams decided that trying to do "write-once-run-anywhere" UI leads to "uncanny valley" effects as you invariably end up with non-native experiences by trying that approach, instead front end developers who are experts on each platform (Web, Android, iOS) use the best available native tools for those platforms to create the UI 3x, which they wire up to a shared layer which is written once.
The reason to go with transpilation, instead of a low level emscripten/bytecode/VM level approach is performance and optimization. Java classes can be pretty easily translated to ES6 classes, and consumed by Babel, or more importantly, Closure Compiler, with aggressive optimizations to split code, tree shake, etc. This information is lost if you just blindly translate the entire stack at a low level.
It also means the impedance mismatch is very low. For example, Objective-C or JS code can call into J2Cl code very easily. They're just ES6 modules or Obj-C interfaces/classes.
True, but it is reusing an (alien) middleware on top of that. I like react-native and have used it, but a <Text>, <View>, or <ScrollView> isn't the same thing as directly using the native widget APIs yourself, or using the native tooling like Android XML files, XIBs, etc. There's a class of apps where you really need the direct access, and currently for React-Native, that means writing native modules and tying them to markup, which invariably leads to people trying to create versions that work on Android and iOS unified by a single <Element>.
React-Native works, apps like Discord prove that. But Gmail and Docs tried the approach of running their huge apps business logic 100% in JS on mobile, and the performance and memory usage didn't meet expectations. If you try to do something like run formula recalculations on a 20,000 cell spreadsheet, on a low powered Android device, the performance is much worse than running the same code in Dalvik/ART.
Unless I'm mistaken. I don't think the 'world has moved on'. As an example, I believe Eclipse Che (a relatively new project with a decent UI) uses GWT mixed with a little bit of Typescript.
I also tought that, long before Google shipped some new GWT applications in 2017.
I think that GWT is still in big use, but it's probably not trendy, that's why you probably won't see much talk about it.
I think that transpired ANY Language is actually the future of most web applications. yes there will still be a lot of javascript users, but I guess other languages will soon have ways to build web application with a shared code base.
And actually I think there is a benefit in doing so, well sharing everything is maybe not the best idea, even GWT made integration with JavaScript stuff better in the last releases. But Models and Utilities are a big win if they can be shared.
Actually in my company we use a lot of Scala, and it would be really cool to share the models, but sadly it's really hard to get a good toolchain (ScalaJS works, but integration in our "legacy" tooling sucks). that's why we still duplicate a lot of code in typescript, besides the fact that most models are just 1:1.
>unless you're a java shop hell bent on NOT learning modern frontend development.
Sorry, but that statement is dripping with irony. Irrespective of whether GWT was the right implementation, the Swing model is far superior to any of the piles of tangled JS/HTML/Made-Up-Things that comprise "modern frontend" frameworks. I know that's not a popular statement, as everyone seems to have their favorite framework, and I'm referencing all of them.
So, we took a step back and had a bit of a mess with frontend development on the Web, then "solved" some of the problems with new frameworks. They're still miles behind a true event-driven, component-based UI model. We solved this problem long ago with Swing and other native window-based UI frameworks, and none of the current frontend Web frameworks is even close.
Don't know if the subject of this post is the answer, but I do know that one day we'll look back and laugh at the time we thought, say, JSX was a good idea.
The web is fundamentally different from every desktop UI framework that has come before. The address bar and back button change everything. Swing doesn't handle it, SWT doesn't, Qt, gtk, cocoa, none of them. So yeah, there has been a lot of development, but the web is different.
>The address bar and back button change everything.
>the web is different
It's not specifically the desktop UI framework model that's discordant with the Web; it's SPAs in general.
The browser was built around a document model, not a SPA model. Hence, 99% of what you really want to do with the back button in a SPA is try to prevent it from having deleterious effects. You enable it for navigation only because you have no choice (well, you do, but it wouldn't meet user expectations, especially on mobile where the back-button in apps and the browser are the same). Likewise, beyond locating the app, the address bar is really of little use.
So, let's hold that constant. You have to manage it regardless and it's just as easy to build URL-based view-resolution into any framework. Point being that, once the view is resolved, there's absolutely no reason you can't use a Swing-like model to render and manage it.
This is really nifty as a proof of concept, major kudos to the authors. However, it completely kills accessibility, so it's probably best to avoid for any serious projects.
I've gotta ask, since I've never used Java applets... Wasn't this already possible back in 1995? Have we come full circle?
It was possible, but there were issues with performance, compatibility, security and configuration. Everyone had a different version of the Java plugin implemented with different platform Look-And-Feels (if you had the plugin at all). And then the browser vendors went to war against plugins.
CheerpJ is a much better approach - doesn't require a separate plugin, doesn't have version problems, has inherent JS-sandbox security, uses the same look-and-feel and performs great (after initial download).
For a large project, it's nice to have all the benefits of desktop development with a strongly typed language, but still have the ability to publish to the browser.
One of the biggest impediments was that Microsoft had this crappy implementation of Java on IE that was simply useless. Making a portable (modern at the time) applet that worked in IE was essentially impossible. I have no doubt MS did that on purpose.
All said, I think having a standardized binary ASM model in the browser is the right way to go, even if it is a couple decades later :)
Java finally made it on my iPhone.
"Java uh.. finds a way." -Goldblum
This is actually pretty cool, though something about seeing my taskbar containing a window that contains an jvm that contains another window drawn in swing makes me think we've lost our way somewhat.. better we make the computers do it than rewrite everything by hand I suppose.
I see it another way... It's actually a Holy Grail in a way.
OS makers have made things intentionally incompatible since the beginning of time. Developers are finally finding effective ways to fight back.
We could have had Java/whatever everywhere ages ago if the OS makers were not purposely segmenting the market.
We might finally have a way out of the tyranny of OS makers taking 30% of the revenue in apps stores for example.
WASM will change everything. Every platforms will be compatible somewhat against the will of OS creators. Expect some kind of backlash or walled gardening to commence shortly...
I've wanted this for a while - have my ThreadRipper box at home, and use a remote IntelliJ on a wimpy laptop that just runs a light UI through the browser. Real latency benefits vs running remotely, especially on a typical coffee shop wifi.
Ahh, but I don't see that happening any time soon.
Edit: or spark up a really powerful instance on something like Hyper.sh when you need it, close it down when you're done. Pay more to get a well provisioned instance when you need real horsepower.
For the second point, I've had a lot of success doing this with a Jupiter notebook. It's not an IDE by any means but it's very productive for exploratory work, and when you need horsepower you just spin up the kernel on a beefier cloud machine.
That would be like me hopping on my bike, pedaling for hours, which charges up a battery that is attached to it with an inverter, putting it into a carboat, driving onto the water, to get into my seaplane.
The original goal was for me to be in the air. LOL
For legacy apps or if your back end is Java and you need to share code, GWT and this concept is a good solution. If you are just trying to avoid learning JavaScript/CSS this will leave you very unhappy.
You don't have to use GWT webforms-style: you can also use something like GWTReact[1]. It ends up being more verbose than JS or TS, of course, but might be useful if you've got a lot of business logic in Java that you want to be able to use easily in a modern web app.
There's also JSweet[2], which compiles Java to TypeScript. I believe it can automatically convert TypeScript definitions into Java, so it's a good way to write Java that calls existing JS libraries.
Granted, writing Java to run in the browser probably isn't the best solution for most people. But there are certain situations where it makes sense, and it doing so doesn't mean you're condemned to write an application that feels like crufty legacy garbage.
I'd imagine it's a large codebase and they're trying to maximize the number of people that can access it while minimizing the number of supported browsers. There are very few platforms where firefox is available and Chrom(e|ium) is not.
FWIW, it actually does work on Firefox Quantum; it's just not guaranteed to work.
I’m on a 2G mobile connection right now, and that site refuses to load. I’m going to guess this has something to do with bundling all of Java, but surely there must be a better way to write UIs that doesn’t involve downloading the whole JDK to my browser cache.
This is not a joke - webpage size is a real issue. Even on this connection I can browse a lot of pages normally, but something like this Java UI toolkit just goes way over the edge. On this connection I can’t update any native apps because they’re all much too big - but the ones I have continue to work fine. But web apps generally don’t guarantee persistence in the same way. If an app I need is suddenly removed from cache at an inopportune time, I’m screwed. That’s why web apps really need to be leaner.
I don't disagree it's not for general web pages, but it's more than fine for any non-trivial app. Downloads less data than 60 seconds of YouTube. The runtime is CDN shared, so the more apps that use it, the less it will matter.
Ironically Java apps would ideally be much leaner than JS. Once WASM support is done for CheerpJ the bundles should be quite small.
JavaScript developers are foaming over "tree shaking" which is child's play compared to how much dead code you can remove from a compiled language.
If you don't use tricks like reflection you can eliminate basically all dead code from Java. This is done routinely on Android via proguard and Android apps would be very lean if people didn't take the opportunity to jam tons of crap into them.
It seems the natural way of things is to bloat your app up to at least 5mb by tacking on crap until it's "too slow" for normal users.
The Java Applets of ye old days were basically desktop apps and only took about 3 mb, huge for back then but probably below average for a site these days. And this was before Java had Proguard and related tools to strip unused code.
The standard java.io.File and java.net.URL work as normal. CheerpJ provides a choice of filesystem access methods. This includes a read-only filesystem based on HTTP, a local read-write filesystem based on indexDB which is persistent across sessions, and a facility to access JS strings as files, useful to pass input data to target converted Java programs. DropBox and Google drive are also available.
74 comments
[ 2.6 ms ] story [ 128 ms ] threadI'm assuming I'm supposed to be seeing something else.
Edit: I tried "Run RMStudio Swing". That one actually loads eventually. I don't understand what kind of app it is, but it appears to leak DOM elements. I see 99 DOM elements when the editor first loads ("New"). Mousing back and forth over the menus for a few seconds makes the number of elements increase by hundreds, and it never goes back down.
Can you do the same thing to eclipse? That is still widely used despite how long it takes to load and how "90's the UI looks"
I mean as a technical feat it's impressive (in the same way as running Linux in the browser via JavaScript [0]).
At the same time I'm horrified that someone would seriously do it (though I can understand the business reasons for wanting to do so).
0: https://bellard.org/jslinux/
Good riddance horrific ball of JS/HTML/CSS
Anyone have a thought on how one might pronounce CheerpJ?
[1] https://www.leaningtech.com/cheerpj/faq/
[2] http://www.gwtproject.org/
Get on the consulting gravy train by somehow allowing piecemeal callouts to "real dom" (kindof like an IFRAME from within JAVA) which lets you start rewriting bits and pieces into some angular.next framework.
By the time you finish converting the majority of their Swing to Angular conversion, angular will finally be deprecated (or dart-only, lulz) and you can set yourself up with a new and improved consulting company which will convert Angular to React as soon as the Java to Angular contract finishes up!
/s
I can't wait much longer for WebAssembly.
https://vaadin.com/ [1]
pros:
- Server-side rendering can improve client-side performance, especially since it allows you to avoid N + 1 problems associated with many roundtrips to REST APIs
- Compatibility with all common browsers (Vaadin take responsibility for this basically)
- If your backend codebase is already Java, writing your UI code in Java can save time/reduce complexity (e.g. all your existing static analysis tools can now be applied to your frontend code as well)
- There are simple, well documented ways to wrap 3rd party JavaScript libraries. I was able to integrate VisJS as a custom component quite easily
cons:
- Server-side rendering comes with a non-trivial memory overhead that scales pretty linearly with no. of clients. This may or may not be a concern depending on your requirements
- In terms of writing elegant code, I found the experience much better with React + Redux, as best practices are essentially enforced here (pure functional code)
- You still have to get your hands dirty with CSS, although Vaadin does provide base themes like Valo if you so wish to use them
I'd rethink the assumption that you're purely objective and other people are not.
J2CL (Java 2 Closure) and J2ObjC together permit cross platform application development to run shared code in the server, Web, Android, and iOS. This is not "write once, run anywhere" UI development, the UI layer is still native JS, (Java for Android), and hand-written Objective-C (iOS), but about 70% of the code (business logic layer) is shared between platforms as Java. Java is transpiled to heavily annotated Closure ES6 code (in theory it could be TypeScript) and optimized by the Closure Compiler, OR it's transpiled to Objective-C and imported into XCode.
This is not a React-Native approach, teams decided that trying to do "write-once-run-anywhere" UI leads to "uncanny valley" effects as you invariably end up with non-native experiences by trying that approach, instead front end developers who are experts on each platform (Web, Android, iOS) use the best available native tools for those platforms to create the UI 3x, which they wire up to a shared layer which is written once.
The reason to go with transpilation, instead of a low level emscripten/bytecode/VM level approach is performance and optimization. Java classes can be pretty easily translated to ES6 classes, and consumed by Babel, or more importantly, Closure Compiler, with aggressive optimizations to split code, tree shake, etc. This information is lost if you just blindly translate the entire stack at a low level.
It also means the impedance mismatch is very low. For example, Objective-C or JS code can call into J2Cl code very easily. They're just ES6 modules or Obj-C interfaces/classes.
React-Native works, apps like Discord prove that. But Gmail and Docs tried the approach of running their huge apps business logic 100% in JS on mobile, and the performance and memory usage didn't meet expectations. If you try to do something like run formula recalculations on a 20,000 cell spreadsheet, on a low powered Android device, the performance is much worse than running the same code in Dalvik/ART.
https://github.com/eclipse/che/blob/master/ide/che-core-ide-...
IANAL, but what about copyright here? AFAIU, you create a derivative work of JDK.
I also tought that, long before Google shipped some new GWT applications in 2017. I think that GWT is still in big use, but it's probably not trendy, that's why you probably won't see much talk about it.
I think that transpired ANY Language is actually the future of most web applications. yes there will still be a lot of javascript users, but I guess other languages will soon have ways to build web application with a shared code base. And actually I think there is a benefit in doing so, well sharing everything is maybe not the best idea, even GWT made integration with JavaScript stuff better in the last releases. But Models and Utilities are a big win if they can be shared.
Actually in my company we use a lot of Scala, and it would be really cool to share the models, but sadly it's really hard to get a good toolchain (ScalaJS works, but integration in our "legacy" tooling sucks). that's why we still duplicate a lot of code in typescript, besides the fact that most models are just 1:1.
Sorry, but that statement is dripping with irony. Irrespective of whether GWT was the right implementation, the Swing model is far superior to any of the piles of tangled JS/HTML/Made-Up-Things that comprise "modern frontend" frameworks. I know that's not a popular statement, as everyone seems to have their favorite framework, and I'm referencing all of them.
So, we took a step back and had a bit of a mess with frontend development on the Web, then "solved" some of the problems with new frameworks. They're still miles behind a true event-driven, component-based UI model. We solved this problem long ago with Swing and other native window-based UI frameworks, and none of the current frontend Web frameworks is even close.
Don't know if the subject of this post is the answer, but I do know that one day we'll look back and laugh at the time we thought, say, JSX was a good idea.
>the web is different
It's not specifically the desktop UI framework model that's discordant with the Web; it's SPAs in general.
The browser was built around a document model, not a SPA model. Hence, 99% of what you really want to do with the back button in a SPA is try to prevent it from having deleterious effects. You enable it for navigation only because you have no choice (well, you do, but it wouldn't meet user expectations, especially on mobile where the back-button in apps and the browser are the same). Likewise, beyond locating the app, the address bar is really of little use.
So, let's hold that constant. You have to manage it regardless and it's just as easy to build URL-based view-resolution into any framework. Point being that, once the view is resolved, there's absolutely no reason you can't use a Swing-like model to render and manage it.
all this GWT bashing is from hipsterish kids who don't know anything else besides latest javascript frameworks.
Other than that, it's pretty impressive.
I've gotta ask, since I've never used Java applets... Wasn't this already possible back in 1995? Have we come full circle?
http://www.edm2.com/index.php/Corel_Office_for_Java
CheerpJ is a much better approach - doesn't require a separate plugin, doesn't have version problems, has inherent JS-sandbox security, uses the same look-and-feel and performs great (after initial download).
For a large project, it's nice to have all the benefits of desktop development with a strongly typed language, but still have the ability to publish to the browser.
All said, I think having a standardized binary ASM model in the browser is the right way to go, even if it is a couple decades later :)
http://www.reportmill.com/company/
This is actually pretty cool, though something about seeing my taskbar containing a window that contains an jvm that contains another window drawn in swing makes me think we've lost our way somewhat.. better we make the computers do it than rewrite everything by hand I suppose.
OS makers have made things intentionally incompatible since the beginning of time. Developers are finally finding effective ways to fight back.
We could have had Java/whatever everywhere ages ago if the OS makers were not purposely segmenting the market.
We might finally have a way out of the tyranny of OS makers taking 30% of the revenue in apps stores for example.
WASM will change everything. Every platforms will be compatible somewhat against the will of OS creators. Expect some kind of backlash or walled gardening to commence shortly...
Imagine a bit more powerful Chromebook with that..., but then where the files, projects, etc. would get stored?
Ahh, but I don't see that happening any time soon.
Edit: or spark up a really powerful instance on something like Hyper.sh when you need it, close it down when you're done. Pay more to get a well provisioned instance when you need real horsepower.
That would be like me hopping on my bike, pedaling for hours, which charges up a battery that is attached to it with an inverter, putting it into a carboat, driving onto the water, to get into my seaplane.
The original goal was for me to be in the air. LOL
For legacy apps or if your back end is Java and you need to share code, GWT and this concept is a good solution. If you are just trying to avoid learning JavaScript/CSS this will leave you very unhappy.
There's also JSweet[2], which compiles Java to TypeScript. I believe it can automatically convert TypeScript definitions into Java, so it's a good way to write Java that calls existing JS libraries.
Granted, writing Java to run in the browser probably isn't the best solution for most people. But there are certain situations where it makes sense, and it doing so doesn't mean you're condemned to write an application that feels like crufty legacy garbage.
[1] https://github.com/GWTReact/gwt-react-examples [2] http://www.jsweet.org/
Why no FF? What could possibly cause them not to support it? Any specialists out there?
FWIW, it actually does work on Firefox Quantum; it's just not guaranteed to work.
This is not a joke - webpage size is a real issue. Even on this connection I can browse a lot of pages normally, but something like this Java UI toolkit just goes way over the edge. On this connection I can’t update any native apps because they’re all much too big - but the ones I have continue to work fine. But web apps generally don’t guarantee persistence in the same way. If an app I need is suddenly removed from cache at an inopportune time, I’m screwed. That’s why web apps really need to be leaner.
JavaScript developers are foaming over "tree shaking" which is child's play compared to how much dead code you can remove from a compiled language.
If you don't use tricks like reflection you can eliminate basically all dead code from Java. This is done routinely on Android via proguard and Android apps would be very lean if people didn't take the opportunity to jam tons of crap into them.
It seems the natural way of things is to bloat your app up to at least 5mb by tacking on crap until it's "too slow" for normal users.
The Java Applets of ye old days were basically desktop apps and only took about 3 mb, huge for back then but probably below average for a site these days. And this was before Java had Proguard and related tools to strip unused code.