Tuesday, October 6, 2020

Re: Why Don’t You Use Java for Programming the Client-Side Web Apps on Web Browser?

Hi all
Here is my take on this,
I think for each argument from one side there is a counter-argument from the other side, and this is natural after all those are just 2 languages and 2 ecosystems, when both used to target the same goal, one will win in a specific area and lose in the other, they share the main concepts and they try to solve the same problems, they are only different slightly with the implementations.

I would say I always leave it to the use case and experience, now take a JavaScript/TypeScript developer who knows those very well and knows the ecosystem ask him to do what he used to do but in java, he will not do good and he will complain that JS is better, now get a Java developer who knows it very well and knows the ecosystem and ask him to do what he does but in JavaScript/TypeScript he will not do good and will complain Java is better.

If we take both above developers and let them showcase what they are doing with there best-preferred language for each other, they will impress each other. if you could have a developer who knows both very well, then that's a win.

The actual problem is when someone who knows Java for example very well, and does not actually know JS and out of hype he jumps to building apps with JS without spending enough time to actually learn it ( this is not cheap at all ), the same goes for JS developers.

At work I am building the UI interface for an application with Java/GWT/Dominokit, the UI application is somehow big, keeps growing, maintainable, integrates very well with our infrastructure (micro-services and micro-frontends), we deploy very often (several times per day), different teams working on different micro-frontends, we started as 2 developers now we have only working on the core part and the few microfront-ends and others working on other microfront-ends. we are being very productive.

W also have another project which is as big as the first one, but it is angular based, no microfront-end, large team (10+), the start was very very slow for this one and still until now it does not move as fast as it should be, but the issue was clear from the first few iterations in the project that it was not the language or the ecosystem, but it was the team themselves, they insist on using angular while they didn't actually know angular beyond few tutorials, they didn't know JS too, we had to teach them few things first.

The final result is what we produce in regards to the tool, 2 apps above could have lived the story revered where the Java one would be the one not doing well.

My conclusion is that you can do it with either, just make sure you are not wasting time and money. and spend enough time learning on the other side.

On Tuesday, September 29, 2020 at 7:52:29 PM UTC+3 lofid...@gmail.com wrote:
One thing to the Mocking framework: https://mswjs.io it looks indeed very interesting. 

In GWT I used to implement the mock implementation in "development time" and remove it in "production time" by using GWT options for different "sourcepath" and "entry point" with help of DI. It works very well. So I never have to run the "server / REST APIs" part to be able to develop the whole UI. Very productive.

.... and to try to answer your question: "what are the obstacles for you to use JS or TS (possibly mixed with Java through J2Cl) for frontend development?" here you are: 😉

(1) JS sofar is difficult to use for a bit complex UI. 

Quote from Anders Hejlsberg: 

"Developers by then had started to build huge JavaScript apps for the browser and were struggling to write them in JavaScript, a language he says lacked key features like modules, classes, and, importantly, a type system for creating order through rules in a program."

This interview is a must read: http://bit.ly/AndersHTypeScriptInterview

You can see today that all of those a bit complex frameworks use TypeScript instead of JavaScript (VueJS 3.0, Angular, ...)

Conclusion: JavaScript is in this form today difficult to use.

(2) TypeScript is definitely very good as I already said above in this thread. But I cannot see the advantages using TS if you come from Java and can use GWT / J2CL. If you have frontend developers, yes, TS is definitely the way to go since it is more similar to JavaScript. I know that Erich Gamma moves from Java / Eclipse to TypeScript / Visual Studio Code / Electron but sofar I cannot see that VSC is better than Eclipse. So, yes, very interesting to be able to write those things also in Web browser with TypeScript and you can embed it into GitHub as a web editor.

The reason: "Theia is a framework to build web IDEs. It is built in TypeScript and will give contributors a more enjoyable experience with a programming model that is more flexible and easier to use, and makes it faster to deliver their new plugins." But I'm not sure why they could not build plugins based on GWT which is flexible and easier to use. As we know we all like to begin from scratch and don't like the idea of maintenance 😀😅

Introducing TypeScript to a Java team is a different story. The language is the smallest problem but the ecosystem, library, build, CI/CD pipeline, dependencies management, artifacts scanner, etc.(see the presentation of Netflix above). For many companies you mostly have some intelligent forms and for this purpose I don't see that TypeScript has advantages in comparison with Java / GWT / J2CL (of course we need to address the UI frameworks based on TS or GWT / J2CL as well). One thing you should not forget, on-boarding process of new developers and the ability to be a full-stack team. A team which all the developers can do everything, from frontend to server-side implementation (not to have separation between frontend and backend developers).

Conclusion: TypeScript is the way if you have JavaScript developers. If you are coming from Java with Java developers in team, IMHO GWT / J2CL is the way to go. It is also fun to work with the modern GWT web apps 😀😉👍

Just my 2 ct.

t.br...@gmail.com schrieb am Dienstag, 29. September 2020 um 13:45:56 UTC+2:


On Tuesday, September 29, 2020 at 12:08:36 AM UTC+2, lofid...@gmail.com wrote:
OK, now I understand you 😉

Yes, we always have to separate the Client and the Server part. This is also GWT best practice.

But if you are using JavaScript on browser you lose the advantages like:
  1. We use Java as the language

Is Java objectively the best language out there to be used as an argument that way?
 
  1. We have the best ecosystem like libraries, frameworks, build system and IDEs.

Please define in which way they're "the best".
In terms of dependency management, NPM and Yarn are probably better than Maven (but not Gradle, which looks unrivaled on that point).
In terms of build systems, I hope you're not trying to compare anything to Maven; but I also wonder how you're going to do things like PostCSS, Imagemin, SVGO, etc. do with a J2Cl toolchain. GWT does some of those (not all), but the JS frontend ecosystem is the clear winner on that point.
VS Code, and probably (I never used them for non-JVM projects) IntelliJ IDEA / WebStorm, and I suppose Visual Studio too, are absolutely great IDEs too for JS and/or TypeScript (and Go, and probably many others).
  1. We know best design patterns to make our apps maintainable like Dependency Injection, Mock Testing and many other just take a look at: http://bit.ly/DesignPatternsJava

Wow, how condescending!
BTW, as already pointed by Rodolfo, design patterns are language independent. The "GoF" Design Patterns book has all its examples in C++ and Smalltalk, not Java; and that link you give lists exactly those patterns from the book.
I do miss Dependency Injection from time to time in JS devs, but if you really want/need it, there are ways to do it (React Context for example); and Angular does DI: https://angular.io/guide/architecture-services#dependency-injection-di
Mocking is overrated, but far from impossible in JS, including for network access: https://mswjs.io/ and even though I personally rarely do automated testing of frontend devs (and that's true of GWT too), the JS ecosystem has some quite good libraries as well (testing in a browser environment with GWT is quite "outdated" in comparison: HtmlUnit or the defunct SeleniumRC, or manually launching your browser; fortunately we're doing better with J2Cl by leveraging Selenium/WebDriver).
 
  1. … and if you use Java on the server-side with Spring Framework or JavaEE you have one language through the whole stack. So, you could reuse Validation APIs, Business Rules, Business Model, etc. from server to client.

If you do need to share code, then J2Cl is for you; but that doesn't mean using Java for the whole client-side app. That's actually exactly what J2Cl was built for, in replacement for GWT inside Google: leveraging Closure for web development while being able to share code with the backend through J2Cl (and mobile native apps, through J2ObjC for iOS).

Back to your original question: 
I would like to know, what are the obstacles for you as Java developers not using Java as programming language for writing Web browser apps.

First, I don't consider myself as a "Java developer"; I'm a developer, and I'm proficient in Java (but also JavaScript and Kotlin, somewhat less in Go or Python, and I could probably still do good things in PHP if you forced me to use it).
Now let me return the question: what are the obstacles for you to use JS or TS (possibly mixed with Java through J2Cl) for frontend development?

I'm not saying you shouldn't use Java (we wouldn't be there otherwise), I'm questioning why you wouldn't use something else.
By describing yourself as a Java developer (and praising the Java language and ecosystem like you do), it looks like maybe it could be because you don't know anything else, treating Java like your golden hammer (https://en.wikipedia.org/wiki/Law_of_the_instrument)

My personal take on it is: it depends. It depends on the project (what it does, whether you need to leverage some existing Java or JS library, its size, whether you need to share code with the server and/or native mobile apps, etc.), and of course the project team and its skills.

--
You received this message because you are subscribed to the Google Groups "GWT Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit/c605e3ac-1e77-4f83-93a0-ac1836fabd63n%40googlegroups.com.

No comments:

Post a Comment