philipp-spiess

We actually ended up adding the custom animation-specific data props to all dialog specific custom elements before the release, so the group-*/dialog is no longer necessary but I forgot to update the code in the post.

I doubt that changes your mind, though.

PSPDFKit | REMOTE | Full-time | Elixir

We’re looking to hire a backend developer to join our team working on PSPDFKit for Web (https://pspdfkit.com/pdf-sdk/web/).

We are building a modern PDF SDK with technologies like Elixir, React, PostgreSQL, Docker, and WebAssembly. Your role as a backend engineer will be to implement new features, improve the reliance of our server component, and work on scalability problems in a well-tested Elixir application.

If you're interested in working for a fully bootstrapped company, with a team all over the globe, that iterates quickly and uses a modern, pragmatic tech stack, then check out our job ad: https://pspdfkit.com/careers/backend-developer/

Your users still want feedback _as they type_. The idea of this example though is that you want to see an update as soon as possible. If you use blur, you're also deferring the updates until the timeout is over for the first time - The timeout can only be approximated and will ultimately be more keystrokes behind as if we start rendering ASAP.

There is also the other problem with debounce that was pointed out earlier: The main thread _will be blocked_ when a long running tasks is executed, no matter _when_. You mentioned that the block would happen _after_ the user type in so it would be less noticeable but this is only an approximation. If you have animations on your website that use rAF, the block will still be very visible. Also if the user continues to type.

That said, I know that this is a contrived example and it might not be used as-such in a real world application. I also think it's not comparable to your auto-saving input example that would maybe be better off with using a debounce call. I'm sure that better examples for this use case will follow.

Edit: I can recommend Dan's talk at JSConf Iceland last year. He speaks about debounce as well: https://reactjs.org/blog/2018/03/01/sneak-peek-beyond-react-...

The best approach is to always updated the input synchronously in React (in the same tick when the event is handled). If you do it in another tick, you will always have to handle race conditions. This is a problem for all input elements though, not specific to React or even the Web.

The batching effect of a debounced input is very important. Running an update for every keystroke is expensive and you only want to run it with the latest input anyway. This is why Concurrent React will make batching the default behavior.

Internally, React manages a list of updates. Whenever you trigger one, it will be added to the list but the next re-render will only start after the previous one has finished (this is of course a simplified explanation but you get the idea).

This batching gives us the best of both worlds: We start rendering as soon as we have data and don’t have “idle” time in which the UI is unresponsive (like a long debounce function) but we still batch all updates between the different renderings so that we can skip individual updates to save time.

No, that's not possible in JavaScript. The important part is that React components are lazily evaluated[1] and are not rendered as a stack. So React can render a few components and then pause for higher priority work.

As a user of the framework, you don't need to care about this though. So your mental model can be that of an interruptable function.

[1]: https://overreacted.io/react-as-a-ui-runtime/#lazy-evaluatio...

Something like this is definitely possible. For example a <div hidden> could apply all updates using a lower priority. This can be used to detect offscreen content or non-active tabs.

Keep in mind that the APIs are still WIP. I choose an example with lots of APIs on purpose.

There's a lot that can be inferred by e.g. looking at the event type or understanding semantics. I expect this to be better when the features near completion.

If you delay the artificial slowness that I added in the Text component after the rendering, it sure will be faster. The point is to simulate an expensive component tree with this.

If we keep that in (https://codesandbox.io/s/93yv4j129p), my previous comment holds true: https://news.ycombinator.com/item?id=19332577

Here is by the way a version with all artificial slowness removed: https://codesandbox.io/s/9859x0wm9p You can see that this example does not need any optimizations out of the box. This is why I added the slowness to simulate a more complex app.

It feels a bit faster, yes. The reason is that the input value is updated earlier.

The problem is, that the UI is still unresponsive when the timeouts fire which you feel if you type fast or look at the animation/fps meter.

Instead of a setTimeout, you could also debounce the two expensive updates (as I've noted in the post). This would at least make sure that they are batched so if you type fast you only need to re-render the list once.

PSPDFKit | REMOTE | Full-time | JavaScript, React, WebAssembly | https://pspdfkit.com/web

We’re looking to hire frontend engineers to join our team working on PSPDFKit for Web. We are building a modern PDF SDK with technologies like React, Flow, Jest, and WebAssembly. Our customers host the PSPDFKit for Web Docker container themselves or rely on our WebAssembly renderer.

If you’re interested in working for a fully bootstrapped company, with a remote first culture, that iterates quickly using a modern, pragmatic tech stack, check out our job posting: https://pspdfkit.com/jobs/frontend-engineer/

Have you tried enabling the experimental new WebAssembly baseline compiler in Chrome Canary?

PSPDFKit | REMOTE | Full-time | JavaScript, React, Elixir

PSPDFKit is the leading SDK for working with PDF files on Android, iOS and Web. We're trusted by Dropbox, Box and many Fortune 500 companies to take care of these tricky yet essential parts in their Android and iOS apps.

PSPDFKit for Web is our youngest product - you can see it in action here: https://web-preview.pspdfkit.com

Last year we released PSPDFKit for Web Standalone, which works completely in the browser, using WebAssembly: https://pspdfkit.com/blog/2017/webassembly-a-new-hope/

If you're interested in working for a fully bootstrapped company, with a team all over the globe, that iterates quickly and uses a modern, pragmatic tech stack, then check out our job ad: https://pspdfkit.com/jobs/senior-frontend-web-engineer/

I doubt it's up to the webkit team to make this decision. Anyway, Apple adopting would make things easier

I'd really love to see more high quality posts like this on React. Thank you for sharing the knowledge!

MVP - Most Valuable Player - even said I should say this as a hashtag, although i meant Minimal Viable Product

It's a good idea but it's easier to click the link and do the action manually instead of typing the text and click reply. So there is absolutely no gain for me in using your product.

There is a more easy way: Just name your index.html to index.php and you can use a full featured Apache Webserver.

What happend to the old post?

/agree The "Kollektiv" is nice, but not for everybody.

I like the "Not featured on Mashable". :D

Not master but the selected default branch. A dropdown or so would be nice.

Yeah, it's d3, the article says "The new GitHub graphs are built with the amazing d3 library by @mbostock".

I totally agree with you. The traffic chart is also very exciting.