5 ms·

> The primary reason for this is because the people writing JavaScript do not know what they are doing. Hello. I'm a JavaScript programmer who cut my teeth on

by _bxg1 6y ago

> The primary reason for this is because the people writing JavaScript do not know what they are doing. Hello. I'm a JavaScript programmer who cut my teeth on Java twelve years ago, followed by C++ two years later and throughout the course of my Computer Science program, and over the years I've done personal work in half a dozen other languages including Rust, Clojure, Python, C#, etc. Despite all of that TypeScript remains by go-to general-purpose language of choice, for any arbitrary project without particular constraints. Take your flame-bait elsewhere, please.

jagged-chisel 6y ago
I'm interested in your take wrt to the dependency hell GP mentions.
- brundolf 6y ago
  Personally, I: 1) Keep my direct dependency list slim and mostly limited to "too big to fail" projects backed by major companies 2) Avoid frameworks in favor of libraries I don't stress about indirect dependencies. If one of React's dependencies stops being maintained, or has a security problem or a bug, Facebook isn't going to not address it. Far too much money is riding on React as a whole, so whether they have to switch to a new dependency, or update the version, or reimplement the functionality themselves, they will. On top of this, the left-pad catastrophe can't happen again, because NPM publications are now impossible to remove after 72 hours: https://docs.npmjs.com/cli/unpublish https://docs.npmjs.com/cli/unpublish On the other hand I'm not going to add a direct dependency that I don't truly need. If it's a one-off function that I can write myself, or copy, I'll do so. On time I copied and pasted Lodash's debounce function into my codebase because that was all I needed, and I didn't want to bring in the whole library. Libraries, compared with frameworks, are easier to predict, to fill gaps in, and to replace if necessary. And even some things that we call ""frameworks"" like React can really be used as libraries. If you only use React as a rendering layer - what it's best at anyway - it actually has a very thin and elegant boundary with your code: you construct a data structure, and you hand it off. Others, like Angular and Aurelia, are truly frameworks and I tend to avoid them as a result. I wrote a blog post recently about the libraries/frameworks thing which got some attention/discussion here on HN: http://www.brandonsmith.ninja/blog/libraries-not-frameworks http://www.brandonsmith.ninja/blog/libraries-not-frameworks
  - speedgoose 6y ago
    There is a NPM package lodash.debounce if you only want this feature from lodash. Lodash is available splitted in many small packages.
    - _bxg1 6y ago
      The point remains, though, that I avoided an unnecessary dependency. I copied that function once and never needed to mess with it again, because it was 15 lines and I could verify personally that it did what it needed to do. For contrast, we wanted to be able to incorporate new versions of React, because it isn't a simple enough thing that it can be written once and be done. It evolved, and offered real improvements in terms of performance and useful features. As in all things, there are costs and benefits to making something an external dependency or not. The key is to realize that there are indeed tradeoffs, and that outsourcing every single thing you can isn't necessarily ideal.
    - entropicdrifter 6y ago
      Right, but his point about that was essentially: "Why depend on that as a dependency rather than just have a copy directly in my project that I know will never behave any differently?"
      - speedgoose 6y ago
        Because it's one line to a dependency with a name, a documentation, a bug tracker, many users, and that could be improved in the future. If you are scared about packages behaving differently, you should know that npm has lock files that describes your full dependency tree with versions and checksums.
        majormajor 6y ago
        "Could be improved in the future" is a risk when it comes to a simple utility function that does a simple thing that you don't want to change. In the same way that someone constantly tweaking your utility functions in your own project would be a risk - and you'd understandably want to code review all that - the more you choose to (or have to) outsource "trivial" stuff, the more brittle your project is.
HeWhoLurksLate 6y ago
It's always neat to read reasoned replies to comments like these. > > The primary reason for this is because the people writing JavaScript do not know what they are doing. I think GP has a point here, though- it feels (to _me_, someone with only a small amount of programming experience) that there are all too many beginner tutorials that jump straight into framework-of-the-week.js and that leave huge knowledge gaps- if people start with node.js and angular and and and and, they might not know that they can do xyz in a vanilla install of JS, thus making their core knowledge of the language dependent on a particular framework.
- _bxg1 6y ago
  I think there's some truth to this, but the same is true in, say, the Java world where you're almost not even writing things in Java-the-language, you're writing things in Spring. That said, it's probably more true in the JS world because it is so feasible to teach someone to make something in a JS framework before they know the fundamentals. Which is, honestly, an enormous compliment to the language, not an indictment! But it does come with some interesting side-effects. I do feel the need to make one small correction (the OP actually made the same mistake): Node.js is not a framework, it is a runtime. If you want to run JavaScript the way you run Python, you use Node (or, very recently, an alternative called Deno). You also don't have to do anything special with your code to run it in Node, like you would with a framework, unless you want to use its system APIs which of course do not exist in the browser. But even those are really more like libraries. But yes, your overall point is valid
  - Cthulhu_ 6y ago
    I personally (anecdotal) feel that the Java world is a lot more formal; there are some Strong Opinions held in what "good" Java code is, which is missing in Javascript. This is in part due to great books like Effective Java, and in part due to editor / IDE support that will warn you and help you write great code - keep in mind that good IDE support has been missing in Javascript for years because of its lack of support for e.g. modules or namespaces, and its lack of Opinions. Java's community has been Opinionated, whereas the JS community has been a lot more freeform. JQuery and NodeJS have been very influential in adding an opinion to the language; jquery by adding a kind of namespacing and scoping (also thanks to its predecessors / peers like YUI), NodeJS by adopting a module system (CommonJS) and centralized dependency management (NPM). I came into JS via Java and while the lack of standards and rules / expectations was liberating, I was also missing it. It took a while before the best practices of Java made it into Javascript; in my experience, AngularJS was a big push for that, in that it was a much more opinionated way to structure your components and application - with a strong emphasis on (unit) testability.
fulafel 6y ago
Another perspective: It's nice that there are many nicer languages that target JS, besides the fairly new TypeScript there's ClojureScript, ReasonML, Elm, CoffeeScript, Dart, Haxe etc etc.
mrlala 6y ago
But, but, but, if you don't write in C and manage your memory you are not a real programmer! Says slashdot/HN...
Mandatum 6y ago
I cut my teeth on VB6. Then PHP, .NET and finally Java. I look back at all the code I wrote.. And it's all bad. Except anything I wrote 2 weeks ago, that was my crowning achievement. In 2 months I'll hate it, but right now - it's perfect.

by _bxg1 6y ago

jagged-chisel 6y ago

I'm interested in your take wrt to the dependency hell GP mentions.

brundolf 6y ago
Personally, I: 1) Keep my direct dependency list slim and mostly limited to "too big to fail" projects backed by major companies 2) Avoid frameworks in favor of libraries I don't stress about indirect dependencies. If one of React's dependencies stops being maintained, or has a security problem or a bug, Facebook isn't going to not address it. Far too much money is riding on React as a whole, so whether they have to switch to a new dependency, or update the version, or reimplement the functionality themselves, they will. On top of this, the left-pad catastrophe can't happen again, because NPM publications are now impossible to remove after 72 hours: https://docs.npmjs.com/cli/unpublish https://docs.npmjs.com/cli/unpublish On the other hand I'm not going to add a direct dependency that I don't truly need. If it's a one-off function that I can write myself, or copy, I'll do so. On time I copied and pasted Lodash's debounce function into my codebase because that was all I needed, and I didn't want to bring in the whole library. Libraries, compared with frameworks, are easier to predict, to fill gaps in, and to replace if necessary. And even some things that we call ""frameworks"" like React can really be used as libraries. If you only use React as a rendering layer - what it's best at anyway - it actually has a very thin and elegant boundary with your code: you construct a data structure, and you hand it off. Others, like Angular and Aurelia, are truly frameworks and I tend to avoid them as a result. I wrote a blog post recently about the libraries/frameworks thing which got some attention/discussion here on HN: http://www.brandonsmith.ninja/blog/libraries-not-frameworks http://www.brandonsmith.ninja/blog/libraries-not-frameworks
- speedgoose 6y ago
  There is a NPM package lodash.debounce if you only want this feature from lodash. Lodash is available splitted in many small packages.
  - _bxg1 6y ago
    The point remains, though, that I avoided an unnecessary dependency. I copied that function once and never needed to mess with it again, because it was 15 lines and I could verify personally that it did what it needed to do. For contrast, we wanted to be able to incorporate new versions of React, because it isn't a simple enough thing that it can be written once and be done. It evolved, and offered real improvements in terms of performance and useful features. As in all things, there are costs and benefits to making something an external dependency or not. The key is to realize that there are indeed tradeoffs, and that outsourcing every single thing you can isn't necessarily ideal.
  - entropicdrifter 6y ago
    Right, but his point about that was essentially: "Why depend on that as a dependency rather than just have a copy directly in my project that I know will never behave any differently?"
    - speedgoose 6y ago
      Because it's one line to a dependency with a name, a documentation, a bug tracker, many users, and that could be improved in the future. If you are scared about packages behaving differently, you should know that npm has lock files that describes your full dependency tree with versions and checksums.
      - majormajor 6y ago
        "Could be improved in the future" is a risk when it comes to a simple utility function that does a simple thing that you don't want to change. In the same way that someone constantly tweaking your utility functions in your own project would be a risk - and you'd understandably want to code review all that - the more you choose to (or have to) outsource "trivial" stuff, the more brittle your project is.

HeWhoLurksLate 6y ago

It's always neat to read reasoned replies to comments like these. > > The primary reason for this is because the people writing JavaScript do not know what they are doing. I think GP has a point here, though- it feels (to _me_, someone with only a small amount of programming experience) that there are all too many beginner tutorials that jump straight into framework-of-the-week.js and that leave huge knowledge gaps- if people start with node.js and angular and and and and, they might not know that they can do xyz in a vanilla install of JS, thus making their core knowledge of the language dependent on a particular framework.

_bxg1 6y ago
I think there's some truth to this, but the same is true in, say, the Java world where you're almost not even writing things in Java-the-language, you're writing things in Spring. That said, it's probably more true in the JS world because it is so feasible to teach someone to make something in a JS framework before they know the fundamentals. Which is, honestly, an enormous compliment to the language, not an indictment! But it does come with some interesting side-effects. I do feel the need to make one small correction (the OP actually made the same mistake): Node.js is not a framework, it is a runtime. If you want to run JavaScript the way you run Python, you use Node (or, very recently, an alternative called Deno). You also don't have to do anything special with your code to run it in Node, like you would with a framework, unless you want to use its system APIs which of course do not exist in the browser. But even those are really more like libraries. But yes, your overall point is valid
- Cthulhu_ 6y ago
  I personally (anecdotal) feel that the Java world is a lot more formal; there are some Strong Opinions held in what "good" Java code is, which is missing in Javascript. This is in part due to great books like Effective Java, and in part due to editor / IDE support that will warn you and help you write great code - keep in mind that good IDE support has been missing in Javascript for years because of its lack of support for e.g. modules or namespaces, and its lack of Opinions. Java's community has been Opinionated, whereas the JS community has been a lot more freeform. JQuery and NodeJS have been very influential in adding an opinion to the language; jquery by adding a kind of namespacing and scoping (also thanks to its predecessors / peers like YUI), NodeJS by adopting a module system (CommonJS) and centralized dependency management (NPM). I came into JS via Java and while the lack of standards and rules / expectations was liberating, I was also missing it. It took a while before the best practices of Java made it into Javascript; in my experience, AngularJS was a big push for that, in that it was a much more opinionated way to structure your components and application - with a strong emphasis on (unit) testability.

fulafel 6y ago

Another perspective: It's nice that there are many nicer languages that target JS, besides the fairly new TypeScript there's ClojureScript, ReasonML, Elm, CoffeeScript, Dart, Haxe etc etc.

mrlala 6y ago

But, but, but, if you don't write in C and manage your memory you are not a real programmer! Says slashdot/HN...

Mandatum 6y ago

I cut my teeth on VB6. Then PHP, .NET and finally Java. I look back at all the code I wrote.. And it's all bad. Except anything I wrote 2 weeks ago, that was my crowning achievement. In 2 months I'll hate it, but right now - it's perfect.