6 ms·

> just run it in the browser Yikes. I really do not think that was the solution to this problem and only added a ton of complexity. JS is in a unique positio

by qudat 6y ago

> just run it in the browser Yikes. I really do not think that was the solution to this problem and only added a ton of complexity. JS is in a unique position because it can run both code in a browser as well as a server-side/scripting language. In order to do that with any level of success, tooling is required. This tooling (dev server, webpack) builds on other tooling (node, babel, typescript) which is where all this complexity lives. Furthermore, some packages are not worth installing and if you run into issues with that package, then try something else. We have no information about the package they tried to install and since the JS ecosystem encourages people to publish to npm for virtually anything, this is one area where you really have to be careful. The lesson here is the same lesson with installing something like left-pad: be careful what you install and read the source code to understand what it is doing. Most of the time, these packages can be inlined easily. Just because a library exists, doesn't mean you should use it. Most of the time for JS I'm reading the library's source code to see if I can a) inline it or b) use it as inspiration to build specifically what I need.

masswerk 6y ago
> JS is in a unique position because it can run both code in a browser as well as a server-side/scripting language. In order to do that with any level of success, tooling is required. Mind that this was not that much of a problem back in 1997 with Netscape Navigator and Netscape Enterprise Server. I think, the real issue here is that the JS ecosystem is targeting an abstract implementation, rather than a real world one. Much of the tooling is just about turning the abstract implementation into a real world standard and, in a second step, about packaging (i.e. linking).
- bobthepanda 6y ago
  > Much of the tooling is just about turning the abstract implementation into a real world standard and, in a second step, about packaging (i.e. linking). So long as you have browsers in various states of compliance and paying customers using those browsers, this will always be a problem.
mikeryan 6y ago
Is it me or is the real problem that someone wrote a package and quickly wrote use “import ...“ instead of writing “const x = require(“...“ Node works fine out of the box from the command line, modules just need to have the correct instructions for the README.
- yawaramin 6y ago
  That wouldn't have helped anyway. The file was written in TypeScript. Node would have barfed immediately.
  - _-o-_ 6y ago
    Libraries with TS codebase almost always have a prebuilt bundle.
cookiengineer 6y ago
> be careful what you install and read the source code to understand what it is doing. That’s the reason why I started to love pika.dev ‘s package search. Webpack still sucks and will ruin your day with hours of unnecessary configurations and fixes. On the other hand, when setting yourself a rule to use plain ESM only without any build system, coding has been a joy. The only thing that still sucks is UI frameworks, because all major frameworks still require a shitty babel workflow in one form or the other. Vue.js has an ESM module which is useless without babel (due to the .vue file format), and Angular/React are still in the lets-invent-our-own-language fatigue.
- korla 6y ago
  React has no invented language. You’re thinking about jsx which isn’t needed. It is recommended, however.
  - cookiengineer 6y ago
    > It is used everywhere, however. Fixed that for you. React without jsx components is just as useless as Vue without .vue files. If you cannot use the ecosystem of a framework in practice, your framework isn’t a framework anymore.
    - dragonwriter 6y ago
      > React without jsx components is just as useless as Vue without .vue files. It's not useless at all. JSX in React is just an alternate syntax for React.createElement calls.
      - deleted 6y ago
        [deleted]
    - aaronjxz 6y ago
      Wrong, you can still use VueJS without the vue extension... https://dev.to/arswaw/create-a-lightweight-componentized-spa-without-node-569j https://dev.to/arswaw/create-a-lightweight-componentized-spa...
taurath 6y ago
The challenge of JS is and has always been finding a productive corner of all the possibilities of what you can do with it, and optimizing within that corner. Usually that means picking up a subset of well supported frameworks that you like and find works well in the domain you’re in. It also means learning what language features not to use, or at least abstract away their use. People coming from highly opinionated languages with a large standard library tend to shoot themselves in the foot because they don’t understand this, and nobody really tells them. And inevitably a discussion turns into an argument with different sides becoming Balkanized because they use different parts of the possible language/library set.

by qudat 6y ago

masswerk 6y ago

> JS is in a unique position because it can run both code in a browser as well as a server-side/scripting language. In order to do that with any level of success, tooling is required. Mind that this was not that much of a problem back in 1997 with Netscape Navigator and Netscape Enterprise Server. I think, the real issue here is that the JS ecosystem is targeting an abstract implementation, rather than a real world one. Much of the tooling is just about turning the abstract implementation into a real world standard and, in a second step, about packaging (i.e. linking).

bobthepanda 6y ago
> Much of the tooling is just about turning the abstract implementation into a real world standard and, in a second step, about packaging (i.e. linking). So long as you have browsers in various states of compliance and paying customers using those browsers, this will always be a problem.

mikeryan 6y ago

Is it me or is the real problem that someone wrote a package and quickly wrote use “import ...“ instead of writing “const x = require(“...“ Node works fine out of the box from the command line, modules just need to have the correct instructions for the README.

yawaramin 6y ago
That wouldn't have helped anyway. The file was written in TypeScript. Node would have barfed immediately.
- _-o-_ 6y ago
  Libraries with TS codebase almost always have a prebuilt bundle.

cookiengineer 6y ago

> be careful what you install and read the source code to understand what it is doing. That’s the reason why I started to love pika.dev ‘s package search. Webpack still sucks and will ruin your day with hours of unnecessary configurations and fixes. On the other hand, when setting yourself a rule to use plain ESM only without any build system, coding has been a joy. The only thing that still sucks is UI frameworks, because all major frameworks still require a shitty babel workflow in one form or the other. Vue.js has an ESM module which is useless without babel (due to the .vue file format), and Angular/React are still in the lets-invent-our-own-language fatigue.

korla 6y ago
React has no invented language. You’re thinking about jsx which isn’t needed. It is recommended, however.
- cookiengineer 6y ago
  > It is used everywhere, however. Fixed that for you. React without jsx components is just as useless as Vue without .vue files. If you cannot use the ecosystem of a framework in practice, your framework isn’t a framework anymore.
  - dragonwriter 6y ago
    > React without jsx components is just as useless as Vue without .vue files. It's not useless at all. JSX in React is just an alternate syntax for React.createElement calls.
    - deleted 6y ago
      [deleted]
  - aaronjxz 6y ago
    Wrong, you can still use VueJS without the vue extension... https://dev.to/arswaw/create-a-lightweight-componentized-spa-without-node-569j https://dev.to/arswaw/create-a-lightweight-componentized-spa...

taurath 6y ago

The challenge of JS is and has always been finding a productive corner of all the possibilities of what you can do with it, and optimizing within that corner. Usually that means picking up a subset of well supported frameworks that you like and find works well in the domain you’re in. It also means learning what language features not to use, or at least abstract away their use. People coming from highly opinionated languages with a large standard library tend to shoot themselves in the foot because they don’t understand this, and nobody really tells them. And inevitably a discussion turns into an argument with different sides becoming Balkanized because they use different parts of the possible language/library set.