3 ms·

If Babel is outdated in 2021, what is the best practice for FE build flow? I'm thinking about updating my projects but there too many options to choose from..

by sccxy 5y ago

SavantIdiot 5y ago
We use the JS outputted by TSC in both webpack and nuxt projects. I honestly don't know if that is bad, but I have such a small team that no one really knows. We're not Etsy-sized. :) This article drove it: https://blog.logrocket.com/why-you-dont-need-babel/ https://blog.logrocket.com/why-you-dont-need-babel/ EDIT: Plus we also wanted to go on a package diet because we found ourselves doing too much cut-and-paste from github w/o really knowing how to use all the tools.
WorldMaker 5y ago
The number of transforms that Babel is doing with an "evergreen" config ("last 2 browser versions") at this point is effectively miniscule. It's a massive toolchain for what increasing turns out to be a minimal amount of actual work. "Last 2 Browser Versions" is effectively everything through ES2019 at this point which covers almost all of the "modern JS syntax". If you aren't using custom transforms you might not be transforming anything that matters in Babel in 2021. I've seen a bunch of projects with huge Babel pipelines where the only actual transform was Typescript's type removal and at that point, if your codebase is entirely Typescript, Typescript has all the downlevel transforms you need "baked in" (and arguably a little bit cleaner and simpler to Babel's kitchen sink but also still somehow millions of plugins approach) and it's just setting Typescript's compile option to the ES level you are most comfortable with. (In 2021 that may even be as high as { "target": "es2019" } or higher in your tsconfig.json and even there Typescript's not going to even need to downlevel much.) Typescript can also transform TSX/JSX to JS without the need of Babel, if you are using React. Even ES2015 modules which some people still think is the big reason to keep Babel around: a) has full Browser support if you use type="module", but most people still want to pack their JS because just about no one is assuming HTTP/2 or HTTP/3 yet, and b) Babel has never done module format transforms, that's always been the domain of your packer (webpack, parcel, rollup, snowpack, what have you). If you are updating your project stack in 2021 right now my personal top recommendation is that I really like the approach of snowpack (https://www.snowpack.dev/ https://www.snowpack.dev/): ES2105 modules with <script type="module"> dev experience (which is great), great Typescript support, and a simpler overall config experience than most other options right now. (It uses esbuild under the hood rather than babel for dev and basic transforms/bundling. It can optionally piggy back webpack and parcel for Production bundling that needs more "power".) Especially that <script type='module"> dev experience feels great now (with Hot Module Reloading too) versus waiting for a full bundle even for dev builds.
- SavantIdiot 5y ago
  This is a fantastic answer. Thanks!
- porker 5y ago
  Tangential but did you evaluate Snowpack and Vite? Both seem to share the same space and I was leaning towards Snowpack, but Vite now seems to have the mindshare. Which as a small dev shop is important when betting on it for 3+ years
  - richeyryan 5y ago
    I trialed Snowpack earlier this year and found I ran into quite a lot of hard to debug issues. Around the same time I saw that Rich Harris, creator of Svelte and Sveltekit, opted to use Vite over Snowpack for Sveltekit because more things, like CSS and and SASS, just worked out of the box. I tried out Vite and it was a much smoother transition. As you said it seems to have more mindshare now and I would guess that is because the out of the box experience is better.
  - WorldMaker 5y ago
    I've not tried Vite yet. I've been happy enough with snowpack so far, and they seem so similar in approach I haven't heard a reason to switch other than yes it does seem to be the new PR "hotness". Looking at Vite's own comparison I don't see a strong reason to switch that would impact most of my projects: https://vitejs.dev/guide/comparisons.html#snowpack https://vitejs.dev/guide/comparisons.html#snowpack But also I don't use Vue and I don't trust CSS Modules yet [1] which is their other most impactful feature of Vite. ([1] It still seems like reliable Browser support for CSS Modules is still 5 years away at the current rate, if it ever gets accepted as a standard. I don't think there's any obvious current objections and few browsers outside the Chromium hegemony to even really object today, but it's still one of those web standards that smells to me pessimistically like "it's never going to work right cross-browser", and even if I were less pessimistic about it, I prefer not to use them because I think they bloat CSS and subvert the intent behind cascading. At that point I think you might as well just use CSS-in-JS and that doesn't have to wait on web standards that may never arrive.)

If Babel is outdated in 2021, what is the best practice for FE build flow? I'm thinking about updating my projects but there too many options to choose from..

by sccxy 5y ago

If Babel is outdated in 2021, what is the best practice for FE build flow? I'm thinking about updating my projects but there too many options to choose from..

SavantIdiot 5y ago

We use the JS outputted by TSC in both webpack and nuxt projects. I honestly don't know if that is bad, but I have such a small team that no one really knows. We're not Etsy-sized. :) This article drove it: https://blog.logrocket.com/why-you-dont-need-babel/ https://blog.logrocket.com/why-you-dont-need-babel/ EDIT: Plus we also wanted to go on a package diet because we found ourselves doing too much cut-and-paste from github w/o really knowing how to use all the tools.

WorldMaker 5y ago

The number of transforms that Babel is doing with an "evergreen" config ("last 2 browser versions") at this point is effectively miniscule. It's a massive toolchain for what increasing turns out to be a minimal amount of actual work. "Last 2 Browser Versions" is effectively everything through ES2019 at this point which covers almost all of the "modern JS syntax". If you aren't using custom transforms you might not be transforming anything that matters in Babel in 2021. I've seen a bunch of projects with huge Babel pipelines where the only actual transform was Typescript's type removal and at that point, if your codebase is entirely Typescript, Typescript has all the downlevel transforms you need "baked in" (and arguably a little bit cleaner and simpler to Babel's kitchen sink but also still somehow millions of plugins approach) and it's just setting Typescript's compile option to the ES level you are most comfortable with. (In 2021 that may even be as high as { "target": "es2019" } or higher in your tsconfig.json and even there Typescript's not going to even need to downlevel much.) Typescript can also transform TSX/JSX to JS without the need of Babel, if you are using React. Even ES2015 modules which some people still think is the big reason to keep Babel around: a) has full Browser support if you use type="module", but most people still want to pack their JS because just about no one is assuming HTTP/2 or HTTP/3 yet, and b) Babel has never done module format transforms, that's always been the domain of your packer (webpack, parcel, rollup, snowpack, what have you). If you are updating your project stack in 2021 right now my personal top recommendation is that I really like the approach of snowpack (https://www.snowpack.dev/ https://www.snowpack.dev/): ES2105 modules with <script type="module"> dev experience (which is great), great Typescript support, and a simpler overall config experience than most other options right now. (It uses esbuild under the hood rather than babel for dev and basic transforms/bundling. It can optionally piggy back webpack and parcel for Production bundling that needs more "power".) Especially that <script type='module"> dev experience feels great now (with Hot Module Reloading too) versus waiting for a full bundle even for dev builds.

SavantIdiot 5y ago
This is a fantastic answer. Thanks!
porker 5y ago
Tangential but did you evaluate Snowpack and Vite? Both seem to share the same space and I was leaning towards Snowpack, but Vite now seems to have the mindshare. Which as a small dev shop is important when betting on it for 3+ years
- richeyryan 5y ago
  I trialed Snowpack earlier this year and found I ran into quite a lot of hard to debug issues. Around the same time I saw that Rich Harris, creator of Svelte and Sveltekit, opted to use Vite over Snowpack for Sveltekit because more things, like CSS and and SASS, just worked out of the box. I tried out Vite and it was a much smoother transition. As you said it seems to have more mindshare now and I would guess that is because the out of the box experience is better.
- WorldMaker 5y ago
  I've not tried Vite yet. I've been happy enough with snowpack so far, and they seem so similar in approach I haven't heard a reason to switch other than yes it does seem to be the new PR "hotness". Looking at Vite's own comparison I don't see a strong reason to switch that would impact most of my projects: https://vitejs.dev/guide/comparisons.html#snowpack https://vitejs.dev/guide/comparisons.html#snowpack But also I don't use Vue and I don't trust CSS Modules yet [1] which is their other most impactful feature of Vite. ([1] It still seems like reliable Browser support for CSS Modules is still 5 years away at the current rate, if it ever gets accepted as a standard. I don't think there's any obvious current objections and few browsers outside the Chromium hegemony to even really object today, but it's still one of those web standards that smells to me pessimistically like "it's never going to work right cross-browser", and even if I were less pessimistic about it, I prefer not to use them because I think they bloat CSS and subvert the intent behind cascading. At that point I think you might as well just use CSS-in-JS and that doesn't have to wait on web standards that may never arrive.)