3 ms·

"The primary problem was Java developers compiling code where they had no idea what the output was doing." By that argument anything but assembler is garbage.

austincheney 7y ago
I suppose I should have been more clear. Generally when people compile code they may not be able to read the compiled output, but they still have some idea of what that output is doing. To prove they know what the output is doing they write positive and negative tests. In the case of GWT the Java developers actually had no idea what the output was doing. They, I presume, had some idea what the originating Java code was doing and needed logic to execute in the browser. However, the browser is/was a foreign environment not well understood. There were times they were not exactly sure how to execute the output much less test it. They just knew GWT would generate JavaScript vaguely reflective of their Java input and that web browsers would execute that JavaScript.
- cromwellian 7y ago
  It's really impossible for anyone to develop a non-trivial GWT project without having to compile in PRETTY/Draft mode and drop into a Web debugger. GWT's Java debugging support was great for business logic, but you could not step into a lot of UI code, and almost universally, you ended up looking at the source code to the Widget library to understand what's going on. This had nothing to do with Java->JS transpilation, and everything to do with GWT's UI SDK. If I gave a Javascript developer a heavy weight OO UI library abstraction where they constructed UIs by doing "new Listview(), new Button(), list.addChild(button), etc" and had it hide CSS, DOM, and other Web issues, you'd run into exactly the same issue of leaky abstractions and people not knowing what was going on. The issue with GWT was API design, not language. The way Java was translated to JS (unoptimized) was straightforward and understandable and arguing otherwise IS like arguing C compiled to Assembly is a problem. J2CL even more so is straightforward, was designed to transpile to "clean" ES6 that resembles hand written JS classes. GWT "hid" the Web behind heavyweight widgets. J2CL doesn't. How many React JS developers have a clue as to how VDOM is implemented? Here's some J2CL web code: var div = document.createElement("div"); div.setInnerText("Hello World"); document.body.appendChild(div); div.addEventListener("click", evt -> window.alert("You clicked me!"), false); This compiles to almost 1:1 what you'd get in Typescript->JS.

austincheney 7y ago

I suppose I should have been more clear. Generally when people compile code they may not be able to read the compiled output, but they still have some idea of what that output is doing. To prove they know what the output is doing they write positive and negative tests. In the case of GWT the Java developers actually had no idea what the output was doing. They, I presume, had some idea what the originating Java code was doing and needed logic to execute in the browser. However, the browser is/was a foreign environment not well understood. There were times they were not exactly sure how to execute the output much less test it. They just knew GWT would generate JavaScript vaguely reflective of their Java input and that web browsers would execute that JavaScript.

cromwellian 7y ago
It's really impossible for anyone to develop a non-trivial GWT project without having to compile in PRETTY/Draft mode and drop into a Web debugger. GWT's Java debugging support was great for business logic, but you could not step into a lot of UI code, and almost universally, you ended up looking at the source code to the Widget library to understand what's going on. This had nothing to do with Java->JS transpilation, and everything to do with GWT's UI SDK. If I gave a Javascript developer a heavy weight OO UI library abstraction where they constructed UIs by doing "new Listview(), new Button(), list.addChild(button), etc" and had it hide CSS, DOM, and other Web issues, you'd run into exactly the same issue of leaky abstractions and people not knowing what was going on. The issue with GWT was API design, not language. The way Java was translated to JS (unoptimized) was straightforward and understandable and arguing otherwise IS like arguing C compiled to Assembly is a problem. J2CL even more so is straightforward, was designed to transpile to "clean" ES6 that resembles hand written JS classes. GWT "hid" the Web behind heavyweight widgets. J2CL doesn't. How many React JS developers have a clue as to how VDOM is implemented? Here's some J2CL web code: var div = document.createElement("div"); div.setInnerText("Hello World"); document.body.appendChild(div); div.addEventListener("click", evt -> window.alert("You clicked me!"), false); This compiles to almost 1:1 what you'd get in Typescript->JS.