10 ms·
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
by dxbydt 14y ago
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.
- Arelius 14y ago> 200 average developers This is the problem, and as you implicate, the exact sort of thing we need to stop doing.
- taligent 14y agoSure. So long as you have a full proof way of identifying the best developers. Hint: the best developers aren't the ones who can recite the API off hand.
- rabidsnail 14y agoYou have to be willing to fire them if it turns out they're they suck.
- tatsuke95 14y agoAverage != suck. 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.
- rabidsnail 14y agoYou can do a hell of a lot with a 10-15 person team. Unless you're consulting your company can grow much faster than your team.
- mixitup12 14y agoFool. Fool proof. Not full.
- Daniel_Newby 14y agoThanks, you really honed in on that mistake. <runs away>
- FixThisPOSSite 14y ago"Full proof"?
- radicalbyte 14y ago> Sure. So long as you have a full proof way of identifying the best developers. It's easier to grow them.
- apl 14y ago> This is the problem, and as you implicate, > the exact sort of thing we need to stop doing. You do see the absurdity here, right? Banking on substantially above-average developers doesn't work at scale, by definition.
- heretohelp 14y ago>20 pricey smart JQuery guys See, this is how I knew you knew nothing about JavaScript. My bets, you're a manager that manages shitty Java coders who "used to code" and is an obnoxious know-it-all. Scale of 1-10, how close am I? Edit: From your website: "currentlly: BofA" (sic). Feeling pretty warm on my bet so far.
- mixitup12 14y agoLike
- geuis 14y agoWrite intelligent comments that advance the discussion in some way. This is not reddit.
- joshmlewis 14y agoI don't even think that would fly on Reddit.
- malandrew 14y agoSo 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.
- heretohelp 14y agoGood to know somebody understood what I was talking about. This is why I don't ask for a "jQuery" guy, I ask for a frontend engineer who's a solid programmer and likes working on interesting products.
- cracell 14y agoI 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.
- grimlck 14y agoInstead 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'.
- Hovertruck 14y agoThere is no such thing as a jQuery Programmer. There are JavaScript programmers who are familiar with jQuery.
- lowboy 14y agoSadly, I think there are jQuery "programmers".
- itsbits 14y agoi garee..not all so called JQuery programmers can be atleast able to debug a low level JS...
- johncoltrane 14y agoThere 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.
- kamjam 14y agoYes, sadly you are right, and it's cos of this (IMO) that you end up in this situation. I'd hire an average JS guy over a average jQuery guy any day.
- nathan_long 14y ago200 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.
- mcot2 14y agoI 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".
- einhverfr 14y agoMoreover the original author says "JavaScript is not suitable for large web apps. 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.
- atesti 14y agoWhy 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?
- regularfry 14y agoI don't think they're running in a browser on the open web.
- deleted 14y ago[deleted]
- rehack 14y agoI 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).
- allanebdrup 14y agoYou 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.