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 Jav…
JavaScript is not suitable for large web apps
171–180 of 218 posts
Re: JavaScript is not suitable for large web apps
#172GWT? 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 doesn't get the fair share of respect it deserves. It's not enterprise java (j2ee and such), it's a toolkit that (amongst other things) lets you write and debug java, that gets compiled to javascript in the end. GWT is not modular in the same sense as jQuery/underscore/backbone/any other js library, that's its weakness but also its strength. Also, the same modularity of those libs is simultaneously its strength a…
However, the whole "just write a desktop app and we will turn it into a web app" philosophy doesn't seem very web-oriented to me. Yes, it works, it's easy, but if one day you want to change your client-side code (i.e. use a different framework or something) you'll most likely have to change the server side as well. It just seems to be too RPC-centered and too monolithic. But maybe I'm wrong.
Re: JavaScript is not suitable for large web apps
#173pyjs works great now, and makes one highly productive. it just needs a bigger community of users (and developers?). so anyone asking the types of questions raised here should try it. then you can bash it on hn, right? :)
Re: JavaScript is not suitable for large web apps
#174Re: JavaScript is not suitable for large web apps
#175There are reasonable objections to JavaScript, but this is inane. He uses an example of someone committing a classic mistake in software design. This error would be the same in JavaScript or Java. I'd like to see how his ActionScript translation magically fixed it. However, the remedies for the mistake differ in each language. It is somewhat difficult to fix it in Java's statically typed straightjacket (which I assum…
>In my experience most Java developers don't even do that. They... It's awesome how, on Hacker News, people whose job require them primarily write code in Java are some sort of stupid luddites ready to be easily generalized as the worst kind of programmer. Way to stay objective, guys.
It's obvious that (in the OP's case) using JavaScript didn't help the problem either -- but that was my point. Bad design is bad design. I am not making a strong claim that JS is better.
Re: JavaScript is not suitable for large web apps
#176Earlier quoted context omitted.
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.
Re: JavaScript is not suitable for large web apps
#177Earlier quoted context omitted.
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.
Just to be clear: I don't like this situation at all.
Re: JavaScript is not suitable for large web apps
#178Concerning the first aspect, the most important advantage I see in static typing is not that is finds bugs (tests are better in that discipline), but that it leads to much better IDE support. Only in a statically typed language, the IDE can definitely find out which class, method or field your code actually refers to, which allows for code navigation, documentation lookup, and last but not least intelligent refactoring support.
Concerning ActionScript versus JavaScript, I must say that I like and respect JavaScript a lot and want to keep its "good parts" (a la Crockford), but I also want to be able to take advantage of static typing for the reasons given above. Thus, although the company I work for is not affiliated with Adobe in any way (rather on the contrary), we were looking for the statically typed language that is closest to JavaScript and finally chose ActionScript 3. We then built a cross-compiler from ActionScript to JavaScript years before Adobe/Bernd Paradies did. We have improved and been working with this tool since 2004 (starting with JavaScript 2/ECMAScript 4) and never regretted following this approach. In contrast to Adobe's tool, "Jangaroo" is Open Source and ready to use now. It focuses on integrating with, not replacing JavaScript, and we help solve problems like dependency management for JavaScript and reuse such solutions for generated JavaScript code. Jangaroo's generated JavaScript code does not look like assembly language, but as much as the AS3 source code as possible.
It's not always black or white, I believe we can use the best of both worlds!
Re: JavaScript is not suitable for large web apps
#179Earlier quoted context omitted.
Large parts are written in C++ :)
I'm pretty sure that very little of it is actually in js. It's more appropriate to say that you use javascript to script the node environment/runtime.
Re: JavaScript is not suitable for large web apps
#180Earlier quoted context omitted.
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.