5 ms·

> Just the main JS parser file [0] is 12k lines While that is impressive, I think this is also an indication of a problem: the grammar is becoming unwieldy. Fo

by lhorie 6y ago

> Just the main JS parser file [0] is 12k lines While that is impressive, I think this is also an indication of a problem: the grammar is becoming unwieldy. For example, even for someone as prolific as Evan, he must decide between feature depth (e.g. bundle splitting) and feature breadth (e.g. implementing the equivalent to @babel/preset-flow, which is used by both flow and hegel[0] type systems)[1] Esbuild supporting Typescript and JSX is undoubtedly a byproduct of these grammar extensions having become popular. But supporting extra grammar extensions does add to complexity, sometimes in non-trivial ways. In Typescript, for example, you can import types using runtime import syntax, making it ambiguous whether running side-effects from a library is intentional or not. This gets problematic once you consider treeshaking and not-really-standard things like conditional resolution via package.json's `browser` field. It gets even more fun when you realize that module resolution isn't even specified, meaning that as far as a bundler is concerned, something like `import 'lodash'` means completely different things for a browser vs a project installed via npm vs one installed via yarn v2... [0] https://hegel.js.org/ https://hegel.js.org/ [1] https://github.com/evanw/esbuild/issues/79 https://github.com/evanw/esbuild/issues/79

pbowyer 6y ago
> It gets even more fun when you realize that module resolution isn't even specified, meaning that as far as a bundler is concerned, something like `import 'lodash'` means completely different things for a browser vs a project installed via npm vs one installed via yarn v2... Ugh, why does it have to be different between npm and yarn v2? I'm an occasional JavaScripter and yetserday wrote an automation with Puppeteer. The first line I wrote was import puppeteer from 'puppeteer' only for Node to fail on that. I thought that syntaxt was supported, but I had to change it to const puppeteer = require('puppeteer'); I've no idea if it's a problem with my Node version (12) or what, but it was a real "Huh?" moment.
- acemarke 6y ago
  FWIW, that's not an `npm` vs `yarn` thing. That's a "Node has only recently added support for ES module syntax and it's still mostly experimental" thing: - https://nodejs.org/api/esm.html https://nodejs.org/api/esm.html - https://nodejs.medium.com/node-js-version-14-available-now-8170d384567e https://nodejs.medium.com/node-js-version-14-available-now-8...
  - josephg 6y ago
    Its supported pretty well now but you need to explicitly switch ES module support on in nodejs. The easiest way is via the "type": "module" flag in the package.json file for your project.
- jdlshore 6y ago
  Modules weren't production-grade until Node version 14. Before that, it used CommonJS modules ("require" instead of "import"). It's because Node was invented before EcmaScript modules existed. CommonJS worked well and supporting both was awkward, so the transition took a while.
- pwdisswordfish6 6y ago
  It's an odd thing. The way people talk, you'd think NodeJS and JavaScript are synonymous. Turns out, NodeJS is this generation's JScript, including shoddy support for the language proper, and it includes vendor-specific extensions that you're expected to use instead. It has somehow though managed to escape any of the criticism that gets thrown at other projects pilloried for stuff like this.
  - jiofih 6y ago
    Node came out way before any of these features were invented, and the ES committee knowingly broke compatibility when designing for the browser. Modules are supported since v14 but you have to opt in.
    - pwdisswordfish6 6y ago
      They didn't break compatibility. NodeJS never attempted to be compatible with the Web. The design work that TC-39 and the browser makers did is also much better than what the NodeJS community puts out. And it's a design that was in ECMAScript 6. Six years later, and you still have to opt in. The TypeScript team got it right, working in a way that NodeJS should have been taken lessons from.
      - Scarbutt 6y ago
        The design work that TC-39 and the browser makers did is also much better than what the NodeJS community puts out Like the dumb broken Maps and Sets?
        preya2k 6y ago
        Can you elaborate what you’re referring to?
        rrishi 6y ago
        How are they broken?
        deleted 6y ago
- lucideer 6y ago
  > Ugh, why does it have to be different between npm and yarn v2? Mainly just because yarn v2 went off book[0]. npm vs yarn v1 is a more sane wold. [0] A perspective on Yarn v2 from the creator of Yarn v1: https://twitter.com/sebmck/status/1300664946645069830 https://twitter.com/sebmck/status/1300664946645069830

by lhorie 6y ago

pbowyer 6y ago

> It gets even more fun when you realize that module resolution isn't even specified, meaning that as far as a bundler is concerned, something like `import 'lodash'` means completely different things for a browser vs a project installed via npm vs one installed via yarn v2... Ugh, why does it have to be different between npm and yarn v2? I'm an occasional JavaScripter and yetserday wrote an automation with Puppeteer. The first line I wrote was import puppeteer from 'puppeteer' only for Node to fail on that. I thought that syntaxt was supported, but I had to change it to const puppeteer = require('puppeteer'); I've no idea if it's a problem with my Node version (12) or what, but it was a real "Huh?" moment.

acemarke 6y ago
FWIW, that's not an `npm` vs `yarn` thing. That's a "Node has only recently added support for ES module syntax and it's still mostly experimental" thing: - https://nodejs.org/api/esm.html https://nodejs.org/api/esm.html - https://nodejs.medium.com/node-js-version-14-available-now-8170d384567e https://nodejs.medium.com/node-js-version-14-available-now-8...
- josephg 6y ago
  Its supported pretty well now but you need to explicitly switch ES module support on in nodejs. The easiest way is via the "type": "module" flag in the package.json file for your project.
jdlshore 6y ago
Modules weren't production-grade until Node version 14. Before that, it used CommonJS modules ("require" instead of "import"). It's because Node was invented before EcmaScript modules existed. CommonJS worked well and supporting both was awkward, so the transition took a while.
pwdisswordfish6 6y ago
It's an odd thing. The way people talk, you'd think NodeJS and JavaScript are synonymous. Turns out, NodeJS is this generation's JScript, including shoddy support for the language proper, and it includes vendor-specific extensions that you're expected to use instead. It has somehow though managed to escape any of the criticism that gets thrown at other projects pilloried for stuff like this.
- jiofih 6y ago
  Node came out way before any of these features were invented, and the ES committee knowingly broke compatibility when designing for the browser. Modules are supported since v14 but you have to opt in.
  - pwdisswordfish6 6y ago
    They didn't break compatibility. NodeJS never attempted to be compatible with the Web. The design work that TC-39 and the browser makers did is also much better than what the NodeJS community puts out. And it's a design that was in ECMAScript 6. Six years later, and you still have to opt in. The TypeScript team got it right, working in a way that NodeJS should have been taken lessons from.
    - Scarbutt 6y ago
      The design work that TC-39 and the browser makers did is also much better than what the NodeJS community puts out Like the dumb broken Maps and Sets?
      - preya2k 6y ago
        Can you elaborate what you’re referring to?
      - rrishi 6y ago
        How are they broken?
      - deleted 6y ago
lucideer 6y ago
> Ugh, why does it have to be different between npm and yarn v2? Mainly just because yarn v2 went off book[0]. npm vs yarn v1 is a more sane wold. [0] A perspective on Yarn v2 from the creator of Yarn v1: https://twitter.com/sebmck/status/1300664946645069830 https://twitter.com/sebmck/status/1300664946645069830