Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Blocking=render: Why would you do that?

csswizardry.com

Post reply on HN
Print view View original

11–20 of 20 posts

Re: Blocking=render: Why would you do that?

#11

Post by don-code »

thanatos519 wrote: post #6

Could this be used to prevent me from clicking on or tapping the wrong thing because new items keep appearing causing a reflow just as I jab? I would really appreciate it if pages would render after they have made up their mind.

That's very much a double-edged sword. Jira is probably the product I use which has the worst UX around this - fields jump around the page for 5-10 seconds when I load a ticket. That said, while the likelihood that I personally (team/tech lead) am going to edit a ticket is quite high, I imagine the rest of my team (there are more of them than me) would be suffering through 5-10 second load times just to read a ticket.

Re: Blocking=render: Why would you do that?

#12

Post by don-code »

I've noticed there's a behavior of newer React apps, to load the static text "You need to enable JavaScript to run this app" (or similar). It'd be nice if they could instead use this feature to gate rendering the page, as I assume that plugins like NoScript would be implemented to ignore it entirely and render whatever static content is there.

It'd for sure still be up to content designers to degrade gracefully.

Re: Blocking=render: Why would you do that?

#13

Post by csswizardry »

don-code wrote: post #12

I've noticed there's a behavior of newer React apps, to load the static text "You need to enable JavaScript to run this app" (or similar). It'd be nice if they could instead use this feature to gate rendering the page, as I assume that plugins like NoScript would be implemented to ignore it entirely and render whatever static content is there. It'd for sure still be up to content designers to degrade gracefully.

This, generally, is avoidable hand-over-fist. `NoScript` isn’t a plugin—it’s older than most web developers.

Re: Blocking=render: Why would you do that?

#14

Post by fevangelou »

Once ad agencies/networks take note of this feature, they will 100% start using it and abusing it.

We're already seeing some ad networks using initialization scripts to bootstrap their ad setup, with dynamically constructed secondary scripts that have a high fetchpriority (so they supposedly load faster than others).

For reference, modern news/media sites may load multiple ad networks (3-4 on average perhaps) in order to optimize ad performance (revenue) or inject different kinds of ads or sponsored content. If we take Google's Ad Manager (or similar) as the base network to serve ads (own or third-party), many times we see additional networks like AdSense, Taboola, Outbrain, Vidverto (to name a few) or other local ad networks that do some sort of header bidding, ad injection, sponsored content display, in-read ads/videos and so on.

I don't see why some won't abuse this spec to force-inject their stuff earlier than other ad networks and of course at the expense of a site's performance...

Re: Blocking=render: Why would you do that?

#17

Post by daelon »

don-code wrote: post #11
thanatos519 wrote: post #6

Could this be used to prevent me from clicking on or tapping the wrong thing because new items keep appearing causing a reflow just as I jab? I would really appreciate it if pages would render after they have made up their mind.

That's very much a double-edged sword. Jira is probably the product I use which has the worst UX around this - fields jump around the page for 5-10 seconds when I load a ticket. That said, while the likelihood that I personally (team/tech lead) am going to edit a ticket is quite high, I imagine the rest of my team (there are more of them than me) would be suffering through 5-10 second load times just to read a ticket…

How is it justifiable for jira tickets to take 5-10 seconds to load in the first place?

Re: Blocking=render: Why would you do that?

#18

Post by Woshiwuja »

daelon wrote: post #17
don-code wrote: post #11

Earlier quoted context omitted.

That's very much a double-edged sword. Jira is probably the product I use which has the worst UX around this - fields jump around the page for 5-10 seconds when I load a ticket. That said, while the likelihood that I personally (team/tech lead) am going to edit a ticket is quite high, I imagine the rest of my team (there are more of them than me) would be suffering through 5-10 second load times just to read a ticket…

How is it justifiable for jira tickets to take 5-10 seconds to load in the first place?

The company bought the Jira dildo and now is forced to jump on it

Re: Blocking=render: Why would you do that?

#19

Post by psd1 »

daelon wrote: post #17
don-code wrote: post #11

Earlier quoted context omitted.

That's very much a double-edged sword. Jira is probably the product I use which has the worst UX around this - fields jump around the page for 5-10 seconds when I load a ticket. That said, while the likelihood that I personally (team/tech lead) am going to edit a ticket is quite high, I imagine the rest of my team (there are more of them than me) would be suffering through 5-10 second load times just to read a ticket…

How is it justifiable for jira tickets to take 5-10 seconds to load in the first place?

My friend, I've worked in a Remedy system where tickets would routinely take over a minute to load.

Senior management keeps buying shit, so shit is what the market offers.

Re: Blocking=render: Why would you do that?

#20

Post by ycombinatrix »

don-code wrote: post #12

I've noticed there's a behavior of newer React apps, to load the static text "You need to enable JavaScript to run this app" (or similar). It'd be nice if they could instead use this feature to gate rendering the page, as I assume that plugins like NoScript would be implemented to ignore it entirely and render whatever static content is there. It'd for sure still be up to content designers to degrade gracefully.

>"I've noticed there's a behavior of newer React apps, to load the static text "You need to enable JavaScript to run this app" (or similar)."

There's an HTML "" tag that works perfectly well...

Post reply on HN