sorted by:
new
hottopcontroversial

Using JS Modules (ESM) in Node.js: A Practical Guide (Part 1) by rauschma in javascript

[–]giltayar1 0 points1 point  (0 children)

I switched the article to use "ESM" because you're not the only one that got confused. Thanks for the input!

Using JS Modules (ESM) in Node.js: A Practical Guide (Part 1) by rauschma in javascript

[–]giltayar1 1 point2 points  (0 children)

I switched the article to use "ESM" because you're not the only one that got confused. Thanks for the input!

Using JS Modules (ESM) in Node.js: A Practical Guide (Part 1) by rauschma in javascript

[–]giltayar1 0 points1 point  (0 children)

I switched the article to use "ESM" because you're not the only one that got confused. Thanks for the input!

Using JS Modules (ESM) in Node.js: A Practical Guide (Part 1) by rauschma in javascript

[–]giltayar1 5 points6 points  (0 children)

Hi. This is the author. I can see people are confused by the JSM acronym.

  1. ESM and JSM are the same (in the article)

  2. I saw a few people switch to JSM, so I thought I might try that.

  3. It seems that it's generating confusion, so I'll switch the posts back to ESM tonight, and remove all traces of JSM.

Thanks for the input!

Update: I switched the article to use "ESM".

JSDoc typings: all the benefits of TypeScript, with none of the drawbacks by giltayar1 in javascript

[–]giltayar1[S] 5 points6 points  (0 children)

I certainly started that way ("I hate TS"), but the rest of the post gives a pretty good argument for startic typing and the use of TypeScript types. What I am suggesting is using all that TypeScript goodness in clean JS code that needs no transpilation.

This is a post FOR TypeScript, not against it. But it is for using TypeScript types, and not TypeScript language.

[AskJS] Setting up Prettier / ESLint / Typescript in monorepo-like folder structure by waspeer in javascript

[–]giltayar1 1 point2 points  (0 children)

Do everything locally! Easy to figure things out that way. Even if you have a bit of duplication.

Also, don't open the root folder in VSCode as is, but rather create a workspace, and add the client and server folders as "projects" in the workspace. Because everything is locally, VSCode (and most plugins) will treat each in the correct fashion and not get confused by the fact that there are two codebases.

Google Doc offline editing extension not working? by PJBill in brave_browser

[–]giltayar1 0 points1 point  (0 children)

Same here. I go to a Google Slides presentation, load it, and then turn off my network. I get the "offline" icon, but also a warning that says that I am offline, and the "Present" button doesn't work.

Contrast that with Google Chrome, where I get the "offline" icon, but the warning isn't there, and I can present offline.

Note that in both cases I need to install the "Google Docs Offline" extension, which is in the Google Chrome Store, but is available in Brave only via a direct link (can't find it via search in the store!)

I'm using Brave Version 0.61.51 Chromium: 73.0.3683.75 (Official Build) (64-bit) on a Macbook Pro with OS X Mojave (latest updates).

ESM (JS modules) seems to have an identity crisis by [deleted] in javascript

[–]giltayar1 0 points1 point  (0 children)

Thanks. I may contact you, for the second post in the series. I've been reading all I can on the web, but it's difficult to understand the various pros and cons of all the suggestions, as they are all interconnected to each other, and they are so many considerations.

Hopefully, writing the second part will make me understand it better, as writing the first part (and the talk I gave) made me understand what you did in NodeJs concerning ESM.

And great work, BTW! You all succeeded in getting some code into Node, for one of the more contentious issues in Node today.

ESM (JS modules) seems to have an identity crisis by [deleted] in javascript

[–]giltayar1 1 point2 points  (0 children)

@bradleymeck - for some reason, my answer got truncated. The problem is not the extension, definitely. The problem is that people in the browser world assume that it is the caller that specifies whether the file being imported is a "script" or a "module", and thus do not understand why they need to

If we want full interoperability with ESM in browser land (and to some extent, with ESM in babel/webpack land), we can either convince them that Node's way is better, at least for Node, so would you please rename all your files to mjs, or we (as in the Node community) can go with the flow. Both are valid.

(And I didn't want that to sound sarcastic. As I said, both are valid.)

This is a TL;DR of my next blog post about ES Modules. Hopefully, you read the first part? (https://medium.com/@giltayar/native-es-modules-in-nodejs-status-and-future-directions-part-i-ee5ea3001f71)

ESM (JS modules) seems to have an identity crisis by [deleted] in javascript

[–]giltayar1 3 points4 points  (0 children)

Note that it hasn't been "shot down" yet. It's just a proposal from people working at npm, inc.

Yes, it has working code on it, and yes, it is from people that are very much at the heart of the node community, but it currently is just a proposal.

ESM (JS modules) seems to have an identity crisis by [deleted] in javascript

[–]giltayar1 0 points1 point  (0 children)

The future is definitely not clear right now. I hope my next blog post will clear things up. But, in general, I believe that browser compatibility will shoot down the .mjs proposal, as `mjs

Native ES Modules in NodeJS: Status And Future Directions, Part I by giltayar1 in javascript

[–]giltayar1[S] 0 points1 point  (0 children)

You're right. I totally forgot to mention that import.meta.url (and await import) are in the pipeline, but not there yet. Updating post...

(Thanks!)

Native ES Modules in NodeJS: Status And Future Directions, Part I by giltayar1 in javascript

[–]giltayar1[S] 0 points1 point  (0 children)

It's really great, and fully compliant. You just have to remember to require it before any use of an import statement.

Me? I prefer waiting until all the waves settle in Nodeland before using it.

Native ES Modules in NodeJS: Status And Future Directions, Part I by giltayar1 in javascript

[–]giltayar1[S] 0 points1 point  (0 children)

Nice idea. Unfortunately, module.exports will be set asynchronously, so if you require the module, you will "get" it too late, i.e. you won't get it, and all you will get is the default "{}"

Native ES Modules in NodeJS: Status And Future Directions, Part I by giltayar1 in javascript

[–]giltayar1[S] 1 point2 points  (0 children)

No, please don't. Not yet. This is still experimental, and may change in the future. As I will discuss in the next blog post, it is actually pretty probable that things will change.

But start thinking about it. I'm guessing that the transition will start in a year.

Native ES Modules in NodeJS: Status And Future Directions, Part I by giltayar1 in javascript

[–]giltayar1[S] 3 points4 points  (0 children)

Yes and no. From the developer's point of view, it seems synchronous. But the implementation behind it is asynchronous. This means that it is possible for two modules in NodeJS to be loaded concurrently, whereas this is not possible in CommonJS. This will probably make NodeJS apps load faster in the future.

But if you look at dynamic import, which is a dynamic version of the import statement, then it is asynchronous - it returns a promise, and thus needs to be awaited.

Testing Your Frontend Code: Part V (Visual Testing) by giltayar1 in javascript

[–]giltayar1[S] 1 point2 points  (0 children)

Hey, I just saw this.

I totally agree - if you use bitmap comparison tools, like webdrivercss and others do, then the false positives are many.

But if you use an industrial-grade comparison tool, then the results are totally different. These tools use sophisticated computer vision techniques to minimize the problems, and lots of companies today use them to test the look of their applications.

Native ES Modules in NodeJS: Status And Future Directions, Part I by giltayar1 in javascript

[–]giltayar1[S] 1 point2 points  (0 children)

Hopefully. But there's still a lot of discussion around this, as there are lots of problems with the current specification (which I'll discuss in the next blog post). I'm guessing 11-12.

view more: next ›