loading...

re: How Blazor Is Going to Change Web Development VIEW POST

FULL DISCUSSION
 

This sounds very similar to GWT (though, modernized to run using webassembly and using C# instead of Java). Am I wrong about that?

Several things killed GWT:

  1. GWT applications were hard to debug since the generated JS was minified.
  2. GWT applications tended to have lots of spaghetti-like interactions with the server because it's easy to make RPC calls when everything is written in the same place, in the same language.
  3. The skills and thought processes required to create a good front-end application are quite different from those required to create a good back-end one (regardless of the technology you use).
  4. Google lost interest in the technology.

#1 might be made irrelevant if sourcemaps are supplied. #4 is probably irrelevant since MS seems lately to be a better steward of OSS.

#2 and #3 really are big issues with this kind of tech. Though, I'm interested to see where this goes.

 

I worked on several projects around 8 years ago using GWT and from my experiences the biggest drawback was the lack of the open source community support and boilerplate code to make it more manageable. Like adding a new place had big overhead. Wiring places, activity mapper adding view, we had to at least touch 10 Java classes just to add a new view.

I somehow couldn't agree with some of your points:

  1. GWT application are not hard to debug, classic / super dev mode imho doesn't make much different to me. I prefer to use the super dev mode, debug directly using chrome devtool.

  2. Depends how you make your application. We were using activity and places that was introduced in early 2013 or something was a big help. We followed Model View Presenter pattern and used UI binder. Basically each UI Component is isolated and doesn't have any business logic, it just call the presenter on user interaction (button pressed, value changed, etc).

  3. We had it separated between the client and server code and any of our programmer could work on one UI part and never care about the presenter / activity part. Tbh I see the similarity with dumb and smart component pattern in angular / react.

  4. We had hot reload without restarting server. We used standalone tomcat + GWT plugins in eclipse. Once we start the tomcat the gwt dev server started on itself. Launch setup is not much different than any other spring boot based project and dominating our software landscape atm.

GWT was dead because noone liked it, it was complex and hard to use, gwt 3rd party library was near to non existence. We also used RPC which only useful for that application. We couldn't leverage it. I wish we used rest backend already.

Sometimes you will need to use native javascript, so what you do, you write javascript code wrap it to your own java class using JSNI. I tbh dislike JSNI, it shows the limitation of GWT.

 

Good point about the lack of community around GWT. It was never properly supported by Google and once they lost interest in it, GWT was as good as dead.

code of conduct - report abuse