For a certain definition of "large" and for certain domains ( especially finance ) his argument is very, very valid. 200 average developers working with GWT->JS are anyday going to be more productive than coding native JS to get the same functionality. This isn't anti-JS...end of the day if you are on the web your code is JS. Thing is, how do you get there - do you hire 20 pricey smart JQuery guys, or 200 average Java pgmmers. Pls go to a bank or any large finance shop - TONS of Java programmers, very familiar with navigating through verbose boilerplate Java code, very familiar with coding up some risk function or pricing algorithm in Java...mostly by abusing the heck out of the optimized collections library and its search & sort algos :) But so long as the damn pricing function prices corectly, eveybody's happy. So now all that stuff has been built & is sitting there as desktop apps with dirty swing UIs. 1000s of Java classes. Literally tens of 1000s. Nobody is going to rewrite it in JQuery/JS/coffeescript => No money, no mandate, no manpower, no expertise, but primarily no need to do so. GWT has captured precisely that sweet spot. First get rid of the fancy swing widgets - stick to simple GWT textareas & lists & panels & checkboxes & stuff. Then get rid of Java collections - replace with GWT lightweight collections. Then check some corner cases. Then compile to JS & optimize & you are done. The same shit now works on the web, & if its buggy you just debug your desktop app because they are essentially using the same logic. This is just how it is done in large financial shops. You are simply not going to hire JS folk & teach them financial algos & then get them to code those up in idiomatic jquery...takes too long. Just train the existing Java folk who already have the domain expertise to move from fullblown Java + swing to lightweight collections + GWT. It doesn't have to be pretty. We are not web shops or consumer frontends...this will still be accessed by people inside the bank...only not by downloading applets & standalone java apps, but via native JS.
Anyone who thinks they are going to do nothing but hire above-average programmers at any scale is downright naive. Design your system around an "average" employee, and you'll be far happier.
200 developers of any kind simultaneously working on the same code base sounds like a nightmare to me. I sincerely hope they have many separate projects that communicate via APIs or something.
Instead of comparing '20 smarty JQuery guys' with '200 average Java programmers', how about comparing '20 average JQuery programmers' with '20 average Java programmers'? Or comparing '20 smart JQuery guys' with '20 smart Java programmers'.
There are lots of jQuery programmers. They know (how to read the docs of) the whole API and close to nothing about low-level JS. jQuery is a powerful and useful tool but it has grown to "replace" JS in the minds of many.
Just to be clear: I don't like this situation at all.
I think your example of an Enterprise Finance app and TONS of Java programmers is over generalizing things a bit, of who can benefit from things like GWT.
I would contest, GWT is used by some people who sort of already grokked some of the points made by this article, some years back. For example, coding in JS giving a feel of coding in assembly, particularly without the help of any good editors.
Another example to break the Enterprise only narrative: 'Google Flights' is done in GWT. And you and me can guess, there won't be 200 avg developers coding that product.
I came from an Enterprise background before our Internet Startup. Few of us coded up our app, in 3 months flat out using mainly Java and GWT.
One of the reasons we chose GWT was that, when we started out IE 6 still had a considerable share, and GWT generated JS which ran on it very well (although slowly).
You fail to make a general point about JS. Instead you make the point that jQuery is inadequate for large apps, and I agree. Just because you failed with jQuery dosent mean JS can't be used. I've seen Big JS projects go horribly wrong, but I've alse seen big C# projects go horribly wrong (And COBOL and ...). Every time the projects didn't have good tests, a CI server, nightly builds, structured code reviews, a modular and simple design etc. If you use all the good practices available, big JS projects become maintainable.
It shines through in your post that you didn't do it close to right.
I guess I am not understanding why you would be compelled to re-write massive Java apps in JavaScript. Especially anything to do with heavy finance algos.
Replacing swing UI's seems like a reasonable thing to tackle using HTML/CSS/JavaScript. You could just pass data back and forth over HTTP if you are talking remote client/server or bundle a local webserver if running host only.
In the case of a platform like Windows 8, you can write actual apps using JavaScript (no server) but you can also write libraries in native code and access them directly from the JS.
I think this is just a classic case of "use the right tool for the job".
I am serious: Don’t write large web apps in JavaScript."
I don't know how the first flows from the second. Certainly I wouldn't write a large web app in Javascript! I might write Javascript in a large web app though.
So I agree and think the original article overreached.
Why exactly would one run financial pricing functions inside the browser? Doesn't this stuff belong in the backend and far out of the users reach? Isn't that insecure or gives up secret stuff?
So so true. If you are hiring "pricey smart [sic] jQuery guys" then you're probably doing it wrong. You need to be looking for solid software engineers that know javascript well. If the developers you are hiring think (jQuery === javascript) and can't explain the difference between classical and prototypal inheritance , then you're screwed before you even begin.
Funny, the exact same question came up today. I'm curious what the actual difference between the two is as it's not apparent. (I use a mixture of function prototype with the extends pattern and CoffeScript which exports a function exporting a function.) From what I can see they behave the same as long as you follow the same pattern when writing a subclass.
The main difference in many cases is memory usage. When cloning in prototypal inheritance, you point back to the prototype's function, unlike classical inheritance where you are copying methods on every instantiation.
Prototypal inheritance is native to JavaScript while, simply because JS doesn't have classes, you have to go through quite a lot of troubles to make classical inheritance work.
I dislike the term frontend engineer or frontend anything because people use it to mean a whole range of things between JavaScript programmer, web designer, and HTML/CSS scripter. And while some people possess all three of those very different skills they are not at all the same thing.
