5 ms·

I just serve my ESM modules directly from the filesystem. It works well, builds in literally 0 seconds. You also don't need a transpiler like Babel if you drop

I just serve my ESM modules directly from the filesystem. It works well, builds in literally 0 seconds. You also don't need a transpiler like Babel if you drop support for IE11. Almost all ES6 features– such as classes, proxies, arrow functions, and async are supported by modern browsers and their older versions. As long as you avoid features like static, private, and ??=, you get instant compile times. It's not 2015. You don't need a transpiler to write modern JavaScript. As of writing, the latest version of Safari is 14 and the latest version of Chrome is 88. These features fully work in Safari 13 and Chrome 70, which have less than 1% of marketshare.

nicoburns 6y ago
Alas, many of us still need to support IE11. We alas get a lot of value out of TypeScript, which needs to be transpiled. <1 second with esbuild is pretty good!
- crazypython 6y ago
  Here's my suggestion if you want faster builds: In development, use an index.html that loads it directly from the filesystem, using a single-pass annotation remover such as https://github.com/alangpierce/sucrase https://github.com/alangpierce/sucrase A single-pass transpiler doesn't build an AST, instead just looping over everything once, which will surely make it faster than esbuild. In production, use a bundler like snowpack.
  - ljm 6y ago
    What you're saying there is: in development, use sucrase. In production, use sucrase. And saying it quite a lot in this thread.
    - crazypython 6y ago
      Sorry, I meant to say use snowpack.
- runarberg 6y ago
  You can annotate your code with JSDoc comments and get the full value of TypeScript while just writing JavaScript without any transpilation step[1]. It won’t help you with IE11 support though. 1: https://www.typescriptlang.org/docs/handbook/intro-to-js-ts.html https://www.typescriptlang.org/docs/handbook/intro-to-js-ts....
  - pitaj 6y ago
    That's a helpful feature but it's by no means a replacement for Typescript. You do not get the full value with just inline comments, in fact that usage is extremely limited.
ko27 6y ago
1. How do you handle npm dependencies that don't expose ES modules? 2. How do you handle the performance impact of your browser doing multiple sequantial requests because it doesn't know your whole dependecy tree?
- crazypython 6y ago
  > 1. How do you handle npm dependencies that don't expose ES modules? See my comment above. > 2. How do you handle the performance impact of your browser doing multiple sequantial requests because it doesn't know your whole dependecy tree? Put all your dependencies in the HTML file, so it fetches them all in parallel. So instead of just loading the root application file and forcing the browser to resolve dependencies: <script type="module" src="/scripts/app.js" defer></script> Load the dependencies like this: <script type="module" src="/scripts/lib/gui.js" defer></script> <script type="module" src="/scripts/lib/guielements.js" defer></script> <script type="module" src="/scripts/lib/network.js" defer></script> <script type="module" src="/scripts/lib/input.js" defer></script> <script type="module" src="/scripts/lib/rendering.js" defer></script> <script type="module" src="/scripts/lib/sockets.js" defer></script> <script type="module" src="/scripts/lib/world.js" defer></script> <script type="module" src="/scripts/lib/ui/classupgrades.js" defer></script> <script type="module" src="/scripts/lib/ui/toasts.js" defer></script> <script type="module" src="/scripts/lib/netstore/minimap.js" defer></script> <script type="module" src="/scripts/data/configuration.js" defer></script> <script type="module" src="/scripts/app.js" defer></script> You can see a demonstration of this technique on my production site, a complex JavaScript SPA that loads everything (including dynamic content) in less than one second: http://vnav.io http://vnav.io For a small performance boost, you can load smaller files first via <link rel=preload>.
  - keb_ 6y ago
    Hi, I tried accessing your site, but seems like it's stuck in this weird reload loop. It never full loads. I'm on Ubuntu 20.04 using the latest Firefox, if that helps. EDIT: Seems to load fine in Chromium.
    - 6y ago
brundolf 6y ago
I would say the primary motivators at this point have shifted from browser compatibility to syntaxes like TypeScript and JSX that will (likely) never be supported natively
- crazypython 6y ago
  > I would say the primary motivators at this point have shifted from browser compatibility to syntaxes like TypeScript and JSX that will (likely) never be supported natively I suggest using a single-pass transpiler like Surcase[0] that doesn't translate to IE11-compatible syntax, and just loops through the string once, avoiding generating an AST– making it much faster– removing TypeScript annotations and desugaring JSX. If you additionally need to support IE11, you can use a development build with Surcase and a production build with a bundler like Snowpack. C/C++ developers have been doing things like this for ages: compiling files as objects during development, and compiling them into one big binary for production. [0]: https://github.com/alangpierce/sucrase https://github.com/alangpierce/sucrase
  - IggleSniggle 6y ago
    Surcase is often slower than ESBuild since it is single-threaded. The benchmark posted on its README forces ESBuild to run single-threaded, and is thus a bit misleading.
SahAssar 6y ago
If you have any third party dependencies you still need something like snowpack though, right?
- crazypython 6y ago
  I don't have any third-party dependencies. We all agree the JS ecosystem sucks. When I do, I use a script tag, and put it before my ESM modules: <script src="/scripts/data/contractor.js"></script> Use them via global variables. I generally avoid third-party JavaScript modules for performance and maintainability reasons. When I do use them, I'll frequently vendorize them (put them in my source tree) and make ESM modules for them.
  - thitcanh 6y ago
    So you’re the one writing everything from scratch even though the wheel has already been invented and perfected and tested over years by many developers. Also your website is serving dozens of cascading files instead of a single minified one. Feels like 2010 to me.
    - ratww 6y ago
      It's the opposite. Bundlers aren't the "wheels" here. The real "wheels" here are ESM modules, which have been available in every modern browser for a while. Bundlers are just pre-wheel, prehistoric, stopgap technology from the 2010s that we should be moving away from. And there's no problem serving multiple files in 2020 because we have HTTP2 multiplexing now. In fact, it's probably more efficient than using bundling, because you can cache much better. Minification is also virtually unnecessary with Brotli, and not minifying has the added benefit of making the debugging experience much better. And bundlers haven't been "perfected". Not even close. Webpack is without a doubt the worst piece of technology in my stack right now, together with Babel. Those two are terrible by themselves, but they also manage to "infect" other things elsewhere in my stack: for example, ESLint and Jest need Webpack/Babel plugins to work.
      - 6y ago
krainboltgreene 6y ago
> You also don't need a transpiler like Babel if you drop support for IE11 I really dislike this line of thought: Babel isn't just a polyfill tool. It's an incredible way to enhance your code. Further, the future of javascript changes isn't static and shouldn't be.
phplovesong 6y ago
This works IF you write 100% vanilla javascript. In larger projects a vanilla javascript approach usually falls short. I cant see a large project being written without a types in 2021. So you still need a build step, no matter if you are using Typescript, flow or some other typed version.

nicoburns 6y ago

Alas, many of us still need to support IE11. We alas get a lot of value out of TypeScript, which needs to be transpiled. <1 second with esbuild is pretty good!

crazypython 6y ago
Here's my suggestion if you want faster builds: In development, use an index.html that loads it directly from the filesystem, using a single-pass annotation remover such as https://github.com/alangpierce/sucrase https://github.com/alangpierce/sucrase A single-pass transpiler doesn't build an AST, instead just looping over everything once, which will surely make it faster than esbuild. In production, use a bundler like snowpack.
- ljm 6y ago
  What you're saying there is: in development, use sucrase. In production, use sucrase. And saying it quite a lot in this thread.
  - crazypython 6y ago
    Sorry, I meant to say use snowpack.
runarberg 6y ago
You can annotate your code with JSDoc comments and get the full value of TypeScript while just writing JavaScript without any transpilation step[1]. It won’t help you with IE11 support though. 1: https://www.typescriptlang.org/docs/handbook/intro-to-js-ts.html https://www.typescriptlang.org/docs/handbook/intro-to-js-ts....
- pitaj 6y ago
  That's a helpful feature but it's by no means a replacement for Typescript. You do not get the full value with just inline comments, in fact that usage is extremely limited.

ko27 6y ago

1. How do you handle npm dependencies that don't expose ES modules? 2. How do you handle the performance impact of your browser doing multiple sequantial requests because it doesn't know your whole dependecy tree?

crazypython 6y ago
> 1. How do you handle npm dependencies that don't expose ES modules? See my comment above. > 2. How do you handle the performance impact of your browser doing multiple sequantial requests because it doesn't know your whole dependecy tree? Put all your dependencies in the HTML file, so it fetches them all in parallel. So instead of just loading the root application file and forcing the browser to resolve dependencies: <script type="module" src="/scripts/app.js" defer></script> Load the dependencies like this: <script type="module" src="/scripts/lib/gui.js" defer></script> <script type="module" src="/scripts/lib/guielements.js" defer></script> <script type="module" src="/scripts/lib/network.js" defer></script> <script type="module" src="/scripts/lib/input.js" defer></script> <script type="module" src="/scripts/lib/rendering.js" defer></script> <script type="module" src="/scripts/lib/sockets.js" defer></script> <script type="module" src="/scripts/lib/world.js" defer></script> <script type="module" src="/scripts/lib/ui/classupgrades.js" defer></script> <script type="module" src="/scripts/lib/ui/toasts.js" defer></script> <script type="module" src="/scripts/lib/netstore/minimap.js" defer></script> <script type="module" src="/scripts/data/configuration.js" defer></script> <script type="module" src="/scripts/app.js" defer></script> You can see a demonstration of this technique on my production site, a complex JavaScript SPA that loads everything (including dynamic content) in less than one second: http://vnav.io http://vnav.io For a small performance boost, you can load smaller files first via <link rel=preload>.
- keb_ 6y ago
  Hi, I tried accessing your site, but seems like it's stuck in this weird reload loop. It never full loads. I'm on Ubuntu 20.04 using the latest Firefox, if that helps. EDIT: Seems to load fine in Chromium.
  - 6y ago

brundolf 6y ago

I would say the primary motivators at this point have shifted from browser compatibility to syntaxes like TypeScript and JSX that will (likely) never be supported natively

crazypython 6y ago
> I would say the primary motivators at this point have shifted from browser compatibility to syntaxes like TypeScript and JSX that will (likely) never be supported natively I suggest using a single-pass transpiler like Surcase[0] that doesn't translate to IE11-compatible syntax, and just loops through the string once, avoiding generating an AST– making it much faster– removing TypeScript annotations and desugaring JSX. If you additionally need to support IE11, you can use a development build with Surcase and a production build with a bundler like Snowpack. C/C++ developers have been doing things like this for ages: compiling files as objects during development, and compiling them into one big binary for production. [0]: https://github.com/alangpierce/sucrase https://github.com/alangpierce/sucrase
- IggleSniggle 6y ago
  Surcase is often slower than ESBuild since it is single-threaded. The benchmark posted on its README forces ESBuild to run single-threaded, and is thus a bit misleading.

SahAssar 6y ago

If you have any third party dependencies you still need something like snowpack though, right?

crazypython 6y ago
I don't have any third-party dependencies. We all agree the JS ecosystem sucks. When I do, I use a script tag, and put it before my ESM modules: <script src="/scripts/data/contractor.js"></script> Use them via global variables. I generally avoid third-party JavaScript modules for performance and maintainability reasons. When I do use them, I'll frequently vendorize them (put them in my source tree) and make ESM modules for them.
- thitcanh 6y ago
  So you’re the one writing everything from scratch even though the wheel has already been invented and perfected and tested over years by many developers. Also your website is serving dozens of cascading files instead of a single minified one. Feels like 2010 to me.
  - ratww 6y ago
    It's the opposite. Bundlers aren't the "wheels" here. The real "wheels" here are ESM modules, which have been available in every modern browser for a while. Bundlers are just pre-wheel, prehistoric, stopgap technology from the 2010s that we should be moving away from. And there's no problem serving multiple files in 2020 because we have HTTP2 multiplexing now. In fact, it's probably more efficient than using bundling, because you can cache much better. Minification is also virtually unnecessary with Brotli, and not minifying has the added benefit of making the debugging experience much better. And bundlers haven't been "perfected". Not even close. Webpack is without a doubt the worst piece of technology in my stack right now, together with Babel. Those two are terrible by themselves, but they also manage to "infect" other things elsewhere in my stack: for example, ESLint and Jest need Webpack/Babel plugins to work.
    - 6y ago

krainboltgreene 6y ago

> You also don't need a transpiler like Babel if you drop support for IE11 I really dislike this line of thought: Babel isn't just a polyfill tool. It's an incredible way to enhance your code. Further, the future of javascript changes isn't static and shouldn't be.

phplovesong 6y ago

This works IF you write 100% vanilla javascript. In larger projects a vanilla javascript approach usually falls short. I cant see a large project being written without a types in 2021. So you still need a build step, no matter if you are using Typescript, flow or some other typed version.