Hacker News new | past | comments | ask | show | jobs | submit login
React 16.4 release notes (pointer events) (reactjs.org)
85 points by threatofrain on May 24, 2018 | hide | past | favorite | 20 comments



Pointer events integrate inputs from mice, touchscreens, and pens, making separate implementations no longer necessary and authoring for cross-device pointers easier. The one input API to rule them all!

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!


> 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


Safari is the new Internet Explorer

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.


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.


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.


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.


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!


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.


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>
Would love to have this simplicity in React.


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/


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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: