React 16.4 release notes (pointer events)(reactjs.org)
reactjs.org
React 16.4 release notes (pointer events)
https://reactjs.org/blog/2018/05/23/react-v-16-4.html
23 comments
> making separate implementations no longer necessary
Until you actually start to implement gesture disambiguation and realize that pointer events are useless [1][2]
1. https://github.com/w3c/pointerevents/issues/178
2. https://github.com/w3c/pointerevents/issues/216
Until you actually start to implement gesture disambiguation and realize that pointer events are useless [1][2]
1. https://github.com/w3c/pointerevents/issues/178
2. https://github.com/w3c/pointerevents/issues/216
there are any number of pointer events polyfills (https://www.google.com/search?q=pointer+polyfill). it's not react's fault. this feature will still be there if/when safari gets with the program!
Safari is the new Internet Explorer
https://www.safari-is-the-new-ie.com/
https://www.safari-is-the-new-ie.com/
Until another browser implements proper tail calls as per the spec, I'll still have great respect for Safari, quirks and all. It's the only browser where you can write fully functional, continuation passing style code without fear of blowing the stack.
And all the fear mongering over "it makes debugging haaard" is just frustrating. Debugging is hard, there's just no way around it.
The Develop menu in Safari is also without equal in my experience. Quick access to almost a dozen settings each of which requires either command line arguments or buried toggles and restarts in Chrome (or myriad extensions).
I do wonder why the console doesn't use a monospace font. That's not the only problem with Safari, but it's one of the most off-putting, glaring issues. Makes you feel like the browser isn't intended for serious work. Which I guess some people would say is true.
And all the fear mongering over "it makes debugging haaard" is just frustrating. Debugging is hard, there's just no way around it.
The Develop menu in Safari is also without equal in my experience. Quick access to almost a dozen settings each of which requires either command line arguments or buried toggles and restarts in Chrome (or myriad extensions).
I do wonder why the console doesn't use a monospace font. That's not the only problem with Safari, but it's one of the most off-putting, glaring issues. Makes you feel like the browser isn't intended for serious work. Which I guess some people would say is true.
They even solved the debugging complaint of TCO by having a shadow stack but to be fair chrome is way ahead in implemented JS features.
> I do wonder why the console doesn't use a monospace font
I use Safari dev tools exclusively and can report that the console does indeed use a monospace font. I wonder how you configured your setup to use otherwise.
I use Safari dev tools exclusively and can report that the console does indeed use a monospace font. I wonder how you configured your setup to use otherwise.
Any reason you prefer Safari dev tools over Chrome's?
No, it's not. It cannot be and this is extremely harmful and short sighted.
Safari does not have a monopoly on either Desktop or Mobile. Safari while behind does not implement its own broken standards and force them upon everyone. It doesn't allow for semantically broken HTML and simply "fixes it."
I'm not trying to be ageist here, but I often find this rhetoric from people who are too young to have actually worked with IE 4-6.
Safari does not have a monopoly on either Desktop or Mobile. Safari while behind does not implement its own broken standards and force them upon everyone. It doesn't allow for semantically broken HTML and simply "fixes it."
I'm not trying to be ageist here, but I often find this rhetoric from people who are too young to have actually worked with IE 4-6.
At the time IE6 was released it was easily best browser and many many of the standards that we now take for granted (DOM events on every tag, AJAX, etc) were started with IE. Now what followed that was years of stagnation just like we're starting to see with Safari.
Safari is the exclusive platform browser for iOS; even Microsoft didn't prevent you from installing alternative browsers! So in that way, Mobile Safari is even worse. From there, everything else follows: developers simply cannot afford to ignore Safari, despite its flaws, just like they couldn't afford to ignore IE despite its flaws.
Safari is the exclusive platform browser for iOS; even Microsoft didn't prevent you from installing alternative browsers! So in that way, Mobile Safari is even worse. From there, everything else follows: developers simply cannot afford to ignore Safari, despite its flaws, just like they couldn't afford to ignore IE despite its flaws.
I'm just excited for https://reactjs.org/blog/2018/03/27/update-on-async-renderin... , and curious to see how it works in our code.
It's going to be interesting to see how this plays out. It's an enormous effort on their part, and for the users with all the API changes.
But Dan's "Beyond React 16" demo simply was not compelling at all for me. With the focus on latency but no mention of bandwidth, it's really hard to understand the full impact on mobile devices. With TCP, throughput decreases as latency increases. Queue up too many requests, and the UI will get more disconnected, not less. Anyone that has had to work on an image gallery knows this all too well. Then you have SSR, and promises from render() that potentially swallow errors... lots of unknowns here.
If all these efforts turn into a wash, or at best a subtle improvement at a cost of relearning React... people are going to be asking if it was worth it.
But Dan's "Beyond React 16" demo simply was not compelling at all for me. With the focus on latency but no mention of bandwidth, it's really hard to understand the full impact on mobile devices. With TCP, throughput decreases as latency increases. Queue up too many requests, and the UI will get more disconnected, not less. Anyone that has had to work on an image gallery knows this all too well. Then you have SSR, and promises from render() that potentially swallow errors... lots of unknowns here.
If all these efforts turn into a wash, or at best a subtle improvement at a cost of relearning React... people are going to be asking if it was worth it.
Absolutely ! Any news on that btw ?
the Suspense PR was merged in for this version (https://github.com/facebook/react/commits/master?after=fa7fa...) so you can absolutely start trying it out in 16.4. with the requisite warnings that it is still unstable. I keep a repo of all publicly discussed stuff on async react here: https://github.com/sw-yx/fresh-async-react for people's research convenience.
I think these commits were taken out of the release. At least I couldn't find them when I took a quick look: https://github.com/facebook/react/commits/v16.4.0
it was merged from acdlite's branch. look harder :)
Great release. I am still desperately waiting for passive/once events support though. VueJS integrates them in a trivial way:
<div v-on:scroll.passive="onScroll">...</div>
The pointer events contribution comes from PSPDFKit, a company that sells PDF SDKs for mobile, desktop and web. It's used in https://pspdfkit.com/web/
[deleted]
A curated list of awesome React Components & Libraries:
https://reactjsexample.com/
In the grand scheme of things this sounds like one of the more boring version bumps but I'm sure a lot of people are going to be really excited about this.
Except... of course Pointer Events doesn't work in Safari. Safari doesn't even support the regular mouse event "buttons" property which has been in the specs forever, which is a constant source of Safari specific bugs in my experience. Nothing happens when you click? Oh, you must be using Safari!
Why is input handling such a pain in the behind!