Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Agreed. Every time NextJS changes out their build system for speed, its users lose out on all kinds of functionality that they were depending on before.

Moving away from Babel to SWC meant we could no longer use SCSS within JSX styled components. We first switched everything to plain CSS, which was a nightmare IMHO. Now slowly switching things to SCSS modules.

Now with Turbopack, we lose that too: https://turbo.build/pack/docs/features/css#scss-and-less

"These are likely to be available via plugins in the future." Fantastic



As a performance nightmare you can't wake up from, SCSS can't die soon enough. As someone who depends on it currently though I def understand the frustration with losing support.


The new version (written in Dart of all things) seems pretty fast. The old ruby implementation was insanely slow, and the nodesass rewrite was insanely broken.

Whatever they got now though is just about perfect for me


Embedded SASS promises to be faster anyway, though still slow IMO..

There are some issues with realizing the potential though. Namely, a standard-ish CRA React app will have thousands of SCSS compilation entrypoints due to importing SCSS in individual component modules.

Lack of process reuse is causing many to see slightly SLOWER compile times. Next you have:

* Lack of tooling support: Vite?

* Need to migrate SCSS syntax

* ??

As soon as it's a free-ish upgrade with high ROI on swapping it in, I'll take it! I think SCSS is a dead-end though. Modern CSS + postcss for some CSS-Next polyfills is the way forward IMO.


Yeah, it really pains me that Sitecore is doubling down on them as the main FE framework.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: