Live data from Hacker News

JavaScript is not suitable for large web apps

blogs.adobe.com

171–180 of 218 posts

Re: JavaScript is not suitable for large web apps

#171
post #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 Jav…

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?

Re: JavaScript is not suitable for large web apps

#172
post #82

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

I know what GWT is. I agree that it provides out of the box certain functionalities that require a bit of "glue code" when using other frameworks.

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

#173
i dont know why nobody ever talks about pyjs.org. to me it takes the best ideas of gwt, simplifies it, and then lets you use python instead of java. sure its a little bleeding edge, and not being heavily developed (because it already works good enough?), but who cares. i dont need the worlds fanciest framework with new features every five minutes. i dont need pythons metaclasses for browser apps. i just need simple, bare bones widgets that wrap html and to be able to write python. javascript is fine, but python is just so much more productive. syntactic sugar counts. readability counts. and python will never run native in the browser so we all need to move on.

pyjs 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

#174
I used to write 10-20kloc projects in javascript. Don't know if its large enough for you but i dont feel any problem to maintain large js applictions written by good programmers. Try CoffeeScript anyway. BTW "jQuery programmer" sounds obnoxiously we are javascript programmers.

Re: JavaScript is not suitable for large web apps

#175
post #137

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

Fair point -- it's unfair to stereotype Java developers. In my mind, I meant "most developers" and I happened to be talking about Java. But that distinction wasn't clear.

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

#176
post #89

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

Sadly, I think there are jQuery "programmers".

Re: JavaScript is not suitable for large web apps

#177
post #89

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

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.

Re: JavaScript is not suitable for large web apps

#178
It seems to me this is a discussion on two levels: statically versus dynamically/weakly typed languages in general, and ActionScript versus JavaScript in particular.

Concerning 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

#179

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

Actually a pretty decent part is in JS since most of the standard libraries are purely written in JS. Github claims that nearly 70% of the node repository is in JavaScript.

Re: JavaScript is not suitable for large web apps

#180
post #167

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

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