4 ms·

The author encounters four problems trying to approach a programming task: 1) A problem common to every programming language (feature introduction/deprecation

The author encounters four problems trying to approach a programming task: 1) A problem common to every programming language (feature introduction/deprecation compatibility conflicts w.r.t. import/require) 2) A security issue around browser filesystem access (not-JS related at all: HTTP content-type sniffing) 3) A usability issue with the VSCode IDE (not JS related) 4) A bug in a single JS module Concludes this is all the fault of "modern Javascript", gives up. > What hope do actual novices have? Programming is a profession requiring learning from experience - if a novice doesn't have the patience to overcome very small speedbumps like this on a daily basis while learning a new domain, this might not be a good path for them. Don't get me wrong, there's A LOT about the modern JS ecosystem that could be improved from a UX perspective, but... it's not these things. I don't think any of the 4 bullets above are avoidable: (1) is a painful but necessary migration incompatibility is an unfortunate reality, the only alternative of which is to stagnate and never introduce/deprecate breaking features ever. (4) is human error - it happens. The others aren't JS-related at all.

deleted 4y ago
[deleted]
cxr 4y ago
> Programming is a profession requiring learning from experience - if a novice doesn't have the patience to overcome very small speedbumps like this on a daily basis while learning a new domain, this might not be a good path for them. There's a lot of assumption packed into this statement. Those speedbumps used to also not be there—they were put in recently[1]. Also, having read through your comment first and then read through the article (fully expecting to find what you describe), I'm compelled to say that your summaries grossly mischaracterize the substance of the complaints actually mentioned by the author. > a painful but necessary migration incompatibility is an unfortunate reality, the only alternative of which is to stagnate and never introduce/deprecate breaking features Well, no. The module fiasco is 100% a consequence of really, really bad decisions on the part of the NodeJS folks. They created the preconditions that led to the demand for their solution. This problem/solution cycle is rife in the NodeJS/NPM world. The only way to deal with it is to opt out[1][2]. 1. <https://www.colbyrussell.com/2019/03/06/how-to-displace-javascript.html https://www.colbyrussell.com/2019/03/06/how-to-displace-java...> 2. <https://news.ycombinator.com/item?id=24495646 https://news.ycombinator.com/item?id=24495646>
- lucideer 4y ago
  > Those speedbumps used to also not be there—they were put in recently > having read through your comment It doesn't sound like you've read my comment at all: 3 of the problems I listed are not new at all. The one that is - modules - is a result of two colliding independently standardised implementations from one language (commonjs vs ecma). > The module fiasco is 100% a consequence of really, really bad decisions on the part of the NodeJS folks. I'd genuinely like to hear an elaboration on this. You may be right but just stating doesn't make it so (your two referenced articles are just people who dislike JS railing against it for its own sake, nothing really constructive)
  - cxr 4y ago
    > It doesn't sound like you've read my comment at all Well, I did. > I'd genuinely like to hear an elaboration on this. You already alluded to it. NodeJS's take on modules (which are not CommonJS[1]) were never a good idea, and they were never standard, least of all in any sense that matters. Too many people treat the NodeJS project and its associated silliness like it's the be-all and end-all of "JS". It's not. It's a single, standards-incompatible runtime packed with proprietary features leading to obvious pain points (like the module fiasco) that are foreseeable from a mile away. Previously: <https://news.ycombinator.com/item?id=31331358 https://news.ycombinator.com/item?id=31331358> > your two referenced articles are just people who dislike JS railing against it for its own sake Wrong. I happen to like JS. It's why a spent a huge chunk of my time (before NodeJS was even a thing) making sure that there were high quality JS docs available on developer.mozilla.org, and it's why I wrote that post diagnosing the problems with the NodeJS culture that can (and should) be fixed to repair the JS onramp to be friction-free the way that it was before (and repair JS's image from the damage done by the NodeJS project, cf OP). But it doesn't sound like you've read them at all (nor does it sound like you're able to meaningfully separate JS from NodeJS yourself). 1. Isaac S: the best thing for me, and for node, and for npm, was just to go off the reservation and focus on the things that I knew mattered. Ryan basically always gave zero fucks about CommonJS anyway. One evening at Joyent, when I mentioned being a bit frustrated some ludicrous request for a feature that I knew to be a terrible idea, he said to me, "Forget CommonJS. It's dead. We are server side JavaScript."[...] we went pretty far off the reservation in v0.4, with the whole node_modules folder thing, and loading packages via their "main" field. Maybe we should remove those features, I'm sure that Node users would appreciate us being more spec-compliant!
mike_hearn 4y ago
The problems are all eminently avoidable, though. It's all death by a thousand cuts stuff. 1. Churn in something as basic as how modules work isn't common to every programming language, actually that's pretty specific to JavaScript. Java modules remained the same for 20 years, and when the 'new' module system came it's opt-in (you can pretty much ignore them and many people do because a 'new' module is forwards compatible and can be treated as an 'old' module as well). 2. They were only trying to use the browser because they had problems with Node and thought it'd be easier. The fact that there are security issues loading stuff written by the owner of the computer itself from disk is more an artifact of how browsers work and how they evolved than anything else. 3. The usability issue wasn't really with VS Code. It's that the default behavior of browsers on encountering stuff they don't understand is to ignore it and plough on regardless, so they got no error message and at that point were stuck. If they hadn't had Lee on hand their adventure would have ended here because Lee simply intuited what was wrong based on past experience. The fact that browsers routinely leave you looking at a broken page with either no error messages to help you, or a uselessly vague one, is a problem caused by (again) how browsers evolved, it isn't fundamental. More robust development environments don't have this issue. If something goes wrong you get an error, always, and it's usually helpful. You never just get nothing and are left wondering what happened. 4. The "bug" here is that you can't use TypeScript directly in a browser (why not? again, mostly complicated browser related tech politics that no beginner would understand), and the library in question doesn't advertise that it's using TypeScript properly. Even if the bug was fixed the user would still be stuck with TypeScript when what they need is JavaScript. "Programming is a profession requiring learning from experience - if a novice doesn't have the patience to overcome very small speedbumps like this on a daily basis while learning a new domain, this might not be a good path for them." The guy wasn't a novice. He's introduced as " a great computer scientist, but not a JS person". I think we're, as an industry, exceptionally blasé about usability problems in our tooling. These problems don't just waste the time of novices, they waste the time of people with 30 years experience, people who have been coding since childhood. The problems encountered in the article aren't the classic beginner problems like forgetting to add a semicolon at the end of a line. They're the result of accumulated lack of care for the overall developer experience. The root cause is a rampant culture of abusing tools for things they weren't ever actually designed for. JS modules are weird because JS was never intended to be a programming language for large scale projects, so it took decades for modules to emerge and then they were bolted on. Browsers refuse to do something as basic as load code from local disk because they were originally designed to render documents, TypeScript exists and requires extra work to execute because of the spec-driven approach browsers etc which in turn is due to their origin in rendering documents, etc etc. The blog post is specific to JavaScript because these problems are specific to JavaScript and the way we (ab)use web tech.
pkgland 4y ago
Regarding point 4: more people need to realise picking the right NPM package in the JS ecosystem is becoming a "must-have" skill, but the only way to find the right package is still to be constantly up-to-date with the ecosystem, endless google searches or hoping someone on Twitter can just tell you what's better. This is why I built https://pkg.land/ https://pkg.land/ (beta), append NPM package name to the url and a list of alternatives will be suggested. See https://pkg.land/colors https://pkg.land/colors
- lucideer 4y ago
  FWIW, I work in security and this skill is becoming very well automated in that domain. It's imperfect (and always will be), but there's a large overlap between manageable libraries and securable[0] libraries. [0] In the software-composition analysis field, "securability" is not only about upgrading vulnerable libraries but also about how many vulnerable transitive dependencies you may have to upgrade in future.
jeroenhd 4y ago
One thing in particular I hate about Javascript's platform is how much time you have to spend on learning the ever-changing tooling. I can write JS and TypeScript easily enough but when I start a new project I'm always fighting the tooling for at least half an hour before I can get going. The JS ecosystem has six ways to do anything and four of those aren't compatible with your previous choices. Tooling gets extended with endless helpers and plugins to the point where I don't even know what a given command does anymore. Python venvs and pip are easy enough to understand. Cargo and dotnet are also clear enough if you read their help pages. NPM and Yarn, however, only do a fraction of what you'd want them to do out of the box, forcing every tool out there to set up their custom system of helpers and tooling just to get them to run.
- lucideer 4y ago
  Hard agree on JS tooling. This is largely centred on browsers these days (ironically it used to be better for browsers and worse for server, now it's the opposite). However I'll say two things in javascript's defence: (1) No other language has yet taken on supporting server and browser environments simultaneously: it's unlikely to be easy for the first. (2) I have a strong suspicion it'll get much much easier one Node moves past it's CommonJS roots and gets to full community ES module support to match browsers > The JS ecosystem has six ways to do anything and four of those aren't compatible with your previous choices. Tooling gets extended with endless helpers and plugins to the point where I don't even know what a given command does anymore. No idea what you're talking about here though. Is this about NPM? What 6 different ways? What tooling extensions? This sounds like vague projection. > Python venvs and pip are easy enough to understand If only "understanding" was near enough. Good luck putting together a robust unattended install routine for anything python: does the user have existing venvs, should this script create a new one, where?, how should the user easily init it?, should it be a global init??, autoinit via bash or shortcut via bash alias? What about Elvish? What about fish? What about <Python is a horrible ecosystem, please don't get me started on its ills>...
  - jeroenhd 4y ago
    > (1) No other language has yet taken on supporting server and browser environments simultaneously, it's unlikely to be easy for the first. ASP.NET has allowed you to write purely backend code and add interactivity forever. Of course you can't get around JS in the front-end, but a mix of backend and frontend code existed long before Node got any popularity. > (2) I have a strong suspicion it'll get much much easier one Node moves past it's CommonJS roots and gets to full community ES module support to match browsers I agree. Then again, the Node ecosystem always seems to be moving from one standard to another.
deleted 4y ago
[deleted]

deleted 4y ago

[deleted]

cxr 4y ago

> Programming is a profession requiring learning from experience - if a novice doesn't have the patience to overcome very small speedbumps like this on a daily basis while learning a new domain, this might not be a good path for them. There's a lot of assumption packed into this statement. Those speedbumps used to also not be there—they were put in recently[1]. Also, having read through your comment first and then read through the article (fully expecting to find what you describe), I'm compelled to say that your summaries grossly mischaracterize the substance of the complaints actually mentioned by the author. > a painful but necessary migration incompatibility is an unfortunate reality, the only alternative of which is to stagnate and never introduce/deprecate breaking features Well, no. The module fiasco is 100% a consequence of really, really bad decisions on the part of the NodeJS folks. They created the preconditions that led to the demand for their solution. This problem/solution cycle is rife in the NodeJS/NPM world. The only way to deal with it is to opt out[1][2]. 1. <https://www.colbyrussell.com/2019/03/06/how-to-displace-javascript.html https://www.colbyrussell.com/2019/03/06/how-to-displace-java...> 2. <https://news.ycombinator.com/item?id=24495646 https://news.ycombinator.com/item?id=24495646>

lucideer 4y ago
> Those speedbumps used to also not be there—they were put in recently > having read through your comment It doesn't sound like you've read my comment at all: 3 of the problems I listed are not new at all. The one that is - modules - is a result of two colliding independently standardised implementations from one language (commonjs vs ecma). > The module fiasco is 100% a consequence of really, really bad decisions on the part of the NodeJS folks. I'd genuinely like to hear an elaboration on this. You may be right but just stating doesn't make it so (your two referenced articles are just people who dislike JS railing against it for its own sake, nothing really constructive)
- cxr 4y ago
  > It doesn't sound like you've read my comment at all Well, I did. > I'd genuinely like to hear an elaboration on this. You already alluded to it. NodeJS's take on modules (which are not CommonJS[1]) were never a good idea, and they were never standard, least of all in any sense that matters. Too many people treat the NodeJS project and its associated silliness like it's the be-all and end-all of "JS". It's not. It's a single, standards-incompatible runtime packed with proprietary features leading to obvious pain points (like the module fiasco) that are foreseeable from a mile away. Previously: <https://news.ycombinator.com/item?id=31331358 https://news.ycombinator.com/item?id=31331358> > your two referenced articles are just people who dislike JS railing against it for its own sake Wrong. I happen to like JS. It's why a spent a huge chunk of my time (before NodeJS was even a thing) making sure that there were high quality JS docs available on developer.mozilla.org, and it's why I wrote that post diagnosing the problems with the NodeJS culture that can (and should) be fixed to repair the JS onramp to be friction-free the way that it was before (and repair JS's image from the damage done by the NodeJS project, cf OP). But it doesn't sound like you've read them at all (nor does it sound like you're able to meaningfully separate JS from NodeJS yourself). 1. Isaac S: the best thing for me, and for node, and for npm, was just to go off the reservation and focus on the things that I knew mattered. Ryan basically always gave zero fucks about CommonJS anyway. One evening at Joyent, when I mentioned being a bit frustrated some ludicrous request for a feature that I knew to be a terrible idea, he said to me, "Forget CommonJS. It's dead. We are server side JavaScript."[...] we went pretty far off the reservation in v0.4, with the whole node_modules folder thing, and loading packages via their "main" field. Maybe we should remove those features, I'm sure that Node users would appreciate us being more spec-compliant!

mike_hearn 4y ago

The problems are all eminently avoidable, though. It's all death by a thousand cuts stuff. 1. Churn in something as basic as how modules work isn't common to every programming language, actually that's pretty specific to JavaScript. Java modules remained the same for 20 years, and when the 'new' module system came it's opt-in (you can pretty much ignore them and many people do because a 'new' module is forwards compatible and can be treated as an 'old' module as well). 2. They were only trying to use the browser because they had problems with Node and thought it'd be easier. The fact that there are security issues loading stuff written by the owner of the computer itself from disk is more an artifact of how browsers work and how they evolved than anything else. 3. The usability issue wasn't really with VS Code. It's that the default behavior of browsers on encountering stuff they don't understand is to ignore it and plough on regardless, so they got no error message and at that point were stuck. If they hadn't had Lee on hand their adventure would have ended here because Lee simply intuited what was wrong based on past experience. The fact that browsers routinely leave you looking at a broken page with either no error messages to help you, or a uselessly vague one, is a problem caused by (again) how browsers evolved, it isn't fundamental. More robust development environments don't have this issue. If something goes wrong you get an error, always, and it's usually helpful. You never just get nothing and are left wondering what happened. 4. The "bug" here is that you can't use TypeScript directly in a browser (why not? again, mostly complicated browser related tech politics that no beginner would understand), and the library in question doesn't advertise that it's using TypeScript properly. Even if the bug was fixed the user would still be stuck with TypeScript when what they need is JavaScript. "Programming is a profession requiring learning from experience - if a novice doesn't have the patience to overcome very small speedbumps like this on a daily basis while learning a new domain, this might not be a good path for them." The guy wasn't a novice. He's introduced as " a great computer scientist, but not a JS person". I think we're, as an industry, exceptionally blasé about usability problems in our tooling. These problems don't just waste the time of novices, they waste the time of people with 30 years experience, people who have been coding since childhood. The problems encountered in the article aren't the classic beginner problems like forgetting to add a semicolon at the end of a line. They're the result of accumulated lack of care for the overall developer experience. The root cause is a rampant culture of abusing tools for things they weren't ever actually designed for. JS modules are weird because JS was never intended to be a programming language for large scale projects, so it took decades for modules to emerge and then they were bolted on. Browsers refuse to do something as basic as load code from local disk because they were originally designed to render documents, TypeScript exists and requires extra work to execute because of the spec-driven approach browsers etc which in turn is due to their origin in rendering documents, etc etc. The blog post is specific to JavaScript because these problems are specific to JavaScript and the way we (ab)use web tech.

pkgland 4y ago

Regarding point 4: more people need to realise picking the right NPM package in the JS ecosystem is becoming a "must-have" skill, but the only way to find the right package is still to be constantly up-to-date with the ecosystem, endless google searches or hoping someone on Twitter can just tell you what's better. This is why I built https://pkg.land/ https://pkg.land/ (beta), append NPM package name to the url and a list of alternatives will be suggested. See https://pkg.land/colors https://pkg.land/colors

lucideer 4y ago
FWIW, I work in security and this skill is becoming very well automated in that domain. It's imperfect (and always will be), but there's a large overlap between manageable libraries and securable[0] libraries. [0] In the software-composition analysis field, "securability" is not only about upgrading vulnerable libraries but also about how many vulnerable transitive dependencies you may have to upgrade in future.

jeroenhd 4y ago

One thing in particular I hate about Javascript's platform is how much time you have to spend on learning the ever-changing tooling. I can write JS and TypeScript easily enough but when I start a new project I'm always fighting the tooling for at least half an hour before I can get going. The JS ecosystem has six ways to do anything and four of those aren't compatible with your previous choices. Tooling gets extended with endless helpers and plugins to the point where I don't even know what a given command does anymore. Python venvs and pip are easy enough to understand. Cargo and dotnet are also clear enough if you read their help pages. NPM and Yarn, however, only do a fraction of what you'd want them to do out of the box, forcing every tool out there to set up their custom system of helpers and tooling just to get them to run.

lucideer 4y ago
Hard agree on JS tooling. This is largely centred on browsers these days (ironically it used to be better for browsers and worse for server, now it's the opposite). However I'll say two things in javascript's defence: (1) No other language has yet taken on supporting server and browser environments simultaneously: it's unlikely to be easy for the first. (2) I have a strong suspicion it'll get much much easier one Node moves past it's CommonJS roots and gets to full community ES module support to match browsers > The JS ecosystem has six ways to do anything and four of those aren't compatible with your previous choices. Tooling gets extended with endless helpers and plugins to the point where I don't even know what a given command does anymore. No idea what you're talking about here though. Is this about NPM? What 6 different ways? What tooling extensions? This sounds like vague projection. > Python venvs and pip are easy enough to understand If only "understanding" was near enough. Good luck putting together a robust unattended install routine for anything python: does the user have existing venvs, should this script create a new one, where?, how should the user easily init it?, should it be a global init??, autoinit via bash or shortcut via bash alias? What about Elvish? What about fish? What about <Python is a horrible ecosystem, please don't get me started on its ills>...
- jeroenhd 4y ago
  > (1) No other language has yet taken on supporting server and browser environments simultaneously, it's unlikely to be easy for the first. ASP.NET has allowed you to write purely backend code and add interactivity forever. Of course you can't get around JS in the front-end, but a mix of backend and frontend code existed long before Node got any popularity. > (2) I have a strong suspicion it'll get much much easier one Node moves past it's CommonJS roots and gets to full community ES module support to match browsers I agree. Then again, the Node ecosystem always seems to be moving from one standard to another.

deleted 4y ago

[deleted]