24 ms·

I'm not sure this will help solve any of our problems. Theoretically, there would be no more need for compilation tools after this change is implemented. In p

by spion 4y ago

I'm not sure this will help solve any of our problems. Theoretically, there would be no more need for compilation tools after this change is implemented. In practice, lambdas need to be bundled, frontends still need to be bundled and running typescript in node efficiently nowadays should be as easy as `node -r @swc-node/register path/to/file.ts` So this will actually not ease the JavaScript tooling nightmare.

brundolf 4y ago
Transpiling and bundling are two separate things. Removing the need for one of those would have benefits even if the other were still there That said, I'm not convinced this would actually remove one of them: - It would mean shipping more code which is a no-no - It probably won't ever cover the whole of typescript's features, so many people will continue to use that, and will still have to transpile I'm sure this will help... somebody, but it's going to be a very narrow set of workflows that benefit
- klodolph 4y ago
  This makes both irrelevant, since you can already run code without bundling. Obviously it’s not something you’d do in a normal production environment. It’s nice to be able to run code without any compilation steps if you’re working on something small (e.g. some demo on my personal website) or something in a development environment. I’ve done this. Served up JS with “import” statements everywhere. The devserver just served JS straight from the filesystem without modification. When I change the JS, the browser just needs to reload—there’s no build process, no waiting. The production environment ran it all through Closure. Closure also ran in the dev environment, but it ran asynchronously, in the background, telling you what the errors are. No source maps to deal with. No delays. The browser gets exactly what I write.
  - brundolf 4y ago
    Sure, it's just that very few companies are probably going to be doing this outside of very early prototypes/toy examples. Load time is just too important
    - klodolph 4y ago
      So? Prototypes / dev are important.
- mekster 4y ago
  Stewardship of JS may align more with TS and may be better for the future of JS than TS going its way.
laurencerowe 4y ago
Not requiring bundling to be setup during development is a huge win for developer ergonomics. Though I prefer to write TypeScript I've avoided it in some small projects where I didn't want the hassle of setting up the transpiler / watcher / etc. Production bundling can then be as simple as running `deno bundle index.js` or similar.
- seniorsassycat 4y ago
  that's solved easily enough with ts-node or swc
  - laurencerowe 4y ago
    It's not when you're writing code for a browser.
algerd 4y ago
It will reduce complexity of the existing tools.

by spion 4y ago

brundolf 4y ago

Transpiling and bundling are two separate things. Removing the need for one of those would have benefits even if the other were still there That said, I'm not convinced this would actually remove one of them: - It would mean shipping more code which is a no-no - It probably won't ever cover the whole of typescript's features, so many people will continue to use that, and will still have to transpile I'm sure this will help... somebody, but it's going to be a very narrow set of workflows that benefit

klodolph 4y ago
This makes both irrelevant, since you can already run code without bundling. Obviously it’s not something you’d do in a normal production environment. It’s nice to be able to run code without any compilation steps if you’re working on something small (e.g. some demo on my personal website) or something in a development environment. I’ve done this. Served up JS with “import” statements everywhere. The devserver just served JS straight from the filesystem without modification. When I change the JS, the browser just needs to reload—there’s no build process, no waiting. The production environment ran it all through Closure. Closure also ran in the dev environment, but it ran asynchronously, in the background, telling you what the errors are. No source maps to deal with. No delays. The browser gets exactly what I write.
- brundolf 4y ago
  Sure, it's just that very few companies are probably going to be doing this outside of very early prototypes/toy examples. Load time is just too important
  - klodolph 4y ago
    So? Prototypes / dev are important.
mekster 4y ago
Stewardship of JS may align more with TS and may be better for the future of JS than TS going its way.

laurencerowe 4y ago

Not requiring bundling to be setup during development is a huge win for developer ergonomics. Though I prefer to write TypeScript I've avoided it in some small projects where I didn't want the hassle of setting up the transpiler / watcher / etc. Production bundling can then be as simple as running `deno bundle index.js` or similar.

seniorsassycat 4y ago
that's solved easily enough with ts-node or swc
- laurencerowe 4y ago
  It's not when you're writing code for a browser.

algerd 4y ago

It will reduce complexity of the existing tools.