Live data from Hacker News

JavaScript is not suitable for large web apps

blogs.adobe.com

71–80 of 218 posts

Re: JavaScript is not suitable for large web apps

#71

Earlier quoted context omitted.

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…

put a comment at the top of your function that says what to expect about the return value. Great, so now the documentation for the function will promise to return a motorcycle, but instead return either a bunny or a toaster. There are lies, damn lies, and boilerplate code comments.

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

Re: JavaScript is not suitable for large web apps

#74
post #4

This is utter tripe. It goes from saying don't use javascript to use a high level language that translates down to javascript. His main example of why javascript isn't suitable is an anecdote about a badly developed code base written in javascript. Seriously?

Hear hear. He does have a point about that well known low level language 'javaScript'. Must be similar to the high level one of the same name. Also he makes the valid point that bad developers make for a bad project, what a genius. judging by the comments on the actual blog he must be the second coming of Christ.

Re: JavaScript is not suitable for large web apps

#75
post #4

This is utter tripe. It goes from saying don't use javascript to use a high level language that translates down to javascript. His main example of why javascript isn't suitable is an anecdote about a badly developed code base written in javascript. Seriously?

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.

Re: JavaScript is not suitable for large web apps

#76
post #4

This is utter tripe. It goes from saying don't use javascript to use a high level language that translates down to javascript. His main example of why javascript isn't suitable is an anecdote about a badly developed code base written in javascript. Seriously?

There's no contradiction in saying don't use javascript, use something that compiles to javascript. It's exactly the same as saying don't use C, use something that translates to C (i.e. C++ once). As for his example being anecdotal, almost all code snippets posted in a blog post can be attacked for that, and while it might be valid, it is pretty much impossible for the writer to give _any_ negative example without it…

When combined with the assertion that "JS is the browser's assembly language", one can't quite say it's identical, because C isn't the OS's assembly language. Assembly language is.

Re: JavaScript is not suitable for large web apps

#77
post #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.

It actually does a lot to explain why I hate the AWS management console so much.

Re: JavaScript is not suitable for large web apps

#78

>Splitting up the code into multiple files enabled us to scale the project. I really don't get this at all. More files == more scalable? Someone more knowledgeable about ... whatever topic is relevant here care to explain this to me?

He means "scale the number of people working on the project at one time."

He's basically saying that if you have 10 files and 2 developers the chances of collision (or merging issues) is small, but having 20 developers working from 10 files makes things more sticky.

To some degree, he's not incorrect, in that over time, you'll spend more time managing the merging and conflict process than you will writing code.

Obviously, there are modern tools that will help alleviate this problem, but the deeper you go, the worse it is. This was the reason that "old" VCS had exclusive locks.

Re: JavaScript is not suitable for large web apps

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

>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

Re: JavaScript is not suitable for large web apps

#80
post #46

Earlier quoted context omitted.

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

"Full proof"?
Post reply on HN