4 ms·

I have been writing JavaScript professionally for nearly 20 years. I try my damndest to keep up, but the fact of the matter is the ecosystem is garbage. It’s re

by donatj 4y ago

I have been writing JavaScript professionally for nearly 20 years. I try my damndest to keep up, but the fact of the matter is the ecosystem is garbage. It’s really not a not-knowing-the-language thing. It’s a legacy of years and years of incompatible tooling requiring even more tooling to work around nightmare scenario. Node modules not working in the browser without translation was the original sin that kicked the whole nightmare off. Nothing ever works like a sane person would expect. When I do get a working typescript + webpack setup it’s almost entirely by accident. I stumbled upon something that works? Just avoid touching it at all costs. Recently I wanted to load an AMD module in Deno and just about gave my self an aneurism before giving up hours later. I have worked in dozens of languages over my career, and not encountered as much of a clusterf*ck as JavaScript anywhere else. I have never worked with anything before where so few people had any idea how it actually worked and just prayed that it continues.

fendy3002 4y ago
> Node modules not working in the browser without translation was the original sin that kicked the whole nightmare off Uh what? It's literally the name itself "node"_modules, it's designed to be used with node. The fact that it use same language and can later be used by browser is another matter. Thankfully we can easily bundle the whole thing using webpack nowadays. There are also countless boilerplate project with webpack setup already so you can get reference from there.
- marpstar 4y ago
  Not that I agree with the GP, but I think it’s easy to conflate “node”_modules with “modules from NPM”. Bower was once the recommended package manager for front-end assets, but NPM overtook it. I use Node daily, but 90% of my packages are front end.
  - fendy3002 4y ago
    Uh yeah, the fact that people using npm for frontend too means alternative front end package managers isn't as good (or as suitable) as npm. I take it as even though NPM isn't aimed for that, it works well.
- donatj 4y ago
  > It's literally the name itself "node"_modules, it's designed to be used with node. That’s the problem. It’s not JavaScript. It’s not any part of the ECMA standard, it doesn’t work in runtimes other than node (read: the browser) yet it lives in the .js files making them not truly JavaScript. You have split the language. The syntax isn’t part of the language and was designed in such a way that it cannot be polyfilled. This lead to a thousand packagers that would not be necessary at all if a sane syntax had been chosen. The creator of node himself has said making node incompatible with the browser was one of his biggest mistakes. https://medium.com/@imior/10-things-i-regret-about-node-js-ryan-dahl-2ba71ff6b4dc https://medium.com/@imior/10-things-i-regret-about-node-js-r... > There are also countless boilerplate project with webpack setup already so you can get reference from there. That’s literally the other problem! People just copying boilerplate without understanding it. That’s not a proper solution. That’s not a maintainable project, that’s copying other peoples homework and getting yourself in over your head.
  - fendy3002 4y ago
    If anything, it's not the fault of javascript, it's on node. However finding the popularity of it means that somewhat it's more suitable for many devs than the alternatives. Well I can understand it. As I've used the previous generation of jQuery, knockout, etc, nodejs and it's tooling makes things easier to scale, even with bigger overhead cost. EDIT: > That’s literally the other problem! People just copying boilerplate without understanding it. That’s not a proper solution. That’s not a maintainable project, that’s copying other peoples homework and getting yourself in over your head. Copy, make it run well, modify, learn is how I learn things. Without working example, it's magnitude times harder to learn something. The fact that people copy and use without trying to understand things is their fault, not the hundreds of boilerplate code.
franciscop 4y ago
Typescript IS a different language than Javascript (for good or for bad), meaning you are compounding the issues with Javascript ecosystem with the issues with Typescript compilation. Most of my code today is very straightforward, start a project, add type: module and 90% of the packages will work. If it doesn't, I either pick one of the 1M+ alternatives, try to decipher the issue (often is changing the import format or entrypoint), or avoid using a package for the problem I was trying to solve if trivial enough.
corrral 4y ago
This seems like a great place to ask how the ever-loving shit you get a front-end project with simple NPM-fetched libraries to bundle into either a single .js file ready to go in a <script> tag, or a block of <script> tags with all the referenced .js files in a directory and ready to serve. Ideally with typescript support, but surely (ha. ha. ha. ha.) I can just tack that on top and point whatever-this-is at typescript's output directory and my package.json, so that shouldn't be a problem (yeah, right...). I've written JS professionally for probably 12 or 13 out of the last 22 years, but I skipped the first couple iterations of frontend bundlers and tooling (kept rocking it old-school and just including plain .js files with script tags) until React, so I seem to have missed that intermediate phase, and now I cannot find it. I've lost probably 3 to 4 hours to trying to figure this out, last couple times I looked.
- SahAssar 4y ago
  For me esbuild has worked pretty well. Given a index.js as the entrypoint for your app: npx esbuild index.js --bundle --sourcemap --minify --outfile=out.js --format=esm esbuild is also pretty quick and does not have a lot of npm depencencies thanks to being a go binary. npx should download and run the binary for you and npx is almost always installed with node automatically.
  - corrral 4y ago
    Thank you. It was really hard to figure out which tools even could do this so I knew which one I ought to deeply "RTFM" for, which was really frustrating to me because it seemed like the most obvious default behavior for any JS build/bundle tool, which should be what it did if you just typed "some-build-tool build" or "bundle" or whatever, from your project root with nothing but a package.json containing a "main" entry.
    - SahAssar 4y ago
      I agree that this is really not a good experience. I prefer js projects that don't rely on build tools at all for this reason, but most devs, frameworks and libraries don't support such a use-case. When I have to use build-tools I usually go for esbuild.
jdminhbg 4y ago
> Node modules not working in the browser without translation was the original sin that kicked the whole nightmare off. Node modules are just a reaction to the actual original sin, which is building a popular language that essentially had no standard library. I suppose that's the kind of thing that will happen when you have to build one in a matter of weeks, but everything from webpack to left_pad is essentially the fault of the language not having a standard library.
- krapp 4y ago
  The language has a standard library fit for its intended purpose - scripting the DOM. Moving javascript out of the browser and trying to use it as a one-size-fits-all replacement for everything from systems to application programming, and every language from C++ to Java, is the original sin. Stop complaining because Brendan Eich's toy scripting language isn't a good replacement for things it was never meant to be used for. A screwdriver isn't a good hammer, either.
  - jdminhbg 4y ago
    Given how many front-end packages are on NPM, it's obviously not the case that the libraries provided were sufficient for scripting the DOM. Just take left_pad itself, that's something the language should provide, and it's an issue that it ended up being a point of failure. I have no particular love for using JS as a language to power everything from IoT devices to web servers, but it doesn't really matter how I feel about it. It's not going anywhere.
    - krapp 4y ago
      >Just take left_pad itself, that's something the language should provide, and it's an issue that it ended up being a point of failure. Why should the language provide that? What other languages provide an equivalent to that? left_pad is intended for formatting text within a terminal, not a website. There's no need for it within the context of a website, because HTML has tables, CSS and other elements for that.

by donatj 4y ago

fendy3002 4y ago

> Node modules not working in the browser without translation was the original sin that kicked the whole nightmare off Uh what? It's literally the name itself "node"_modules, it's designed to be used with node. The fact that it use same language and can later be used by browser is another matter. Thankfully we can easily bundle the whole thing using webpack nowadays. There are also countless boilerplate project with webpack setup already so you can get reference from there.

marpstar 4y ago
Not that I agree with the GP, but I think it’s easy to conflate “node”_modules with “modules from NPM”. Bower was once the recommended package manager for front-end assets, but NPM overtook it. I use Node daily, but 90% of my packages are front end.
- fendy3002 4y ago
  Uh yeah, the fact that people using npm for frontend too means alternative front end package managers isn't as good (or as suitable) as npm. I take it as even though NPM isn't aimed for that, it works well.
donatj 4y ago
> It's literally the name itself "node"_modules, it's designed to be used with node. That’s the problem. It’s not JavaScript. It’s not any part of the ECMA standard, it doesn’t work in runtimes other than node (read: the browser) yet it lives in the .js files making them not truly JavaScript. You have split the language. The syntax isn’t part of the language and was designed in such a way that it cannot be polyfilled. This lead to a thousand packagers that would not be necessary at all if a sane syntax had been chosen. The creator of node himself has said making node incompatible with the browser was one of his biggest mistakes. https://medium.com/@imior/10-things-i-regret-about-node-js-ryan-dahl-2ba71ff6b4dc https://medium.com/@imior/10-things-i-regret-about-node-js-r... > There are also countless boilerplate project with webpack setup already so you can get reference from there. That’s literally the other problem! People just copying boilerplate without understanding it. That’s not a proper solution. That’s not a maintainable project, that’s copying other peoples homework and getting yourself in over your head.
- fendy3002 4y ago
  If anything, it's not the fault of javascript, it's on node. However finding the popularity of it means that somewhat it's more suitable for many devs than the alternatives. Well I can understand it. As I've used the previous generation of jQuery, knockout, etc, nodejs and it's tooling makes things easier to scale, even with bigger overhead cost. EDIT: > That’s literally the other problem! People just copying boilerplate without understanding it. That’s not a proper solution. That’s not a maintainable project, that’s copying other peoples homework and getting yourself in over your head. Copy, make it run well, modify, learn is how I learn things. Without working example, it's magnitude times harder to learn something. The fact that people copy and use without trying to understand things is their fault, not the hundreds of boilerplate code.

franciscop 4y ago

Typescript IS a different language than Javascript (for good or for bad), meaning you are compounding the issues with Javascript ecosystem with the issues with Typescript compilation. Most of my code today is very straightforward, start a project, add type: module and 90% of the packages will work. If it doesn't, I either pick one of the 1M+ alternatives, try to decipher the issue (often is changing the import format or entrypoint), or avoid using a package for the problem I was trying to solve if trivial enough.

corrral 4y ago

This seems like a great place to ask how the ever-loving shit you get a front-end project with simple NPM-fetched libraries to bundle into either a single .js file ready to go in a <script> tag, or a block of <script> tags with all the referenced .js files in a directory and ready to serve. Ideally with typescript support, but surely (ha. ha. ha. ha.) I can just tack that on top and point whatever-this-is at typescript's output directory and my package.json, so that shouldn't be a problem (yeah, right...). I've written JS professionally for probably 12 or 13 out of the last 22 years, but I skipped the first couple iterations of frontend bundlers and tooling (kept rocking it old-school and just including plain .js files with script tags) until React, so I seem to have missed that intermediate phase, and now I cannot find it. I've lost probably 3 to 4 hours to trying to figure this out, last couple times I looked.

SahAssar 4y ago
For me esbuild has worked pretty well. Given a index.js as the entrypoint for your app: npx esbuild index.js --bundle --sourcemap --minify --outfile=out.js --format=esm esbuild is also pretty quick and does not have a lot of npm depencencies thanks to being a go binary. npx should download and run the binary for you and npx is almost always installed with node automatically.
- corrral 4y ago
  Thank you. It was really hard to figure out which tools even could do this so I knew which one I ought to deeply "RTFM" for, which was really frustrating to me because it seemed like the most obvious default behavior for any JS build/bundle tool, which should be what it did if you just typed "some-build-tool build" or "bundle" or whatever, from your project root with nothing but a package.json containing a "main" entry.
  - SahAssar 4y ago
    I agree that this is really not a good experience. I prefer js projects that don't rely on build tools at all for this reason, but most devs, frameworks and libraries don't support such a use-case. When I have to use build-tools I usually go for esbuild.

jdminhbg 4y ago

> Node modules not working in the browser without translation was the original sin that kicked the whole nightmare off. Node modules are just a reaction to the actual original sin, which is building a popular language that essentially had no standard library. I suppose that's the kind of thing that will happen when you have to build one in a matter of weeks, but everything from webpack to left_pad is essentially the fault of the language not having a standard library.

krapp 4y ago
The language has a standard library fit for its intended purpose - scripting the DOM. Moving javascript out of the browser and trying to use it as a one-size-fits-all replacement for everything from systems to application programming, and every language from C++ to Java, is the original sin. Stop complaining because Brendan Eich's toy scripting language isn't a good replacement for things it was never meant to be used for. A screwdriver isn't a good hammer, either.
- jdminhbg 4y ago
  Given how many front-end packages are on NPM, it's obviously not the case that the libraries provided were sufficient for scripting the DOM. Just take left_pad itself, that's something the language should provide, and it's an issue that it ended up being a point of failure. I have no particular love for using JS as a language to power everything from IoT devices to web servers, but it doesn't really matter how I feel about it. It's not going anywhere.
  - krapp 4y ago
    >Just take left_pad itself, that's something the language should provide, and it's an issue that it ended up being a point of failure. Why should the language provide that? What other languages provide an equivalent to that? left_pad is intended for formatting text within a terminal, not a website. There's no need for it within the context of a website, because HTML has tables, CSS and other elements for that.