5 ms·

> What is it missing that makes you hate it so? 1. Type Safety. TypeScript helps, but until strong typing is mandatory in the language, I can't fathom using JS

> What is it missing that makes you hate it so? 1. Type Safety. TypeScript helps, but until strong typing is mandatory in the language, I can't fathom using JS in any sizable project. This is also true of Python, et al. 2. A sane dependency management framework. Maven solved this problem a decade ago. Gradle is trying to fix Maven's XML mistake. But the fact is, if I need a dependency in Java, I know how to get it. And as a bonus, Maven Central isn't going to go down next Tuesday because Timmy in Alberta threw a temper tantrum or something. 3. A sense of stability. Javascript's framework churn is just exhausting.

snorremd 8y ago
2. After the npmjs.com registry became immutable and npm got lockfiles I feel npm is pretty much there as far as dependency management systems go. I'm not sure if npm shares the cache across projects (like the ~/.m2/repositories folder for maven/gradle/leiningen), but you can get that with the yarn client if saving disk space is important.
jhall1468 8y ago
> until strong typing is mandatory in the language, I can't fathom using JS in any sizable project. There are massive JS projects in production today, but that's moot. It's never going to be mandatory because that ruins the point. Typing isn't a requirement of a language. > A sane dependency management framework. Maven solved this problem a decade ago. A Rube Goldberg machine that solved a problem? Maven's goals may have solved the problem, but its implementation did not. > A sense of stability. Javascript's framework churn is just exhausting. Feature, not a bug.
jmull 8y ago
> ...until strong typing is mandatory in the language, I can't fathom using JS in any sizable project. There are quite a large number of counter-examples to show type safety isn't especially important to the success of large projects. I think the guarantees it provides are far too limited and weak to support large software systems. It relies on static code analysis, which doesn't mean much unless your app is a single build and runs as a single instance. That's more of a '90's style Microsoft Word type of app than what a typical large software project is today. Meanwhile the guarantees it does provide are only helpful to the extent developers can map their domain problems to the capabilities of the type system. Sometimes there is a nice natural fit, but usually the typesystem is both too weak (doesn't provide a convenient and natural way to impose the constraits of your problem domain) and too strong (imposes constraints your don't need or want, encumbering your development process). Not to mention that when it comes to Javascript, you can opt-in to about as much static code analysis, including type-safety, as you want.

snorremd 8y ago

2. After the npmjs.com registry became immutable and npm got lockfiles I feel npm is pretty much there as far as dependency management systems go. I'm not sure if npm shares the cache across projects (like the ~/.m2/repositories folder for maven/gradle/leiningen), but you can get that with the yarn client if saving disk space is important.

jhall1468 8y ago

> until strong typing is mandatory in the language, I can't fathom using JS in any sizable project. There are massive JS projects in production today, but that's moot. It's never going to be mandatory because that ruins the point. Typing isn't a requirement of a language. > A sane dependency management framework. Maven solved this problem a decade ago. A Rube Goldberg machine that solved a problem? Maven's goals may have solved the problem, but its implementation did not. > A sense of stability. Javascript's framework churn is just exhausting. Feature, not a bug.

jmull 8y ago

> ...until strong typing is mandatory in the language, I can't fathom using JS in any sizable project. There are quite a large number of counter-examples to show type safety isn't especially important to the success of large projects. I think the guarantees it provides are far too limited and weak to support large software systems. It relies on static code analysis, which doesn't mean much unless your app is a single build and runs as a single instance. That's more of a '90's style Microsoft Word type of app than what a typical large software project is today. Meanwhile the guarantees it does provide are only helpful to the extent developers can map their domain problems to the capabilities of the type system. Sometimes there is a nice natural fit, but usually the typesystem is both too weak (doesn't provide a convenient and natural way to impose the constraits of your problem domain) and too strong (imposes constraints your don't need or want, encumbering your development process). Not to mention that when it comes to Javascript, you can opt-in to about as much static code analysis, including type-safety, as you want.