Comments (15)
First, how would the implementation be easier? I'm trying to get at if it's generally difficult to implement or because of multiple file dependencies.
Second, if you want a version without media.js, picturefill is the other option I know of. I know you've created a demo using that as well. I would say speed is the biggest difference. In performance tests, picture was faster, in part that speed is due to Media.parseMatch's ability to parse media queries.
Is there something you like about picture that you don't about picturefill and vise versa or are both implementations lacking?
Let me know how I can help.
from picture.
The 'problem' is that there's already a poly fill for matchmedia in Drupal 8 core, so if we add this picture solution to core we need to rewrite a lot of other core code, and that will be hard to defend.
The thing I like about this solution is that images are only loaded once.
The other solution is to rewrite media.js as well so it uses the same interface as matchmedia, but I have to think some more about this :-)
from picture.
"rewrite media.js as well so it uses the same interface as matchmedia"
See line 255 of media.js window.matchMedia || (window.matchMedia = Media.match);
media.js already supports the native matchMedia interface. Unlike matchMedia.js, media.js supports addListener like the spec does (triggered on match and unmatch) and on resize mql.matches will change from true to false and vise versa as native does.
Addition:
@WickyNilliams has created a pull request that would fix the match/unmatch scenario paulirish/matchMedia.js#28
from picture.
I'll try to have a look at the code tomorrow, it's getting late over here.
from picture.
Ok, thanks for hanging in there. I appreciate you trying to make this work.
from picture.
Yeah, @knightdr has already been very accommodating to an earlier request of mine to match (no pun intended) the matchMedia API :)
I've not looked into the this particular project yet so correct me if I'm off the mark... From an outsider's perspective I think it should just rely on the matchMedia API rather than any specific implementation of it (in this case media-match). That way, any polyfill can fit the bill, and the end consumer is given the power to decide which (if any!) polyfill to utilise.
from picture.
Hmm. You and your thoughts @WickyNilliams.
You're making some sense. Your sense will require me to do a little re-think on how picture (https://github.com/weblinc/img-srcset and https://github.com/weblinc/nonresponsive) is currently implemented. I'm using Media.parseMatch because it can return the media query it matched on. I'm using the query as the property name where the value is the src of the img to load. It also bypasses the need to store the query list object in an array like Media.match does.
from picture.
@WickyNilliams that's what I meant
@knightdr I think it would be possible to split media.js in 2 parts, one the polyfill and a new one that extends matchMedia with the features and parseMatch so it can still be used by picture.js
from picture.
@attiks
I guess I was being simple when thinking that the performance increase would be enough of a reason to switch from other polyfills. Looking over the jsPerf, media.js is 700+ times faster than matchMedia.js. When looking at devices with slower processors it's 1,000+ times faster.
So when I created the other plugins, again my thought was "wow, this is way faster and it's used in picture, img-srcset and nonresponsive". Basically eliminating the need to choose because it's so much faster. Since, media.js supports the native API, I didn't see an issue.
I don't see how media.js could be split but I'm open to talking about it.
from picture.
@attiks apologies, I was concurring with your sentiment and adding some further reasoning.
@knightdr I have a lot of thoughts, most of them crap, but I think this one was worthwhile :)
As for your reasoning above, I think the end consumer should still have the decision. Some people may favour file size (the classic polyfill) over speed (your polyfill) and it's ultimately something that you should not dictate by inclusion. Others may not even care about polyfilling older browsers, another reason why it should be an optional include rather than a hardcoded dependency. I spent a long time thinking about this with enquire, which is why I did not include any polyfill in the codebase, leaving the decision the user.
from picture.
I guess this is why I'm paying you the big bucks, these thoughts.
The only reason I personally would want to continue development on "picture" is if it added something to the community. If I follow your argument down the path as I see it then I would come to the conclusion that I should focus my efforts on forking picturefill.js rather than this project. If I add matchMedia into picture then it's really a slight difference from picturefill.js. Currently I see this project as more of a departure even though they both strive to achieve the same end.
from picture.
What do you think of "picture" becoming a plugin to Media? So it could be Media.picture to show that these efforts are linked and then I think it's less of an issue that "picture" uses Media specific implementation. Too much fragmentation of picture like functionality? I would then see if I could improve picturefill.js performance.
from picture.
@WickyNilliams @attiks ,
I've just released v2.0.0 of this project. Thought you would be interested. I've removed the dependencies as we discussed. This version is different enough and performant enough at the moment to be a separate repo from picturefill.js. If this performs well, maybe it can be folded in to picturefill or at least share some of the concepts. After all, picturefill has a much greater awareness.
I'm closing this one out now.
from picture.
I'll check this out when I have some time (tomorrow most likely). Thanks for the update David
from picture.
Fantastic Nick, I appreciate any feedback. Same hourly as before, right? ;)
from picture.
Related Issues (6)
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from picture.