4 ms·
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
by cromwellian 8y 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.