Live data from Hacker News

JavaScript is not suitable for large web apps

blogs.adobe.com

201–210 of 218 posts

Re: JavaScript is not suitable for large web apps

#201
post #98

Earlier quoted context omitted.

Don't write programs in assembly. Use a high level language that translates down to assembly. Yknow, most every language ever. If you had read the article, you'd see that the author made this comparison.

Except Javascript isn't assembly, no matter how much the author would like to think so. It's a reasonably well featured, multi-paradigm high-level language.

Woosh...that is the sound of the point flying over your head.

Re: JavaScript is not suitable for large web apps

#202

Earlier quoted context omitted.

It's a pain, still. I don't generate js files. When something like that happens, I have to go back to command-line, type 'coffee ...coffee', open generated js file and see where the problem was.

That's your problem right there ;) When you're using CoffeeScript, you're absolutely supposed to generate all of your JS files. -- For the same reason why you don't run all of your JavaScript via eval() while you're developing. Try using `coffee --watch` instead.

OK then. I have already 7-8 tabs in my terminal open all the time (a few for servers, some for redis, some for mongod, some for vi, some for other tools, some for debugging, etc.), so I guess another tab wouldn't hurt (I'm not a fan of running processes in the background).

Re: JavaScript is not suitable for large web apps

#203

Earlier quoted context omitted.

>Great, so now the documentation for the function will promise to return a motorcycle, but instead return either a bunny or a toaster. Not if you follow the second part of my above advice. >There are lies, damn lies, and boilerplate code comments. Since when is a comment that explains what a function does "boilerplate"? I think you are confused.

I've often had to work with code where the comments indicated an entirely different intention than the implementation. As a result, I'm a little paranoid and skeptical, that's all. I also don't like the idea of having to comment each and every single function . If you have to write a comment to explain what it does, maybe you haven't named it properly?

Well, if you're having major problems keeping the project's code and comments in sync, no compiler will save you.

Re: JavaScript is not suitable for large web apps

#206
post #124
post #114

Earlier quoted context omitted.

No, thank Thor that mutant was aborted. ECMAScript 4 got everything wrong, just like AS3 did.

An optionally dynamic, yet also statically typed language? Umm... no. It's hard to even imagine arguing about this.

No. The problem with ES4 was that JavaScript is at heart not a traditional procedural OOP language. It's a functional language, and ES4 was trying to change that, a huge step in the wrong direction. They wanted more Java and less Script, but thankfully ES5 has gone the other direction, and given use more Script and less Java.

Re: JavaScript is not suitable for large web apps

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

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.

Re: JavaScript is not suitable for large web apps

#208

Earlier quoted context omitted.

I've often had to work with code where the comments indicated an entirely different intention than the implementation. As a result, I'm a little paranoid and skeptical, that's all. I also don't like the idea of having to comment each and every single function . If you have to write a comment to explain what it does, maybe you haven't named it properly?

Well, if you're having major problems keeping the project's code and comments in sync, no compiler will save you.

That's exactly how the compiler saves you. A strongly typed routine signature contract is a like comment that cannot get out of sync.

Re: JavaScript is not suitable for large web apps

#209
post #126

Earlier quoted context omitted.

> Also, you can't ignore that this is hosted by Adobe... This may be true, but it's an ad hominem attack.

It might be ad hominem out of context, but I don't feel it's improper to question the motives of someone working for a company that would most likely benefit from a decline in javascript in the app space. http://en.wikipedia.org/wiki/Ad_hominem#Questions_about_the_...

How would Adobe beneifit from a decline of javascript?

Re: JavaScript is not suitable for large web apps

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

His example was an exaggeration... It seemed obvious to me, but maybe not to everyone else.

A more real-life example is that it's very easy to accidentally return a number when you meant to return a string.

But yes, AS does support multiple interfaces.

Post reply on HN