Live data from Hacker News

JavaScript is not suitable for large web apps

blogs.adobe.com

21–30 of 218 posts

Re: JavaScript is not suitable for large web apps

#22
GWT? Seriously? I cannot think of any large, significant web app that has been written in GWT.

I thought it would be clear by now that we do not need Java Enterprise in our web browsers. The web seems to be moving the other way - we have lightweight libs such as jQuery, underscore, backbone etc... and they seem to provide JS with the necessary building blocks for larger, maintainable systems.

Re: JavaScript is not suitable for large web apps

#23

This is more of a rant against dynamically typed languages than against javascript itself, and making the argument that dynamically typed languages are not suitable for large web apps is a difficult (not impossible) one to make. The author also complains about some javascript projects being split up into enough files, which is hardly a side-effect of using javascript. The author inherited what sounds like a pretty di…

I also find objections like the "createBunnyOrToaster" antipattern to be really, really uncompelling. You don't need a static type system to make sure that your functions are sane and consistent, and you don't have to be John Resig either.

First of all, put a comment at the top of your function that says what to expect about the return value. You should be doing this anyway because the return type alone is often not sufficient for future programmers reading your code.

Secondly, every time you write the word "return", look up at the top of your function and make sure you are in accordance with what you said the function would do. If you end up with a paragraph comment about what the return value will be like, refactor.

Re: JavaScript is not suitable for large web apps

#24
Like many commenters here, I'm not sure I can agree with the author's position. Plenty of in-browser apps go awry, but that's most often because the tools people start using (notably jQuery) just don't work well once you have a large collection of UI components on the page.

That said, the bulk of Google's web applications, for instance, are not written in GWT or Dart, but rather in JavaScript using Closure Library, and compiled using the Closure compiler. So I don't think the answer here is to not use JavaScript (although I can understand why people at Adobe would argue for that), but rather to use tools like Closure or Angular that make the process more straightforward.

Re: JavaScript is not suitable for large web apps

#25

GWT? Seriously? I cannot think of any large, significant web app that has been written in GWT. I thought it would be clear by now that we do not need Java Enterprise in our web browsers. The web seems to be moving the other way - we have lightweight libs such as jQuery, underscore, backbone etc... and they seem to provide JS with the necessary building blocks for larger, maintainable systems.

GWT? Seriously? I cannot think of any large, significant web app that has been written in GWT.

I would consider the AWS management console to be significant.

Re: JavaScript is not suitable for large web apps

#27
post #3

As I read more of these arguments, it makes me think a lot about whether I should switch to CoffeeScript before my web app gets any larger. Has anyone switched to CS or another language that compiles to JS, and regretted it?

CoffeeScript is a syntax, not a language.

His arguments have to do with the semantics of JavaScript, which are identical to the semantics of CoffeeScript.

Re: JavaScript is not suitable for large web apps

#28

GWT? Seriously? I cannot think of any large, significant web app that has been written in GWT. I thought it would be clear by now that we do not need Java Enterprise in our web browsers. The web seems to be moving the other way - we have lightweight libs such as jQuery, underscore, backbone etc... and they seem to provide JS with the necessary building blocks for larger, maintainable systems.

AdWords, AdSense, Flights, Hotel Finder, Offers, Wallet, The New Blogger, Chrome Webstore, Product Search, Public Data, New Google Groups, Orkut, Google Takeout, Google Pagespeed, Google WebFonts, Google Tables, Google Health (discontinued), Google Wave (discontinued), PlayN (basis of Angry Birds)

http://gwtreferencelist.appspot.com/#AboutPlace:

Re: JavaScript is not suitable for large web apps

#29
Did they lint or unit test their code? Without having a way to verify that parts of your app work at a smaller level, of course it's going to get hairy when it starts to grow. Although a compile step verifies types, unit tests do that plus check against runtime errors. This is not a language problem.

Re: JavaScript is not suitable for large web apps

#30
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.
Post reply on HN