Switch from Rework to PostCSS ?
Closed this issue · 16 comments
I'm thinking about that because I'm tired of having difficulties to do what I want with rework ecosystem.
Ref:
You can say I'm a maniac or something (sort of, yes) but I would like to have more control on the output, because I like when things are clean (& fast).
Plus, right now we have 3 parsings (rework -> postcss (autoprefixer) -> rework again), so benefit would be huge.
Now that postcss is using es6 (and not coffeescript) it should be easy to go forward with this project.
It should not be that hard to do that because we don't have a lot of work to do.
Postcss have a nicer API, is fast enough + we can already keep all existing tests on all plugins to create postcss-* plugins (to avoid regressions). I'm hot to handle that, using a postcss org (@ai plz tell me if it's an issue for you or not)
Here is a sort of bench based on parsing on github css https://gist.github.com/MoOx/1b0d7d2bd987e0735e0e
You will see that postcss is (on avg) 40% slower.
That being said, you need to know that rework doesn't keep at all coding style (whitespace & shit) & postcss does.
For the live playground planned on myth.io website, that would be nice to keep coding styles. And for maniac too :)
Since we are (for now) parsing 2 times with rework & one time with postcss, we will win something for sure.
Not sure if it's the best idea of the week but I want to share it with the community.
FYI if you are interested let me know, I'll add you there https://github.com/postcss
My problem with PostCSS is that the code is way more complex than Rework, for what I consider to be not much benefit. What are the use cases where keeping the whitespace in the source is useful? I could be wrong there.
@ianstormtaylor don’t forget about much better previous source map support. Autodetect, multiple sources (like in @import), etc.
What are the use cases where keeping the whitespace in the source is useful?
- Implementing a live playground that doesn't change that much what user just type
- Implementing plugins for editor that make "in place" changes.
Here are other arguments:
- got forward with each plugins (see listed issue)
- performances (2~3 times faster)
- using less deps
- for fun (just kidding)
I saw some stuff that I want to do that others are not interested (so not open to) & it make me sad.
If with myth we can work on a common effort, that would be nice.
I totally agree with @MoOx . Issues in examples should be handled by Myth. So maybe, if rework can't (or don't want to) handle that, we could use PostCSS ? By doing so, it would be more faster because we will drop 2 processing step.
It seems to be interesting, indeed.
My problems with the examples are:
- For the live playground, this is nice, but it isn't a core thing Myth is trying to solve really, so I'd only like to consider is as a nice-to-have, and not a core reason for switching.
- For the plugins that make in place changes, I don't understand how this is a good thing. The way I see it, the point of Myth is that the source doesn't have to have these prefixes. As soon as you add the prefixes to the source you actually lose value because you're bloating your code and others can't decide to unbloat it easily. Instead, the source should be browser-agnostic and the end users get to choose which augmentations they want to provide for backwards compatibility.
But the third problem is also that in general I like how clean the Rework codebase is—the main index.js is less than 100 lines long because it nicely delegates work to other modules, very much like Myth itself—and I am wary of a lot of work to change over to a codebase that is not as nicely designed.
@ianstormtaylor here I wrote, why saving outside spaces is important: reworkcss/css#20 (comment)
@ianstormtaylor those 2 arguments are clearly not a big win, that's for sure.
My main point is that we are already using postcss (through autoprefixer) & it's not likely to change soon, so why not just using only this one ?
rework codebase is essentially css module.
I just take a quicky look to postcss codebase & it seems to have small files too.
Anyway I was asking if some people where interested. It seems that people are not interested by my main points & that's not a big deal. I might work on that somewhere else :)
I just found out about postcss today. Yeah, late. Rework's custom media queries still don't work? Sounds like a dead project.
FYI, I've done a myth like based on postcss, and v1.0 has just been released http://cssnext.github.io/
Cool. Are there any drawbacks compared to myth? What does it do that postcss doesn't already do?
Just more features & less bugs. You can play with it online http://cssnext.github.io/cssnext-playground/
Here is an outdated comparison https://gist.github.com/MoOx/091143e99c6c87fa6d13 with myth 1.1.1 vs cssnext 0.3.1
Cool, I might just switch. But, I'm not sure if you answered my other question: what does cssnext do that postcss doesn't already? If fewer bugs, why not just contribute to postcss?