101–110 of 129 posts
Earlier quoted context omitted.
> it's just dumping plugin config objects in an array, really not difficult Until you eject a CRA :)
Which is the cherry on top for those types of self-chastisement fetishists who willingly put themselves at the mercy of CRA ;-)
"Parcel CSS is based on the cssparser Rust crate, a browser-grade CSS tokenizer created by Mozilla and used in Firefox." Fantastic work, I believe cssparser could benefit from Parcel CSS if they contributed back.
We actually already have! I contributed hwb() color support as part of my work on Parcel CSS, and it shipped in Firefox 96! https://github.com/servo/rust-cssparser/commit/62d63fea751df...
I was just looking at Parcel a week or so ago to replace the stagnated Snowpack project for our frontend. Should I just stop trying to avoid it and just use Webpack 5, or can I actually rely on Parcel in a way I couldn't Snowpack? I just want to bundle my React app, I'm not trying to do anything special...
Parcel is becoming my go-to choice most of the time now. I’ve migrated some apps out of CRA, pure Webpack and Snowpack to it and I need to say it was incredible. Some minor issues with HMR on one of those projects I still can’t figure out. Anyway having something that works, with JSX, with TS, really fast, in just 2/3 really simple steps is amazing! You don’t even need to turn your brain on. My two cents.
Earlier quoted context omitted.
Use Vite instead, it has very nice developer experience. Webpack is a "legacy" bundler, while it is supported, is shouldn't really be used in new projects if you really value your sanity.
Webpack is under active development though, nothing legacy about it as far as I'm aware. Are you referring to abandoned third-party plugins maybe? Vite and all the other bundlers are really awesome, but Webpack's strenght - and I think this may also be the root of the issues you seem to be having with the tool - is that there's almost no magic and barely any handholding. Freedom and reliability at the cost of having…
That depends entirely on your definition of “magic”. Needing a specific incantation of seven different plugins and rules, that are often conflicting and incomprehensible, to get a basic project to build, is the same as magic to me.
I assume you mean magic == conventions or implicit behavior. I’ll take that over the Webpack mess any day.
Oh cool: https://github.com/connorskees/grass
Oh node-sass is written in C++. I wonder why they aren't shipping the code as wasm rather than using node bindings
Earlier quoted context omitted.
It won't go away, it will still be supported and used for many years, but majority of new projects today won't use it. Brief history: Rollup dramatically improved bundler plugin and ES modules situation, then came new super fast bundlers like Esbuild and finally solutions combining both like Vite. Webpack is still playing catch up with that. There is literally zero reasons to choose clunky, slow Webpack configs, whil…
> literally zero reasons What about module federation? Has any other bundler implemented that?
Earlier quoted context omitted.
This is not about elitism about terminology, but about sloppiness in using well established words in a specific context to mean something new. It happens rather frequently in the frontend world - which I’m sometimes a part of - and it’s incredibly confusing to all of us.
I write frontend code and backend code and do compiler stuff for fun and I don't find it confusing. "Compiler" means completely separate things in so many contexts that I get the general picture and always need to look deeper to truly understand. Just because it's a generic term doesn't mean anyone should not be allowed to use it IMO.
The confusing part is not calling this process compilation, the confusing part is now calling something a compiler for which the consensus previously was calling it a pre-processor. Now I started to wonder if there is something new that I wasn't aware off, like a browser support optimized binary style format that we can compile into.
Earlier quoted context omitted.
Use Vite instead, it has very nice developer experience. Webpack is a "legacy" bundler, while it is supported, is shouldn't really be used in new projects if you really value your sanity.
I seriously don't get the hatred Webpack receives. Calling it legacy when it introduced stuff like module federation is unfair to say the least. Just because a lot of people use CRA or some "zero config" bundler, or because esbuild etc are picking up momentum, doesn't mean it's bad. The documentation is actually really good IMO.
I just replaced Webpack with Vite, in a 2yo React project, with relatively standard webpack config (scss, fonts, assets copying, minify etc). I was able to remove 24 total devDependencies packages, including the whole of babel and its related ones, bunch of webpack plugins that broke our build on every packages upgrade (e.g. to Webpack 4, then again for Webpack 5) etc etc.
We now have nothing to do with babel, hard-to-understand plugins that someone added since it was solving a build error, nothing to do with webpack, just 1 almost non-existent config file, instant HMR, and 3x faster build...
I was just looking at Parcel a week or so ago to replace the stagnated Snowpack project for our frontend. Should I just stop trying to avoid it and just use Webpack 5, or can I actually rely on Parcel in a way I couldn't Snowpack? I just want to bundle my React app, I'm not trying to do anything special...
Use Vite instead, it has very nice developer experience. Webpack is a "legacy" bundler, while it is supported, is shouldn't really be used in new projects if you really value your sanity.
What a weird thing to say. I feel like people say this because they don't understand it's uses, and it's versatility.
Looking forward to an scss compiler written in Rust, compiled to wasm and exported via a node module that no longer requires node version/platform specific binaries to be either downloaded or compiled. Oh cool: https://github.com/connorskees/grass Oh node-sass is written in C++. I wonder why they aren't shipping the code as wasm rather than using node bindings
[0] https://www.npmjs.com/package/node-sass [1] https://www.npmjs.com/package/sass instead