4 ms·

Most of my projects now use babel indirectly and its been removed from all backend projects at work, sometimes replaced with typescript or vanilla es6. Ex: any

Most of my projects now use babel indirectly and its been removed from all backend projects at work, sometimes replaced with typescript or vanilla es6. Ex: anyone using facebook's jest, vue-cli, etc will get v7 whenever those packages upgrade. The typescript support seems interesting for people with large babel pipelines, but I'm not sure what the other use cases are since it doesn't do any of the typechecking tsc does. Would be interested in hearing what people plan to use it for. https://blogs.msdn.microsoft.com/typescript/2018/08/27/typescript-and-babel-7/ https://blogs.msdn.microsoft.com/typescript/2018/08/27/types...

kevmo314 8y ago
One benefit of running babel in parallel with tsc is that your execution doesn't depend on your code compiling. Sometimes, for example, if I'm hacking something together, it's faster to just disable type checking all together so I can do what needs to be done and save the type checking until later. Having babel + tsc allows you to do just that instead of having to do all the typing as you go.
- cowmoo728 8y ago
  tsc in --watch mode still outputs even if there are type errors for precisely this reason. You can ignore the cli warnings and still have everything run in the browser or node while developing.
  - tracker1 8y ago
    Typescript doesn't let me play with stage0-3 features of EcmaScript.
    - tracker1 8y ago
      Replying to myself... looks like typescript now integrates with babel better. May actually convert my latest project next week.
TheAceOfHearts 8y ago
I also haven't been using babel for most node projects; V8 has already implemented most of the major features I'm interested in. I don't mind setting up a build tool and configuring everything if the project will be actively maintained or if there's a real need for it, but for smaller projects I think it's better to keep things as simple as possible. It's a huge drag when you later revisit a project and a bunch of dependencies are outdated or broken. One of the holdouts which kept me coming back to babel was JSX, but eventually I learned to love preact and its hyperscript-inspired template function. The code ends up being a bit more verbose but you drastically cut down on dependencies. Babel is still superb if you're targeting a broad range of browsers. Although during development I usually disable babel-loader from Webpack for the improved performance and debugging experience.
bombtrack 8y ago
I recently evaluated using Typescript's compiler or Babel + TS plugin, and decided to use Babel. The main reason was keeping access to the Babel plugin ecosystem without needing to do tsc -> babel -> output, which would be a drag in development. It seems to be more common now to see library-specific Babel plugins that optimize performance or improve developer ux. These plugins are usually optional, but I use them to enhance css-in-js and i18n performance/development. With good editor support and ts-lint, the dev experience is solid and as-expected. Setting up an explicit tsc command as a pre-commit hook or CI task should provide that extra bit of confidence. For myself, not being a TS purist, it feels like a good option.
Vinnl 8y ago
It allows you to add TypeScript to your Babel project like you'd add a linter, i.e. you can optionally run tsc to catch potential problems, but in your build pipeline just skip that and build it using the full Babel ecosystem.

kevmo314 8y ago

One benefit of running babel in parallel with tsc is that your execution doesn't depend on your code compiling. Sometimes, for example, if I'm hacking something together, it's faster to just disable type checking all together so I can do what needs to be done and save the type checking until later. Having babel + tsc allows you to do just that instead of having to do all the typing as you go.

cowmoo728 8y ago
tsc in --watch mode still outputs even if there are type errors for precisely this reason. You can ignore the cli warnings and still have everything run in the browser or node while developing.
- tracker1 8y ago
  Typescript doesn't let me play with stage0-3 features of EcmaScript.
  - tracker1 8y ago
    Replying to myself... looks like typescript now integrates with babel better. May actually convert my latest project next week.

TheAceOfHearts 8y ago

I also haven't been using babel for most node projects; V8 has already implemented most of the major features I'm interested in. I don't mind setting up a build tool and configuring everything if the project will be actively maintained or if there's a real need for it, but for smaller projects I think it's better to keep things as simple as possible. It's a huge drag when you later revisit a project and a bunch of dependencies are outdated or broken. One of the holdouts which kept me coming back to babel was JSX, but eventually I learned to love preact and its hyperscript-inspired template function. The code ends up being a bit more verbose but you drastically cut down on dependencies. Babel is still superb if you're targeting a broad range of browsers. Although during development I usually disable babel-loader from Webpack for the improved performance and debugging experience.

bombtrack 8y ago

I recently evaluated using Typescript's compiler or Babel + TS plugin, and decided to use Babel. The main reason was keeping access to the Babel plugin ecosystem without needing to do tsc -> babel -> output, which would be a drag in development. It seems to be more common now to see library-specific Babel plugins that optimize performance or improve developer ux. These plugins are usually optional, but I use them to enhance css-in-js and i18n performance/development. With good editor support and ts-lint, the dev experience is solid and as-expected. Setting up an explicit tsc command as a pre-commit hook or CI task should provide that extra bit of confidence. For myself, not being a TS purist, it feels like a good option.

Vinnl 8y ago

It allows you to add TypeScript to your Babel project like you'd add a linter, i.e. you can optionally run tsc to catch potential problems, but in your build pipeline just skip that and build it using the full Babel ecosystem.