4 ms·

I can't wait for ES module support in Firefox by default (so all major browsers are covered). It feels so good to be able to write code in "plain old JavaScript

I can't wait for ES module support in Firefox by default (so all major browsers are covered). It feels so good to be able to write code in "plain old JavaScript" again without the need for transpilers and build tools for small apps. I made this minecraft WebGL2 thing (https://mrspeaker.github.io/webgl2-voxels/ https://mrspeaker.github.io/webgl2-voxels/) all in modules, and being able to just view-source without any shenanigans feels like the old days. The only issue now is I want to share the code with a Node server... I really hope the new proposals will help bridge the require/import gap!

shriek 9y ago
I was playing with @std/esm yesterday and it helps bridge that gap somewhat. I agree it feels great to not have to transpile anymore. :)
- WorldMaker 9y ago
  That module loader was declared "stable" today, even. https://medium.com/web-on-the-edge/tomorrows-es-modules-today-c53d29ac448c https://medium.com/web-on-the-edge/tomorrows-es-modules-toda...
  - 52-6F-62 9y ago
    Wow! That's great! Thanks for linking this
drudru11 9y ago
Nice demo!
TheAceOfHearts 9y ago
It's great for small apps, demos, and development! But for deploying it'll probably continue to be a good idea to have build step. If you need to support a wider range of browser, you'll want a transpilation step. Minifying can drastically reduce the payload size. If you want tree shaking, that requires a build tool. Even with HTTP 2.0 and being able to push stuff down to the client you'll need to crawl the dependency graph and generate some kind of manifest for the server to know what to send. You can do those things on the fly, but that's just turning it into an implicit build step. Depending on how frequently things are changing, there's also the matter of simultaneous versions of the app running at same time. If you're loading modules asynchronously, a user with Version A of the app could end up importing something meant for Version B. Users sometimes go for weeks or longer without refreshing a tab. Tools like Webpack make it easy to have all your module references updated and named correctly to avoid this kind of clash. These aren't problems that all apps need to handle. In fact, it's great if you can get away without any of it! But those kinds of use-cases are what tools such as Webpack help to solve.
- thelarkinn 9y ago
  Exactly. Alt-Title: Why we use webpack.
thelarkinn 9y ago
Hi there!!! Sean from the webpack team! For a development environment this is great. However if there's any takeaway from this post, it is the reminder that all of the resolve, parse, eval, execute, graph traversal, and linking has to be done at runtime, so if you are okay with your app taking 1000x longer to load then if you bundle it, then I guess that's a personal preference. However, we will continue to endorse for the sake of web performance that you bundle your code, and not use modules natively :-)

shriek 9y ago

I was playing with @std/esm yesterday and it helps bridge that gap somewhat. I agree it feels great to not have to transpile anymore. :)

WorldMaker 9y ago
That module loader was declared "stable" today, even. https://medium.com/web-on-the-edge/tomorrows-es-modules-today-c53d29ac448c https://medium.com/web-on-the-edge/tomorrows-es-modules-toda...
- 52-6F-62 9y ago
  Wow! That's great! Thanks for linking this

drudru11 9y ago

Nice demo!

TheAceOfHearts 9y ago

It's great for small apps, demos, and development! But for deploying it'll probably continue to be a good idea to have build step. If you need to support a wider range of browser, you'll want a transpilation step. Minifying can drastically reduce the payload size. If you want tree shaking, that requires a build tool. Even with HTTP 2.0 and being able to push stuff down to the client you'll need to crawl the dependency graph and generate some kind of manifest for the server to know what to send. You can do those things on the fly, but that's just turning it into an implicit build step. Depending on how frequently things are changing, there's also the matter of simultaneous versions of the app running at same time. If you're loading modules asynchronously, a user with Version A of the app could end up importing something meant for Version B. Users sometimes go for weeks or longer without refreshing a tab. Tools like Webpack make it easy to have all your module references updated and named correctly to avoid this kind of clash. These aren't problems that all apps need to handle. In fact, it's great if you can get away without any of it! But those kinds of use-cases are what tools such as Webpack help to solve.

thelarkinn 9y ago
Exactly. Alt-Title: Why we use webpack.

thelarkinn 9y ago

Hi there!!! Sean from the webpack team! For a development environment this is great. However if there's any takeaway from this post, it is the reminder that all of the resolve, parse, eval, execute, graph traversal, and linking has to be done at runtime, so if you are okay with your app taking 1000x longer to load then if you bundle it, then I guess that's a personal preference. However, we will continue to endorse for the sake of web performance that you bundle your code, and not use modules natively :-)