6 ms·

Apparently the author has it out for import statements. "No import dumpster at the top of each file. Forget imports even existed. Just access whatever you want

Apparently the author has it out for import statements. "No import dumpster at the top of each file. Forget imports even existed. Just access whatever you want, wherever you want. TypeScript knows where to find it." This is a bizarre preference. Is there some reason the JS community has turned against explicitly listing what libraries are used by a module?

jakelazaroff 3y ago
I definitely would not say the authors’ opinions are representative of the JS community.
- whstl 3y ago
  This is the third or fourth time I see today in HN of someone treating someone's personal project or opinion as "the direction the community is moving". If every new toy framework is treated like this, it's no wonder people feel overwhelmed by frontend development.
  - seattle_spring 3y ago
    This seems to happen on subjects much broader than FE community direction. Fringe twitter posts on politics are very frequently interpreted as "what the entire <x> community believes."
  - Py_ 3y ago
    RawJS library author here. Moving away from modules is definitely not what I've observed in the community, I see no evidence that this is "the direction the community is moving". That said, I admittedly have a visceral hatred for ES modules. I personally believe them to be the worst thing that has ever happened to the language. Encapsulation is of course a great thing but in my opinion there are much better ways to do this. I'm not the only person that thinks this–there was a gist that got to the homepage of HN a while back titled something like "ES Modules are terribly, actually" (IIRC).
    - ble 3y ago
      I'm going to read that gist ( https://gist.github.com/joepie91/bca2fda868c1e8b2c2caf76af7dfcad3 https://gist.github.com/joepie91/bca2fda868c1e8b2c2caf76af7d... ), but what do you dislike or hate about ES modules? From my own experience, they are extremely frustrating when tooling doesn't work well or at all with them. Given that I don't do JavaScript or front-end for work, I mostly run into these things in hobby programming. Given that this is programming for fun, I can voluntarily cut myself off from all the libraries that use other module systems. In this happy little bubble, over time, ES module support has gotten better and I've selected tools / found ways to use tools that work with modules and I rather like it. Perhaps because I'm less invested in the tools, I evaluate the situation of "tool X doesn't support ES modules" more like "tool X isn't great" and less like "ES modules are bad". Perhaps it all stems from being a person who genuinely likes JavaScript, has a high affinity for standards, and a relatively low opinion (yes, I'm a snob) of the Node ecosystem?
      - Py_ 3y ago
        You can already do encapsulation without them by using TypeScript namespaces. It's sad that namespaces didn't become part of JavaScript. I really dislike having to include every last identifier that exists in other files. Yes I know that IDEs will sometimes do this for you I guess the main thing is that they result in your needing a bunch of additional infrastructure (webpack, rollup, bun.js, HMR solutions, etc) just to get your app to run, when TypeScript can already do all this.
        throwitaway1123 3y ago
        > I really dislike having to include every last identifier that exists in other files. How do you feel about esm's namespace import feature [1]? For example: import * as React from 'react' > I guess the main thing is that they result in your needing a bunch of additional infrastructure (webpack, rollup, bun.js, HMR solutions, etc) just to get your app to run, when TypeScript can already do all this. You can obviously use es modules directly in the browser without additional infrastructure. Bundlers simply combine (bundle) all your dependencies into a single file to prevent multiple http requests (although this is less relevant today with HTTP2). HMR solves a completely different problem — replacing individual modules in the browser during development when they change instead of reloading the entire page. HMR isn't something that es modules necessitate. You're free to reload your entire page every time you make a change in development. [1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import#namespace_import https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
  - dncornholio 3y ago
    It's an awful trend really. When authors do this sometimes I even feel personally attacked and have to hold myself to be nice in the comment section. That usually means I don't even comment at all.
    - whstl 3y ago
      Same. I was quite happy that jakelazaroff was able to phrase it in a better way than I would.
theogravity 3y ago
the namespacing is also odd as well. I don't usually see it used that way in Typescript.

jakelazaroff 3y ago

I definitely would not say the authors’ opinions are representative of the JS community.

whstl 3y ago
This is the third or fourth time I see today in HN of someone treating someone's personal project or opinion as "the direction the community is moving". If every new toy framework is treated like this, it's no wonder people feel overwhelmed by frontend development.
- seattle_spring 3y ago
  This seems to happen on subjects much broader than FE community direction. Fringe twitter posts on politics are very frequently interpreted as "what the entire <x> community believes."
- Py_ 3y ago
  RawJS library author here. Moving away from modules is definitely not what I've observed in the community, I see no evidence that this is "the direction the community is moving". That said, I admittedly have a visceral hatred for ES modules. I personally believe them to be the worst thing that has ever happened to the language. Encapsulation is of course a great thing but in my opinion there are much better ways to do this. I'm not the only person that thinks this–there was a gist that got to the homepage of HN a while back titled something like "ES Modules are terribly, actually" (IIRC).
  - ble 3y ago
    I'm going to read that gist ( https://gist.github.com/joepie91/bca2fda868c1e8b2c2caf76af7dfcad3 https://gist.github.com/joepie91/bca2fda868c1e8b2c2caf76af7d... ), but what do you dislike or hate about ES modules? From my own experience, they are extremely frustrating when tooling doesn't work well or at all with them. Given that I don't do JavaScript or front-end for work, I mostly run into these things in hobby programming. Given that this is programming for fun, I can voluntarily cut myself off from all the libraries that use other module systems. In this happy little bubble, over time, ES module support has gotten better and I've selected tools / found ways to use tools that work with modules and I rather like it. Perhaps because I'm less invested in the tools, I evaluate the situation of "tool X doesn't support ES modules" more like "tool X isn't great" and less like "ES modules are bad". Perhaps it all stems from being a person who genuinely likes JavaScript, has a high affinity for standards, and a relatively low opinion (yes, I'm a snob) of the Node ecosystem?
    - Py_ 3y ago
      You can already do encapsulation without them by using TypeScript namespaces. It's sad that namespaces didn't become part of JavaScript. I really dislike having to include every last identifier that exists in other files. Yes I know that IDEs will sometimes do this for you I guess the main thing is that they result in your needing a bunch of additional infrastructure (webpack, rollup, bun.js, HMR solutions, etc) just to get your app to run, when TypeScript can already do all this.
      - throwitaway1123 3y ago
        > I really dislike having to include every last identifier that exists in other files. How do you feel about esm's namespace import feature [1]? For example: import * as React from 'react' > I guess the main thing is that they result in your needing a bunch of additional infrastructure (webpack, rollup, bun.js, HMR solutions, etc) just to get your app to run, when TypeScript can already do all this. You can obviously use es modules directly in the browser without additional infrastructure. Bundlers simply combine (bundle) all your dependencies into a single file to prevent multiple http requests (although this is less relevant today with HTTP2). HMR solves a completely different problem — replacing individual modules in the browser during development when they change instead of reloading the entire page. HMR isn't something that es modules necessitate. You're free to reload your entire page every time you make a change in development. [1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import#namespace_import https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
- dncornholio 3y ago
  It's an awful trend really. When authors do this sometimes I even feel personally attacked and have to hold myself to be nice in the comment section. That usually means I don't even comment at all.
  - whstl 3y ago
    Same. I was quite happy that jakelazaroff was able to phrase it in a better way than I would.

theogravity 3y ago

the namespacing is also odd as well. I don't usually see it used that way in Typescript.