4 ms·

especially when you try to do anything requiring more than 20 lines of code It's simpler than most OO languages. Not sure why you think it doesn't scale as we

especially when you try to do anything requiring more than 20 lines of code It's simpler than most OO languages. Not sure why you think it doesn't scale as well.

SideburnsOfDoom 14y ago
> Not sure why you think it doesn't scale as well. The reasons why JavaScript is thought not to scale well are very-well known. They include: Minor syntax issues: - Deeply indented callbacks, passing a function to a function to a function and the resulting complexity of flow control. - Issues with "this" become more likely with larger codebases. I know that JavaScript's "this" WTF is very old news, but it's the gift that keeps on giving. Major design issues: - JavaScript is not an OO language, it is a language that provides an OO construction kit. The OO patterns are layered on top of the language, the best idioms (e.g. self-invoking anonymous function, revealing prototype pattern) are not obvious and took a while to become common, and since none of them are mandatory, they can be ignored, mixed and matched or just gotten wrong. This is not a prescription for trouble-free scaling of the code. - Lack of a built-in packaging/module or linking system. Requirejs is filling this gap, but for a long time most JavaScript code just wasn't partitioned, it was put all in one file. It is unreasonably hard to build large systems this way.
- richcollins 14y ago
  I don't have any of these problems when I use js. I mostly use delegates and notifications instead of callbacks. I always use this to refer to the called object. The inheritance model is very simple and better than many other oo languages like Ruby. I agree that the method for cloning an object is a bit obtuse but it is easily corrected so you can just call clone on any object. The lack of forward is a small but significant problem but it doesn't significantly hamper design of complex software. It isn't ideal that you that you can't import modules but again it doesn't prevent you from building well designed complex software.

especially when you try to do anything requiring more than 20 lines of code It's simpler than most OO languages. Not sure why you think it doesn't scale as well.

SideburnsOfDoom 14y ago

> Not sure why you think it doesn't scale as well. The reasons why JavaScript is thought not to scale well are very-well known. They include: Minor syntax issues: - Deeply indented callbacks, passing a function to a function to a function and the resulting complexity of flow control. - Issues with "this" become more likely with larger codebases. I know that JavaScript's "this" WTF is very old news, but it's the gift that keeps on giving. Major design issues: - JavaScript is not an OO language, it is a language that provides an OO construction kit. The OO patterns are layered on top of the language, the best idioms (e.g. self-invoking anonymous function, revealing prototype pattern) are not obvious and took a while to become common, and since none of them are mandatory, they can be ignored, mixed and matched or just gotten wrong. This is not a prescription for trouble-free scaling of the code. - Lack of a built-in packaging/module or linking system. Requirejs is filling this gap, but for a long time most JavaScript code just wasn't partitioned, it was put all in one file. It is unreasonably hard to build large systems this way.

richcollins 14y ago
I don't have any of these problems when I use js. I mostly use delegates and notifications instead of callbacks. I always use this to refer to the called object. The inheritance model is very simple and better than many other oo languages like Ruby. I agree that the method for cloning an object is a bit obtuse but it is easily corrected so you can just call clone on any object. The lack of forward is a small but significant problem but it doesn't significantly hamper design of complex software. It isn't ideal that you that you can't import modules but again it doesn't prevent you from building well designed complex software.