-
-
Notifications
You must be signed in to change notification settings - Fork 2.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Consider toggling vendor prefixing on/off (stylis v3) #719
Comments
@thysultan Is there any upside or downside to checking which CSS properties are supported in the runtime? I don't think we had a discussion about this before, but please link it if I'm wrong 😄 |
So I've benchmarked this and it turns out it's fortunately not slow, but still, since it's O(n), we wouldn't want it in prod. Also the parsing of CSS outside of Stylis with a middleware would make this slower.
The big problem is: If we'd add this to development only, then we risk inconsistencies in prod. |
Whats the reason you would even think of adding this in dev only?
|
Adding this to the runtime will make things slower. It's a question of how much slower, but at the same time we're trying to make v2 faster, so that's a conflict. As mentioned, checking for a property runs with: We'd want to cache this to get rid of unnecessary DOM access and speed things up. Without thinking about setting a property, getting one out of 10,000 runs with: This is most certainly not going to be faster, than the v8 optimised pattern matching and vendoring in stylis. Thus one argument is definitely performance. The second part is that there's literally no reason to add this to production. The only argument is: It's a nuisance to some. So, that means in production this argument doesn't matter, since you wouldn't look and edit the styles in prod that often. It's really something you can live with there. But then, if we'd only add this to development, if something goes wrong, or there's an inconsistency in an older / more unpopular browser (And, oh boy, there will be), then this either breaks in development, or it will produce inconsistencies. |
You are measuring Furthermore, I don't know how you are benchmarking this. Have you cached the check of a specific style property existence?
What "v8 optimized pattern matching"?
The main argument (as you said yourself) is consistency between development and production environments.
Right. |
Not to mention that the problem would not exist at all if the parser did not add these vendor prefixes in the first place without checking if the environment requires it. |
Yeah, I'm sure @thysultan and @mxstbr have more to add about this decision. If we'd do this, it'd be an extra check + cache on top of what stylis is already doing, I assume. What they'd remove is a simple check of whether a property has to be vendored, which I assume is faster than a DOM API / memory access from a cache-object. I'm only laying out some arguments here, maybe you could do the same, because I do not believe that this is really sth that will resonate with people:
As for this:
I'm pretty sure we can assume, that the browser parsing some CSS properties is not a bottleneck. So at the end of the day I'd love to have more input from multiple people, and less passive aggressiveness, because I really want more of that in my life, right 😉 |
Yes, the browsers css parser will probably never be the bottleneck, it's working on a much lower level than any javascript you can write, apart from that doing the check adds an unknown complexity of consistency and correctness since SSR is supported. |
Hey folks - just wanted to chime in regarding DX. I'm building an application that targets Electron (essentially I'm only building for the /very/ latest version of Chromium), and I'd really like if I could turn off all vendor prefixing. I don't need it and it makes things look messy in the inspector, and harder to change at runtime (because removing a property causes Chrome to fall back to it's second choice prefixed property.) |
Yeah I could see an argument for using a prefixless version of stylis, but
Phil is 100% correct the complexity of runtime CSS feature detection is far
greater than the benefits. If you look at inline-style-autoprefixer you see
the size difference between browser-specific-prefixes and
all-prefixes-all-the-time.
Yes it's a nuisance but not one that justifies extra complexity
…On Sat, 22 Apr 2017 at 8:43 am Ben Gotow ***@***.***> wrote:
Hey folks - just wanted to chime in regarding DX. I'm building an
application that targets Electron (essentially I'm only building for the
/very/ latest version of Chromium), and I'd really like if I could turn off
all vendor prefixing. I don't need it and it makes things look messy in the
inspector, and harder to change at runtime (because removing a property
causes Chrome to fall back to it's second choice prefixed property.)
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#719 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AABa4L93eQb59GngUl0ZoM_YZ5ecdmK_ks5ryTEVgaJpZM4NC-S4>
.
|
Not sure what code you are referring to. A check of whether a property is supported by a browser is literally a single condition ( |
IMO the ideal would be to let devs turn off the prefixing if they want during development. Otherwise tweaking values in Chrome devtools is a total pain. |
something like |
@gajus it's not irrelevant, generating exactly the same output on the server and client is super important. Not least for rehydration purposes. As I already said, I do like the idea of allowing all prefixes to be turned off in the case of Electron or, just for convenience during dev. Not a fan of @geddski's API suggestion—we've had a long-running battle in SC about how we could expose any configuration like this, and have so far settled on using different entry points So yeah, no-prefix mode is on the roadmap, not sure when I'll get to it, but you'll just have to live with them for the moment. |
@geelen glad to hear it! Yeah imports isn't ideal because you'd either have to change them every time you ship or have dynamic imports which could be tricky. I've seen a lot of libs have users add an entry in their webpack config file, seems like it could be a good place for it. |
Hi. On/off prefixing is a good thing, but what about target browsers setting? |
@SanichKotikov stylis doesn't support changing the targeted browsers, and it just prefixes everything down to IE8+ etc |
Does HMR solve this DX problem? |
@matt-erhart why should it solve the DX problem? |
One of the main DX complaints is they can't do live editing of css in chrome. Doesn't HMR accomplish the same thing, i.e. instant feedback of changes like that? |
HMR is a pipedream |
I'm working on electron app and don't need vendor prefixed whatever development and production. |
This will land in V3 of stylis that s-c could potentially use, though it is only a on/off option. |
I want to put my two cents in this discussion: I agree that prefixes are messing with the DX, if you want a quick way to tweak styles in DevTools it is a pain to enable/disable some prefixed styles. HMR solves this problem, but recompile process could be quite slow on big projects, so it is a solution, but not ideal. If stylis would support disabling prefixes it would be very nice to have this as an opt-in option in styled-components. Overall styled-components are already ~= great DX, so our team would still happily use it without this fix for prefixes 😸 |
Thats what I thought before I started experimenting. It turns out it is smaller than a static prefixer, highly performant for 2 reasons:
The biggest challenge was the consistency with server-side rendered prefixes, which is hopefully soon getting fixed. |
I love your idea of adding only browser spesific prefixes and caching. It will reduce props size comparing to the current solution and caching will minimize extra complexity as much as possible. Definitely +1 from me But there is one thing. As I said any The more I think about this issue the more I understand that I hope that will happen one day. But for now implementation of your solution inside styled-components can bring huge performance optimization |
In respect to stylis, i see this as more of a DX problem than a performance one since the stylis prefixer is already very fast, which might mean that adding additional config to tailor for specific/exact vendor prefixes might regress its perf(though largely marginal) than improve it when it comes to runtime perf. |
@thysultan stylis code is hard to read, how do you detect which prefix to add, whats the logic? |
Hi @thysultan I do not favor adding any extra logic to runtime. Moreover, I wonder why would you add into runtime things which can be covered on the build stage
It doesn't mean that it couldn't be even faster and more lightweight, right? But basically, I've just wanted to ask if there are any plans relating to the creation of transpiler, which will remove from runtime things that shouldn't be there and will bring great performance boost P.S. Regarding benchmarks. I think they are not valid since you are comparing the thing, which works in runtime, to preprocessors, which compile code on a build stage. It will be great to see the comparison between |
@kof It compares a hash of the first three character codes of a property name instead of the property name string. |
Compares what with what? Can you give a simple example that illustrates the logic? How do you decide if property needs a prefix? |
For example to prefix We have the first three character codes Edit: This is only for property vendor prefixing, prefixing something like a |
@kof thanks for linking to that prefixer. Maybe we can come up with a combination with the planned standard. For everyone, generally discussing this right now doesn't make a lot of sense since we're working on a universal preprocessing pipeline that'll work both, during a build step, or in the runtime. One thing that's important is that SSR works correctly. But anyway, once we have this stuff in place it should be easy to discuss customisations for the css pipeline This means that how we're currently dealing with parsing css will change dramatically. |
@philpl great to hear! Universal pipeline sounds promising. In such case, I will proceed with the |
Just raised this to continue the discussion re: universal pipeline: cssinjs/istf-spec#24 |
Just to point out, this problem is not just a matter of aesthetics. Unwanted prefixes are a footgun: if you click to disable a property in the devtools, the browser may quietly fall back to some prefixed property. If you fail to notice this, it can lead to minutes or hours of pointless layout debugging. And even when you do notice it, it's painstaking to make sure you catch each potential fallback property and disable them all. It's effectively not even worth using this feature of the devtools, as it's easier to make the change in your code and wait for it to rebuild and then change it back again. |
I need to generate a css file and I'd love not having the prefixes. I'm building a PDF generator using python library weasyprint who doesn't care about prefixes. |
- styled-components#719 - this is implemented using `process.env`, though we could implement it many other ways, since stylis is instantiated immediately, this is the most straight forward & minimal way to achieve the feature, and will have no performance impact if a bundler defines the env & dead code elimination takes place - a test suite for stringifyRules is created - two test cases are added, both of them use jest.resetModules() to ensure the stringifyRules file is evaluated with the updated process.env, only for this test case 1. to check the default functionality (having prefixes) 2. with the `STYLIS_SHOULD_PREFIX` env set, expect that there are no prefixes - teardown/afterAll ensures the process.env is reset
Joining party. Initially thought it was webpack causing all those prefixes - but ended up here, and reason why I see prefixes are actually styled componnets. Adding my points. For development:
For production:
Would be really helpful turning prefixes off - or setting to add only most important and not prehistoric ones, as at least most of our users, are already using recent desktop browsers - and if not we are forcing them by popup to update. |
+1 to this. Not only that, but this can also lead to bugs with things that are incorrectly implemented / missing in Stylis, such as |
you can now use |
Looks like Stylis v4 will have a prefix for |
|
Aren’t there some that could still be relevant? |
This is regarding
2.0.0-15
.Using flex boxes results in:
There is absolutely no reason to add these... and it is likely a performance hit (processing unknown CSS properties is just another cycle).
There is a boolean way to check whether a property is supported in the browser. See Verou's article http://lea.verou.me/2009/02/check-if-a-css-property-is-supported/.
Possible performance issues aside, it is a nuisance from the DX perspective (as visible in the screenshot).
The text was updated successfully, but these errors were encountered: