6 ms·

JavaScript has grown up; it's got one of the best package managers anywhere, rapidly improving syntax and semantics, a large passionate community, loads of grea

JavaScript has grown up; it's got one of the best package managers anywhere, rapidly improving syntax and semantics, a large passionate community, loads of great tooling and a well maintained cross-platform binary in the shape of Node. It's no less deserving than any other language to be run on a server, as part of a build, generic scripts, whatever. Browser security issues arise because it's hard to resolve total user security across the public web coupled with highly interactive scriptable web pages ... its got nothing to do with the JavaScript language per se. It's fair enough to argue against the level of control scripts happen to have over the browser, but web page scripting could be implemented in <insert some other language here> and the same issues would be present. Your comment comes across as ignorant and prejudiced I'm afraid.

donatj 11y ago
NPM and the community that surrounds it is a nightmare. I guess you could be talking about Bower but either way they are far from good,let alone best.
- Wintamute 11y ago
  I was talking about npm. And I find the JS community welcoming, friendly and passionate and for the more serious npm modules out there highly technically literate, but hey it's a subjective thing I suppose :/
  - kuschku 11y ago
    So, the package manager that doesn’t do proper deduplication and, thanks to nested dependencies, runs over the file path length limit on multiple platforms?
    - Silhouette 11y ago
      FYI, the nesting and deduplication were fixed in NPM 3. It uses a flat structure now. Unfortunately, in their place the version resolution algorithm is now subject to order dependency: the same package.json file, run at the same time with the same packages available in the NPM repository, can give different results on different machines depending on what had already been installed.
      - paulddraper 11y ago
        Yep. Solved long file paths. All we had to give up was determinism!
    - its2complicated 11y ago
      Ha ha, the effing path length limit drove me crazy! There'd be 50 node_modules folders and Windows wouldn't let you delete anything; It was nuts! I had to start renaming directories to "a", "b", "c", and so on until I cut the size down. I like JS for quick personal projects, but I'm glad I don't use it professionally anymore.
- Matachines 11y ago
  Agreed. The JS community has some great people but in general it's very immature.
- Matachines 11y ago
  Agreed. The JS community has some great people but in general it's very immature.
- overcast 11y ago
  Can you give me examples of this? Everything I've used regarding NPM has been awesome. Stupid easy to use and integrate.
  - Silhouette 11y ago
    OK, here's an everyday example. Suppose you and I are working on a front-end project, all neatly set up with package.json and so on in place. We've been working on different new features, adding in a new package or two from NPM in the process. We both fetch each other's latest changes to in-house code from source control. What NPM command do we run to make sure we also have the same packages installed and are actually running the same code?
    - overcast 11y ago
      package.json version control and npm update? npm install --save will install the package you want, and add it to package.json Why wouldn't your repo merge package.json between your changes? I'm doing the same thing when I merge changes to production. I add packages as I work on things at the desktop, and sync changes to production server.
      - Silhouette 11y ago
        Unfortunately, the regular package.json and related npm commands are built around semver, and typically also only specify direct dependencies. Either of those alone is enough to violate the simple condition I gave many times over on a real project, because it means you can't in practice guarantee that two developers are even running the same code. It's actually worse with the latest NPM changes that flattened the tree in node_modules, because now there are order dependencies affecting which versions of things you get as well. The closest NPM has to an answer for this is shrinkwrap, but that adds a lot of complexity of its own, and still has limitations. In fact, there's a note at the bottom of the npm shrinkwrap documentation page suggesting that if you really want to control your dependencies robustly, you need to check everything into source control -- which is obviously the sensible thing to do, except that because npm does magic in node_modules that can involve all kinds of funky build steps, you're not checking in just the source for the modules you depend on, but might have all kinds of other artifacts that may or may not be portable as well. In short, it is all but impossible in practice to use Node and NPM to satisfy the most basic of development requirements: getting all of your developers (or production systems, for that matter) to actually run exactly the same code. If that's not a catastrophic failure to meet the requirements for a package management system, I don't know what is.
falcolas 11y ago
Javascript has grown up. It's past its infancy, and at a point where it starts to be really good at what it was designed to be good at. However, like any adolescent, since it's good at one thing, it thinks it is the best at everything. I'm anthropomorphizing Javascript somewhat here, attributing the feelings of its community to the language itself. But from the point of view of someone whose first programming language was not Javascript, the trend is pretty apparent: We can run Javascript anywhere, so we will run it everywhere.
- Wintamute 11y ago
  > However, like any adolescent, since it's good at one thing, it thinks it is the best at everything. The only thing that's happening here is that a community has formed around an evolving language and is taking advantage of some great tooling and open source projects to do some interesting stuff. That community isn't formed exclusively of wet-behind-the-ears web developers. It's comprised of developers of all skills levels with experience in a multitude of platforms and languages, just like any other. These people chose JS because it works for them and their problem set. To suggest otherwise is condescending to say the least. Stop trying to paint the whole community with a single brush, you sound ridiculous. If JS isn't your bag fine, move on, but less of the JS shaming please.
- EvanPlaice 11y ago
  Atwood's law. They're building operating systems with it now. See, NodeOS and Runtime.js. The "Birth and death of Javascript" talk is beginning to look less like satire, and more like moderately accurate prediction.
smt88 11y ago
> ignorant and prejudiced I'm afraid Relax. You're talking about someone's opinion of a programming language. That said, all of your comments come across as ignorant to me. I don't think you're ignorant, though. I think you know JavaScript really well and like it. I personally found it unusable on the server until TypeScript became mature enough to use. Have you tried TypeScript or some other static-typed, better-defined language (Flow, Clojure, etc.)? You may love JavaScript, but there's a good reason Facebook, Google, and Microsoft all find it to be unusable and have created compile-to-JavaScript languages so that their companies can be JavaScript-free someday.
- todd3834 11y ago
  I doubt the goal is to be JavaScript free. The compilers typically enhance the language or give you access to functionality that is destined to land in the future JavaScript. ES6+ shows a lot of promise and thanks to Babel we can use those features now.
  - smt88 11y ago
    Let me clarify what I mean by "JavaScript-free": they don't want any of their employees writing JavaScript by hand anymore, whether it be ES6, ES2015, or ES2020. TypeScript and Flow are supersets, but Clojure (and many other compile-to-JavaScript languages) are completely different.
    - Wintamute 11y ago
      Your insider knowledge of the technical policies of Facebook, Google, MS, etc is truly impressive. And ES2020 too? Somebody write this down quick!
      - smt88 11y ago
        I understand what it's like to be emotionally invested in a particular language or technology. It's usually a result of not having used something better[1] or just having invested a lot of time into that technology. The good news is that a lot of programming skills are fungible, and you (like me) will eventually use things you like more than you expected -- perhaps even more than you like JavaScript. The time you invested won't be wasted. 1. http://www.paulgraham.com/avg.html http://www.paulgraham.com/avg.html
Silhouette 11y ago
JavaScript has grown up; it's got one of the best package managers anywhere, rapidly improving syntax and semantics, a large passionate community, loads of great tooling and a well maintained cross-platform binary in the shape of Node. I'll give you the passionate community point. I almost completely disagree with everything else. JavaScript is a very immature platform. JavaScript has probably the worst packaging ecosystem of any major programming language. The fine-grained packages, indirect dependencies, and frequently broken versioning cause endless problems in real world systems. Recent attempts to fix the package manager have unfortunately swapped one set of problems for another, while still leaving some of those fundamental weaknesses involving transitive dependencies and excessive trust of version numbering conventions unaddressed. It does has rapidly evolving syntax and semantics, but at the expense of stability, portability and future-proofing. The only reason 99% of JS programmers use most of the new syntax and semantics is a combination of a transpilation tool written primarily by one (remarkable) person and a polyfill written primarily by one other (remarkable) person in their free time. Browser, tool and Node support for many of those new features is patchy, which is why that transpilation and polyfilling is necessary. Tooling for JS is at least two decades behind the industry best-in-class. It's a dynamic language that now has such a huge mess of build tools associated with it that seasoned veterans of web development weep at the prospect. You can't reliably debug real world JS code in its natural form, even on the level of setting break points and examining local variables and call stacks, without jumping through all kinds of hoops, and in some browsers even then. Profiling also relies almost entirely on browser magic. There are lots of testing tools, but setting them up is often a chore and they have widely varying degrees of power and flexibility. We've only recently got a style checking tool that can actually cope with ES2015 reasonably well. Refactoring, auto-completion, documentation, navigation in your editor? What are those? As for Node... I've seen experienced developers spend months trying to get basic stuff working in a cross-platform way with Node, and then seen other experienced developers do more in a week or even a day using C. Using Node is saying "I know, let's throw out a few decades of experience building reliable client-server systems and all the other tried and tested languages and tools and libraries we've developed over that time, and instead transfer all of those negative aspects of JS to the server side as well, even though unlike front-end developers we don't have to".

JavaScript has grown up; it's got one of the best package managers anywhere, rapidly improving syntax and semantics, a large passionate community, loads of great tooling and a well maintained cross-platform binary in the shape of Node. It's no less deserving than any other language to be run on a server, as part of a build, generic scripts, whatever. Browser security issues arise because it's hard to resolve total user security across the public web coupled with highly interactive scriptable web pages ... its got nothing to do with the JavaScript language per se. It's fair enough to argue against the level of control scripts happen to have over the browser, but web page scripting could be implemented in <insert some other language here> and the same issues would be present. Your comment comes across as ignorant and prejudiced I'm afraid.

donatj 11y ago

NPM and the community that surrounds it is a nightmare. I guess you could be talking about Bower but either way they are far from good,let alone best.

Wintamute 11y ago
I was talking about npm. And I find the JS community welcoming, friendly and passionate and for the more serious npm modules out there highly technically literate, but hey it's a subjective thing I suppose :/
- kuschku 11y ago
  So, the package manager that doesn’t do proper deduplication and, thanks to nested dependencies, runs over the file path length limit on multiple platforms?
  - Silhouette 11y ago
    FYI, the nesting and deduplication were fixed in NPM 3. It uses a flat structure now. Unfortunately, in their place the version resolution algorithm is now subject to order dependency: the same package.json file, run at the same time with the same packages available in the NPM repository, can give different results on different machines depending on what had already been installed.
    - paulddraper 11y ago
      Yep. Solved long file paths. All we had to give up was determinism!
  - its2complicated 11y ago
    Ha ha, the effing path length limit drove me crazy! There'd be 50 node_modules folders and Windows wouldn't let you delete anything; It was nuts! I had to start renaming directories to "a", "b", "c", and so on until I cut the size down. I like JS for quick personal projects, but I'm glad I don't use it professionally anymore.
Matachines 11y ago
Agreed. The JS community has some great people but in general it's very immature.
Matachines 11y ago
Agreed. The JS community has some great people but in general it's very immature.
overcast 11y ago
Can you give me examples of this? Everything I've used regarding NPM has been awesome. Stupid easy to use and integrate.
- Silhouette 11y ago
  OK, here's an everyday example. Suppose you and I are working on a front-end project, all neatly set up with package.json and so on in place. We've been working on different new features, adding in a new package or two from NPM in the process. We both fetch each other's latest changes to in-house code from source control. What NPM command do we run to make sure we also have the same packages installed and are actually running the same code?
  - overcast 11y ago
    package.json version control and npm update? npm install --save will install the package you want, and add it to package.json Why wouldn't your repo merge package.json between your changes? I'm doing the same thing when I merge changes to production. I add packages as I work on things at the desktop, and sync changes to production server.
    - Silhouette 11y ago
      Unfortunately, the regular package.json and related npm commands are built around semver, and typically also only specify direct dependencies. Either of those alone is enough to violate the simple condition I gave many times over on a real project, because it means you can't in practice guarantee that two developers are even running the same code. It's actually worse with the latest NPM changes that flattened the tree in node_modules, because now there are order dependencies affecting which versions of things you get as well. The closest NPM has to an answer for this is shrinkwrap, but that adds a lot of complexity of its own, and still has limitations. In fact, there's a note at the bottom of the npm shrinkwrap documentation page suggesting that if you really want to control your dependencies robustly, you need to check everything into source control -- which is obviously the sensible thing to do, except that because npm does magic in node_modules that can involve all kinds of funky build steps, you're not checking in just the source for the modules you depend on, but might have all kinds of other artifacts that may or may not be portable as well. In short, it is all but impossible in practice to use Node and NPM to satisfy the most basic of development requirements: getting all of your developers (or production systems, for that matter) to actually run exactly the same code. If that's not a catastrophic failure to meet the requirements for a package management system, I don't know what is.

falcolas 11y ago

Javascript has grown up. It's past its infancy, and at a point where it starts to be really good at what it was designed to be good at. However, like any adolescent, since it's good at one thing, it thinks it is the best at everything. I'm anthropomorphizing Javascript somewhat here, attributing the feelings of its community to the language itself. But from the point of view of someone whose first programming language was not Javascript, the trend is pretty apparent: We can run Javascript anywhere, so we will run it everywhere.

Wintamute 11y ago
> However, like any adolescent, since it's good at one thing, it thinks it is the best at everything. The only thing that's happening here is that a community has formed around an evolving language and is taking advantage of some great tooling and open source projects to do some interesting stuff. That community isn't formed exclusively of wet-behind-the-ears web developers. It's comprised of developers of all skills levels with experience in a multitude of platforms and languages, just like any other. These people chose JS because it works for them and their problem set. To suggest otherwise is condescending to say the least. Stop trying to paint the whole community with a single brush, you sound ridiculous. If JS isn't your bag fine, move on, but less of the JS shaming please.
EvanPlaice 11y ago
Atwood's law. They're building operating systems with it now. See, NodeOS and Runtime.js. The "Birth and death of Javascript" talk is beginning to look less like satire, and more like moderately accurate prediction.

smt88 11y ago

> ignorant and prejudiced I'm afraid Relax. You're talking about someone's opinion of a programming language. That said, all of your comments come across as ignorant to me. I don't think you're ignorant, though. I think you know JavaScript really well and like it. I personally found it unusable on the server until TypeScript became mature enough to use. Have you tried TypeScript or some other static-typed, better-defined language (Flow, Clojure, etc.)? You may love JavaScript, but there's a good reason Facebook, Google, and Microsoft all find it to be unusable and have created compile-to-JavaScript languages so that their companies can be JavaScript-free someday.

todd3834 11y ago
I doubt the goal is to be JavaScript free. The compilers typically enhance the language or give you access to functionality that is destined to land in the future JavaScript. ES6+ shows a lot of promise and thanks to Babel we can use those features now.
- smt88 11y ago
  Let me clarify what I mean by "JavaScript-free": they don't want any of their employees writing JavaScript by hand anymore, whether it be ES6, ES2015, or ES2020. TypeScript and Flow are supersets, but Clojure (and many other compile-to-JavaScript languages) are completely different.
  - Wintamute 11y ago
    Your insider knowledge of the technical policies of Facebook, Google, MS, etc is truly impressive. And ES2020 too? Somebody write this down quick!
    - smt88 11y ago
      I understand what it's like to be emotionally invested in a particular language or technology. It's usually a result of not having used something better[1] or just having invested a lot of time into that technology. The good news is that a lot of programming skills are fungible, and you (like me) will eventually use things you like more than you expected -- perhaps even more than you like JavaScript. The time you invested won't be wasted. 1. http://www.paulgraham.com/avg.html http://www.paulgraham.com/avg.html

Silhouette 11y ago

JavaScript has grown up; it's got one of the best package managers anywhere, rapidly improving syntax and semantics, a large passionate community, loads of great tooling and a well maintained cross-platform binary in the shape of Node. I'll give you the passionate community point. I almost completely disagree with everything else. JavaScript is a very immature platform. JavaScript has probably the worst packaging ecosystem of any major programming language. The fine-grained packages, indirect dependencies, and frequently broken versioning cause endless problems in real world systems. Recent attempts to fix the package manager have unfortunately swapped one set of problems for another, while still leaving some of those fundamental weaknesses involving transitive dependencies and excessive trust of version numbering conventions unaddressed. It does has rapidly evolving syntax and semantics, but at the expense of stability, portability and future-proofing. The only reason 99% of JS programmers use most of the new syntax and semantics is a combination of a transpilation tool written primarily by one (remarkable) person and a polyfill written primarily by one other (remarkable) person in their free time. Browser, tool and Node support for many of those new features is patchy, which is why that transpilation and polyfilling is necessary. Tooling for JS is at least two decades behind the industry best-in-class. It's a dynamic language that now has such a huge mess of build tools associated with it that seasoned veterans of web development weep at the prospect. You can't reliably debug real world JS code in its natural form, even on the level of setting break points and examining local variables and call stacks, without jumping through all kinds of hoops, and in some browsers even then. Profiling also relies almost entirely on browser magic. There are lots of testing tools, but setting them up is often a chore and they have widely varying degrees of power and flexibility. We've only recently got a style checking tool that can actually cope with ES2015 reasonably well. Refactoring, auto-completion, documentation, navigation in your editor? What are those? As for Node... I've seen experienced developers spend months trying to get basic stuff working in a cross-platform way with Node, and then seen other experienced developers do more in a week or even a day using C. Using Node is saying "I know, let's throw out a few decades of experience building reliable client-server systems and all the other tried and tested languages and tools and libraries we've developed over that time, and instead transfer all of those negative aspects of JS to the server side as well, even though unlike front-end developers we don't have to".