6 ms·

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 coo

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. [1] https://www.leaningtech.com/cheerpj/faq/ https://www.leaningtech.com/cheerpj/faq/ [2] http://www.gwtproject.org/ http://www.gwtproject.org/

gschrader 9y ago
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.
- ramses0 9y ago
  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! /s
  - CamperBob2 9y ago
    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."
    - abraae 9y ago
      Consultants: people who borrow your watch to tell you the time.
      - wolco 9y ago
        and charge you for it
kizer 9y ago
What about a program that uses a ton of Java libraries?
stupidcar 9y ago
They also have something called Cheerp, which is an Emscripten-like C++ to JS compiler based on LLVM: https://www.leaningtech.com/cheerp/ https://www.leaningtech.com/cheerp/
killjavascript 9y ago
This is impressive! Are they using WebAssembly here?
- jeffreportmill1 9y ago
  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).
jeffreportmill1 9y ago
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.
- neurotrace 9y ago
  And how's performance? I have a terrible feeling this is really slow.
  - jeffreportmill1 9y ago
    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.
    - copperx 9y ago
      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. I can't wait much longer for WebAssembly.
  - jbergens 9y ago
    Some of their demos were very slow and reminded me of old java applets.
revelation 9y ago
This is 100x more responsive than Reddit Mobile, if that's what "modern frontend development" is I hope it dies very soon.
Sharlin 9y ago
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.) https://vaadin.com/ https://vaadin.com/ [1]
- ganonm 9y ago
  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
  - always_good 9y ago
    >The JavaScript hipsters would probably turn their nose up at it, but being purely objective I found it to be a good solution. I'd rethink the assumption that you're purely objective and other people are not.
cromwellian 9y ago
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.
- deleted 9y ago
  [deleted]
- underwater 9y ago
  React Native promote the idea of "learn once, write everywhere", not reusing UI across platforms.
  - cromwellian 9y ago
    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.
dillon 9y ago
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. https://github.com/eclipse/che/blob/master/ide/che-core-ide-ui/src/main/java/org/eclipse/che/ide/ui/dropdown/DropdownMenu.java https://github.com/eclipse/che/blob/master/ide/che-core-ide-...
- LoSboccacc 9y ago
  eclipse has been trying for a while to move on the web - eclipse RAP dates as far back as 2007
solomatov 9y ago
> Appears the tech behind this "cheerpj" a java transpiled to javascript[1] system that appears to contain all of openjdk including swing(!?!). IANAL, but what about copyright here? AFAIU, you create a derivative work of JDK.
- dragonwriter 9y ago
  There is a reason for the “Open” in the name of “OpenJDK”.
merb 9y ago
> the world moved on. 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.
unclebucknasty 9y ago
>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.
- le-mark 9y ago
  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.
  - unclebucknasty 9y ago
    >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.
skavish 9y ago
all our products are using GWT and they are super awesome, on the bleeding edge of technology! check it out: https://www.animatron.com https://www.animatron.com all this GWT bashing is from hipsterish kids who don't know anything else besides latest javascript frameworks.

gschrader 9y ago

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.

ramses0 9y ago
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! /s
- CamperBob2 9y ago
  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."
  - abraae 9y ago
    Consultants: people who borrow your watch to tell you the time.
    - wolco 9y ago
      and charge you for it

kizer 9y ago

What about a program that uses a ton of Java libraries?

stupidcar 9y ago

They also have something called Cheerp, which is an Emscripten-like C++ to JS compiler based on LLVM: https://www.leaningtech.com/cheerp/ https://www.leaningtech.com/cheerp/

killjavascript 9y ago

This is impressive! Are they using WebAssembly here?

jeffreportmill1 9y ago
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).

jeffreportmill1 9y ago

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.

neurotrace 9y ago
And how's performance? I have a terrible feeling this is really slow.
- jeffreportmill1 9y ago
  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.
  - copperx 9y ago
    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. I can't wait much longer for WebAssembly.
- jbergens 9y ago
  Some of their demos were very slow and reminded me of old java applets.

revelation 9y ago

This is 100x more responsive than Reddit Mobile, if that's what "modern frontend development" is I hope it dies very soon.

Sharlin 9y ago

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.) https://vaadin.com/ https://vaadin.com/ [1]

ganonm 9y ago
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
- always_good 9y ago
  >The JavaScript hipsters would probably turn their nose up at it, but being purely objective I found it to be a good solution. I'd rethink the assumption that you're purely objective and other people are not.

cromwellian 9y ago

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.

deleted 9y ago
[deleted]
underwater 9y ago
React Native promote the idea of "learn once, write everywhere", not reusing UI across platforms.
- cromwellian 9y ago
  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.

dillon 9y ago

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. https://github.com/eclipse/che/blob/master/ide/che-core-ide-ui/src/main/java/org/eclipse/che/ide/ui/dropdown/DropdownMenu.java https://github.com/eclipse/che/blob/master/ide/che-core-ide-...

LoSboccacc 9y ago
eclipse has been trying for a while to move on the web - eclipse RAP dates as far back as 2007

solomatov 9y ago

> Appears the tech behind this "cheerpj" a java transpiled to javascript[1] system that appears to contain all of openjdk including swing(!?!). IANAL, but what about copyright here? AFAIU, you create a derivative work of JDK.

dragonwriter 9y ago
There is a reason for the “Open” in the name of “OpenJDK”.

merb 9y ago

> the world moved on. 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.

unclebucknasty 9y ago

>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.

le-mark 9y ago
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.
- unclebucknasty 9y ago
  >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.

skavish 9y ago

all our products are using GWT and they are super awesome, on the bleeding edge of technology! check it out: https://www.animatron.com https://www.animatron.com all this GWT bashing is from hipsterish kids who don't know anything else besides latest javascript frameworks.