61–70 of 134 posts
> I really think that the needs of server side code are different enough than the needs of client side code that we’re better off drawing from Python and Ruby than from Dojo and jQuery. This sentence sounds ok until Python and Ruby are held as the apparent gold standard of server development. That's not really the case, I think?
Remember this was 10+ years ago. Many of the contemporary gold standards weren't fully a thing yet.
Does anyone have a detailed understanding of why CommonJS (and its async incarnation, AMD) were not adopted by browsers? I do much like the `import` syntax personally and its a little cleaner to read, but CommonJS and AMD were the undisputed winners of the module format until ES Modules were born. Not that I have a problem with ES Modules, I don't, however I am interested in what was so insufficient about the precedi…
> and its async incarnation, AMD A bare-bones implementation of AMD could be put together with less than a kilobyte of JavaScript (this is what we used at Mozilla for a minute circa 2012). Meanwhile, the ECMAScript folks were working on ES6, which was going to have a module system. Why would the browser build in support for a highly-opinionated system that you could implement yourself so trivially, all while a TC39-b…
Does anyone have a detailed understanding of why CommonJS (and its async incarnation, AMD) were not adopted by browsers? I do much like the `import` syntax personally and its a little cleaner to read, but CommonJS and AMD were the undisputed winners of the module format until ES Modules were born. Not that I have a problem with ES Modules, I don't, however I am interested in what was so insufficient about the precedi…
CommonJS requires invoking the code before the modules can be resolved, versus the ESModule syntax with "import" can be parsed out of the code separately (from the AST because it is a keyword). No invocation required. I don't know if that's the entire story -- probably not -- but I do know that is one major differentiator for things like generating import-graphs and performing tree shaking. (you can still do like `im…
The problem with Javascript modules = Everyone will be forced to run a full web server to do anything (to handle CORS restrictions). We all lose the ability to simply have a local index.html file, and have it Just Work (TM): This ability is amazing for demos, fast iteration, onboarding new devs and developing without a ton of layers of js ecosystem machinery. Deno doesn't care about retaining this level of developer…
Is CommonJS even a thing for javascript running in web browsers? Moving from CommonJS to modules shouldn't affect any running in a browser.
Does anyone have a detailed understanding of why CommonJS (and its async incarnation, AMD) were not adopted by browsers? I do much like the `import` syntax personally and its a little cleaner to read, but CommonJS and AMD were the undisputed winners of the module format until ES Modules were born. Not that I have a problem with ES Modules, I don't, however I am interested in what was so insufficient about the precedi…
CommonJS requires invoking the code before the modules can be resolved, versus the ESModule syntax with "import" can be parsed out of the code separately (from the AST because it is a keyword). No invocation required. I don't know if that's the entire story -- probably not -- but I do know that is one major differentiator for things like generating import-graphs and performing tree shaking. (you can still do like `im…
That case is dealt with more like a `fetch('foo' + someVar).then(r => eval(r.text()))` or similar (but of course it is not just a eval and it instead returns the exports of the module).
Dynamic imports and static ones behave very differently and static analysis generally ignores dynamic imports IIRC.
You also need to treat dynamic imports as async including everything that comes with that (error checking, awaiting, etc.)
> I really think that the needs of server side code are different enough than the needs of client side code that we’re better off drawing from Python and Ruby than from Dojo and jQuery. This sentence sounds ok until Python and Ruby are held as the apparent gold standard of server development. That's not really the case, I think?
Thinking back to when CommonJS was implemented, absolutely. I don't think you'd want to call Spring or ASP the gold standards.
Does anyone have a detailed understanding of why CommonJS (and its async incarnation, AMD) were not adopted by browsers? I do much like the `import` syntax personally and its a little cleaner to read, but CommonJS and AMD were the undisputed winners of the module format until ES Modules were born. Not that I have a problem with ES Modules, I don't, however I am interested in what was so insufficient about the precedi…
I can speak to the one listed in the article: "difficult to tree-shake, which can remove unused modules and minimize bundle size." This is because of a much deeper issue: static analysis is highly complex with the near-free-for-all that is CommonJS require & module.exports syntax. ES Modules is stricter and much easier to statically deal with. At a high level, why? You can throw just about anything in an exports.modu…
I think dynamic imports have some of the same footguns here, to be honest. Can't deny ESM is easier to statically analyze though, that much appears to be true across the board based on available evidence.
Earlier quoted context omitted.
Every time this is mentioned, the person is heavily downvoted. But if you were here in the 2000, that's exactly what happened. In fact, this very article starts with "JavaScript, the undisputed king of web development, is being sabotaged — not by a rival language or a revolutionary new technology, but by its own baggage from the past.". That's the first sentence. Nobody wanted to work with JS, it was used to make sno…
> But if you were here in the 2000, that's exactly what happened. That was 23 years ago. It's an entire generation. A baby born after that point could now be working as a fully fledged adult. > I've yet to met anybody who knows Python/Ruby/C#/Java/Rujst/Go and JS to chose JS outside of the web. Because there, we have the choice. I would. Typescript is easily the best language for anything from app development to smal…
> That was 23 years ago.
> It's an entire generation. A baby born after that point could now be working as a fully fledged adult.
And yet, it's no less true.
Regarding typescript, that's just, like, your opinion man. I mean, I think typescript is pretty good, especially given that its tied to the design choices of javascript, but objectively the best language. That's way too far.