News for hackers. Stuff that matters.
Re:Scheduling in React by dplgk on Thursday March 07, 2019 @02:11PM (#19331122)
I understand the need but this adds serious complexity and wouldn't recommend that this becomes the standard for UX in React. A user is often ok with a delay and it may not worth the tech debt. That said, a very well written article.
Re:Scheduling in React by onion2k on Thursday March 07, 2019 @04:25PM (#19332627)
A user is often ok with a delay...

Every user group focus test I've ever done on an app with a janky UI has brought it up as a significant "The app is so slow!" issue. On the things I build users hate UI delays.

Re:Scheduling in React by taeric on Friday March 08, 2019 @12:18AM (#19335301)
This is a tough one. If asked, most everyone will complain about delays. Just like, if asked, most people will complain about the color choice. Doesn't mean it is the best place to focus on at first.

In areas where the latency has been solved, don't make the options worse for the user. There are bare minimums, but they are usually hard to mess up. Such that, if you are bringing something new to the table, focus on that first.

Re:Scheduling in React by danabramov on Thursday March 07, 2019 @05:37PM (#19333308)
Most of the complexity is inside of React, not in the app. Your components look pretty much the same — except that you have more control over scheduling when you need to.
Re:Scheduling in React by dana321 on Thursday March 07, 2019 @06:44PM (#19333811)
React trades simplicity of certain things such as dom manipulation, and makes it difficult to fetch external (ie noncompiled) html and include it as react dom nodes, and ad serving is pretty difficult too because most ads use document.write and this paradigm doesn't work with react, as well as single page applications and the rendering of contextual advertising requires server-side rendering too.

State management solutions like redux; nobody i know or have seen does it exactly the same, its really tricky to use and takes a long time to get the hang of.

Re:Scheduling in React by symboltoproc on Friday March 08, 2019 @03:25AM (#19335993)
I have always considered React one of the frameworks that allows you to interop with regular HTML and JavaScript the easiest. The reason being that you can easily access DOM nodes and everything is run in JavaScript anyway. This is a lot more complicated in languages where you have a template language in my own experience.

That said, document.write is kind of special since it requires JavaScript to run while the HTML document is still open (so before it fires the loaded event). There is a reason this API is barely used today and mostly superset by appendChild.

Re:Scheduling in React by amelius on Thursday March 07, 2019 @06:21PM (#19333667)
> it may not worth the tech debt

Management is complaining that our website is less responsive than our competition's ...

Re:Scheduling in React by dana321 on Thursday March 07, 2019 @06:40PM (#19333788)
Responsive as in ms delay from click to action or responsive as in mobile/tablet visual scaling?
Re:Scheduling in React by philipp-spiess on Thursday March 07, 2019 @04:45PM (#19332816)
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.