3 ms·

I was looking for a good overview of JS modules. This looks helpful for me. > So you can't open your index.html over the file:// protocol. It's not a dealbrea

I was looking for a good overview of JS modules. This looks helpful for me. > So you can't open your index.html over the file:// protocol. It's not a dealbreaker but that is a significant inconvenience for me. I do local development over file:// a lot. One thing I'm wondering about is dynamic loading of modules. Say my main.js should only load extra.js under certain circumstances. How does that look?

dminik 3y ago
For local dev, I usually just spin up a server using python -m http.server . There are no conditional top level imports, but you can call import("thing") which gives you a promise for the module.
- charred_patina 3y ago
  You can also use the http-server npm package, but there's an issue with non-ES6 module resolution. I have started using Vite since it's lightweight, but also provides me with nice to haves module resolution for different module types, and hot reloading. I am not affiliated with Vite in any way, I just really like it for vanilla web dev.
  - wruza 3y ago
    I also used http-server but pressing f5 or including live.js gets old quickly. Vite is a breath of fresh air, for both vanilla formats and “apps” with scss, ts, etc. Finally someone made a no-bs dev watcher and packager. The only thing to note for purists, it creates .vite folder which you have to ignore.
_jesse 3y ago
You can dynamically import using import(): https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/import https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe.... Works basically the same as a static import, just returns a promise that resolves with the module that you're importing.
sublinear 3y ago
> I do local development over file:// a lot. Not meaning to pick at anything here, but to me web dev necessarily requires knowledge and configuration of a web server. What's being sent to the browser in a production setting is an HTTP message, not just the web content. Many features of a non-trivial web page/app will at least require HTTP headers to be set. The "file://" protocol handles this by mocking the full HTTP response for you in the browser, but any deviation from that response on an actual web server has the potential to break your page. I wouldn't rely on opening files directly.

dminik 3y ago

For local dev, I usually just spin up a server using python -m http.server . There are no conditional top level imports, but you can call import("thing") which gives you a promise for the module.

charred_patina 3y ago
You can also use the http-server npm package, but there's an issue with non-ES6 module resolution. I have started using Vite since it's lightweight, but also provides me with nice to haves module resolution for different module types, and hot reloading. I am not affiliated with Vite in any way, I just really like it for vanilla web dev.
- wruza 3y ago
  I also used http-server but pressing f5 or including live.js gets old quickly. Vite is a breath of fresh air, for both vanilla formats and “apps” with scss, ts, etc. Finally someone made a no-bs dev watcher and packager. The only thing to note for purists, it creates .vite folder which you have to ignore.

_jesse 3y ago

You can dynamically import using import(): https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/import https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe.... Works basically the same as a static import, just returns a promise that resolves with the module that you're importing.

sublinear 3y ago

> I do local development over file:// a lot. Not meaning to pick at anything here, but to me web dev necessarily requires knowledge and configuration of a web server. What's being sent to the browser in a production setting is an HTTP message, not just the web content. Many features of a non-trivial web page/app will at least require HTTP headers to be set. The "file://" protocol handles this by mocking the full HTTP response for you in the browser, but any deviation from that response on an actual web server has the potential to break your page. I wouldn't rely on opening files directly.