3 ms·

Any Java developer who doesn't know about callbacks, async logic, recursion, event handling, etc isn't much of a Java programmer and sounds more like someone ou

Any Java developer who doesn't know about callbacks, async logic, recursion, event handling, etc isn't much of a Java programmer and sounds more like someone out of a IT-Mill shop. I mean, come on, Java's platform APIs are full of callbacks, java.util.EventListener has been around since JDK 1.1. java.util.concurrent was introduced in Java5 which introduces a bunch of async/callback interfaces. Then there's Guava, the most popular add on library, which itself introduces a lot of async primitives. On top of that, a lot of mobile developers on Android use RxJava, and Java8, both of which heavily rely on lambdas, and introduce stream processing APIs. The only real issues seasoned Java developers run into on the frontend is having to deal with CSS, Layout, Paint, and cross browser issues. I have never encountered a Java programmer who didn't know what recursion was. Javascript doesn't even have tail call elimination, so there's no reason why a JS programmer should be expected to have some kind of advantage in that category. At the time GWT was created (2004), the Javascript ecosystem was absolute garbage, and jquery was pretty much the primary way most people got anything done. By contrast, GWT and Closure Compiler, enabled very large SPAs to be constructed, as well as code splitting, something that took years to finally arrive in the JS ecosystem, and even today, the code splitting I see in the wild still is inferior to what Closure's cross-module method/code motion does. It is certainly true that the Javascript ecosystem has come a long way since ES3, IE6/8, browser compliance to the HTML5 spec has converged, and that GWT's layering over the DOM/UI is no longer needed. But that's not what J2CL is for. J2CL is about sharing business logic between platforms. For example, Google Inbox was what J2CL was created for, 75-80% of runtime code and unit tests, are shared between Android, iOS, and the Web. On Android, the code has no impedance mismatch, and on iOS via j2obj and JS (via J2CL) the impedance is very low thanks to almost zero-overhead interop layers. J2CL is not meant for "write once run anywhere UI" The philosophy of using it is that you can, and probably should, write the UI code in the 'impedance matched' language for that platform (e.g. ObjC/Swift for iOS, Java/Kotlin for Android, ES6/TS for Web) By contrast, approaches like React-Native to construct large cross platform code sharing are fraught with problems, from trying to share UI code, to running in resource hungry, battery draining, poor performing JS VMs. I'd say if you're a Java programmer who wants more expressiveness AND an impedance match for the primary ecosystems Java lives in, Kotlin would be a much better target. Kotlin is dramatically simpler than Scala, has a faster and less buggy compiler, and competitive with Typescript in terms of expressiveness. There's even Kotlin->JS, Kotlin->WASM, and there's even been some Kotlin->J2Cl prototypes.

austincheney 8y ago
> Any Java developer who doesn't know... I take it you work for Google or contribute to projects under management of Google. Perhaps Google is more selective in their hiring. My claims about Java developer generalizations comes from a decade in the travel industry with 4 of its largest corporate brands, each (at one time) employing thousands of developers. This is the reality of big corporate software development. Take a look at any major corporate brand presence with a website and notice how many megs are downloaded for small amounts of content and tiny interactions. Consider that content quantity served on webpages has not dramatically increased since the 90s and the interactive experience has gotten better since the 90s, but not by orders of magnitude. Yet, despite high speed connections it takes longer to load most corporate websites now than it did back then. It seems, from the bloat, exchanging developer competence for tooling and ecosystem advancement has a had a negative correlation on performance and code quality. I completely understand this is an over simplification, but most problems solved by ecosystem advancement aren't problems related to any business requirement or user concern. Most of those problems are things only developers care about. The changes to the platform that actually do relate to business concerns are generally addressed as enhancements to the technology standards that comprise the platform. If you do work at Google you have access to economists and can get their opinion on this matter.
- cromwellian 8y ago
  I do work for Google, but I've also worked at Oracle, IBM, several startups, and in enterprise consulting. Yes, Enterprise software is full of very low quality development, but this is language independent. I have seen plenty of web developers in enterprise whose sole skill was cut-and-pasting jquery snippets from web searches and tutorials and using jquery plugins. I've also seen some pretty terrible Ruby-on-Rails stuff in the enterprise. Actually, Obamacare's launch was stymied by poor Ruby code, and I hear Square at one point had problems with their Ruby, hired a bunch of Xooglers, who redid everything in Java. (and released some kick ass Java open source libs, like Retrofit, Dagger, etc) The common variable isn't Java, or Javascript, or tooling, it's Enterprise IT hiring inexperienced or unqualified engineers, often consultants, some of whom don't have degrees in engineering/CS, or are from body shops. Once enterprise switches most of the legacy systems from Java or Ruby to Node, you're going to find exactly the same people writing horrible code. You can already start to see it in the Node ecosystem, and in Kubernetes (go ecosystem), with people piling high on dependencies and frameworks, layer upon layer, of new-fangled tools and magic that will solve your enterprise problems, but what it ends up doing is creating a brittle system of crushing complexity and bloat and silos of IT department people who have narrow specific skills as opposed to general purpose engineering skills. The big tech companies in the valley don't look for candidates who have acronyms on their resumes "Java/Javascript/SQL/noSQL/RDBMS/J2EE/XML/SOAP/...." or professional training certifications, they look for people with general purpose engineering skills who can learn any language needed, and who generally adhere to good practices and habits. Back in the 90s, I taught retraining courses to enterprise and government workers. Many of them had never done coding before outside some basic Office or Lotus Notes scripting, and some of them were former COBOL users. A lot of them were reading books like "Perl, CGI in 21 days" or "Java in 21 days". And that's the problem, because the proper way to retrain your employees isn't to send them for a crash course. It's to hire some very good engineers and engineering managers, and let them learn as apprentices having their code reviewed by them. I don't want to bash all enterprise developers, there are some excellent companies out there doing good work. But my general impression from years of cleaning up messes I encountered in consulting, is that corporate IT departments don't care about things like code health or tech debt. This isn't a Java specific problem, it was there with COBOL, and it's there with Ruby, and it'll be there with Node. It's just whatever is Enterprise's favorite fad du jour will eventually be given a bad rep. If enterprise was using Haskell, even Haskell code would come out with a bad rep. :)

austincheney 8y ago

> Any Java developer who doesn't know... I take it you work for Google or contribute to projects under management of Google. Perhaps Google is more selective in their hiring. My claims about Java developer generalizations comes from a decade in the travel industry with 4 of its largest corporate brands, each (at one time) employing thousands of developers. This is the reality of big corporate software development. Take a look at any major corporate brand presence with a website and notice how many megs are downloaded for small amounts of content and tiny interactions. Consider that content quantity served on webpages has not dramatically increased since the 90s and the interactive experience has gotten better since the 90s, but not by orders of magnitude. Yet, despite high speed connections it takes longer to load most corporate websites now than it did back then. It seems, from the bloat, exchanging developer competence for tooling and ecosystem advancement has a had a negative correlation on performance and code quality. I completely understand this is an over simplification, but most problems solved by ecosystem advancement aren't problems related to any business requirement or user concern. Most of those problems are things only developers care about. The changes to the platform that actually do relate to business concerns are generally addressed as enhancements to the technology standards that comprise the platform. If you do work at Google you have access to economists and can get their opinion on this matter.

cromwellian 8y ago
I do work for Google, but I've also worked at Oracle, IBM, several startups, and in enterprise consulting. Yes, Enterprise software is full of very low quality development, but this is language independent. I have seen plenty of web developers in enterprise whose sole skill was cut-and-pasting jquery snippets from web searches and tutorials and using jquery plugins. I've also seen some pretty terrible Ruby-on-Rails stuff in the enterprise. Actually, Obamacare's launch was stymied by poor Ruby code, and I hear Square at one point had problems with their Ruby, hired a bunch of Xooglers, who redid everything in Java. (and released some kick ass Java open source libs, like Retrofit, Dagger, etc) The common variable isn't Java, or Javascript, or tooling, it's Enterprise IT hiring inexperienced or unqualified engineers, often consultants, some of whom don't have degrees in engineering/CS, or are from body shops. Once enterprise switches most of the legacy systems from Java or Ruby to Node, you're going to find exactly the same people writing horrible code. You can already start to see it in the Node ecosystem, and in Kubernetes (go ecosystem), with people piling high on dependencies and frameworks, layer upon layer, of new-fangled tools and magic that will solve your enterprise problems, but what it ends up doing is creating a brittle system of crushing complexity and bloat and silos of IT department people who have narrow specific skills as opposed to general purpose engineering skills. The big tech companies in the valley don't look for candidates who have acronyms on their resumes "Java/Javascript/SQL/noSQL/RDBMS/J2EE/XML/SOAP/...." or professional training certifications, they look for people with general purpose engineering skills who can learn any language needed, and who generally adhere to good practices and habits. Back in the 90s, I taught retraining courses to enterprise and government workers. Many of them had never done coding before outside some basic Office or Lotus Notes scripting, and some of them were former COBOL users. A lot of them were reading books like "Perl, CGI in 21 days" or "Java in 21 days". And that's the problem, because the proper way to retrain your employees isn't to send them for a crash course. It's to hire some very good engineers and engineering managers, and let them learn as apprentices having their code reviewed by them. I don't want to bash all enterprise developers, there are some excellent companies out there doing good work. But my general impression from years of cleaning up messes I encountered in consulting, is that corporate IT departments don't care about things like code health or tech debt. This isn't a Java specific problem, it was there with COBOL, and it's there with Ruby, and it'll be there with Node. It's just whatever is Enterprise's favorite fad du jour will eventually be given a bad rep. If enterprise was using Haskell, even Haskell code would come out with a bad rep. :)