Comment by dxbydt | Hacker News Reader

Comment by dxbydt | Hacker News Reader

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.

> 200 average developers

This is the problem, and as you implicate, the exact sort of thing we need to stop doing.

Sure. 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.

You have to be willing to fire them if it turns out they're they suck.

Average != 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.

You 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.

Fool. Fool proof. Not full.

Thanks, you really honed in on that mistake. <runs away>

> Sure. So long as you have a full proof way of identifying the best developers.

It's easier to grow them.

  > 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.

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 is no such thing as a jQuery Programmer. There are JavaScript programmers who are familiar with jQuery.

Sadly, I think there are jQuery "programmers".

i garee..not all so called JQuery programmers can be atleast able to debug a low level JS...

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.

Yes, 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.

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".

Moreover 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.

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?

I don't think they're running in a browser on the open web.

>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.

Like

Write intelligent comments that advance the discussion in some way. This is not reddit.

I don't even think that would fly on Reddit.

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.

Good 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.

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.

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.

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.

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.

I'm not happy that the top reply to the top comment on this post is a blatant ad hominem.

What's your point about JavaScript?

Apologies.

I'm not happy that somebody who very evidently doesn't have a clue what they're talking about is the top comment.

When people stop upvoting complete and utter tripe (which is nutritious btw), my response stops being necessary.

I'd react the same way to any sort of ignorant pontification on clearly foreign (to them) material.

Raise a fool on a litter and I'll tackle the people carrying the litter.

I'm quite open to being proven wrong, but I don't expect to be.

Ah. The "commenting to point out insanity upvotes by default" paradox. Quite ironic. Quite.

Reply on news.ycombinator.com