4 ms·

If one wants to do a "Masonry" layout, what's wrong with calculating it via JavaScript?

by mg 2y ago

xrisk 2y ago
I’d rather have browser vendors responsible for a correct implementation. This seems like a rather nuanced feature.
- jampekka 2y ago
  With browser vendors you have to get them to do the same implementation. With JS/WASM it'll work across browsers given the more fundamental APIs work the same.
tambourine_man 2y ago
It’s less smooth, uses more power, requires more bandwidth, etc.
nolok 2y ago
You're asking "why render it correctly when we can render it wrong and then fix it afterwards".
- datascienced 2y ago
  An argument I would take more seriously if infinite scrolling was not a requirement too.
isodev 2y ago
Because why introduce a custom abstraction to implement something with an imperative scripting language when you can achieve the same result with a declarative language built specifically to address this use case? You'd rather maintain all the maths and JS dependencies for this than have browsers just render what you want?
- pavlov 2y ago
  It’s been nearly 30 years now that we’ve heard this refrain about CSS. Somehow the dream of “just tell the browser to render what I want” still remains elusive. But maybe it’s just a few dozen more properties and mini-DSLs away this time! Pay no attention to those sirens and false prophets who still believe in anti-CSS “tell the computer how to do exactly what you want” programming…
  - isodev 2y ago
    I'm no prophet and CSS, just like any other language has its quirks. And yeah, generally it is my job to try and tell computers what to do so I like powerful tools that let me do what i want :)
    - pavlov 2y ago
      You’re missing the irony in the second paragraph. CSS proponents are ideologically opposed to simply telling the computer how to do what you want.
      - sham1 2y ago
        Well, as far as I at least understand it, the argument is that by using JS for this, you are indeed telling the computer what you want, you're just doing it by telling the computer it by telling it exactly how to do it. In contrast, in CSS, you're telling the computer what you want by… telling it what you want, and letting the browser engine worry about the how. CSS isn't perfect, but it certainly works nicely for declaring layouts most of the time. It's of course alsp easy to get wrong, but doing all of the layout logic manually doesn't seem like a proper solution.
      - jampekka 2y ago
        I agree that there should be an "escape hatch" to implement stuff that evaded the great wisdom of the commitees. The Houdini project may become such: https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Houdini https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Houdini But I do also see the benefit of a declarative system for most cases. Adaptive layouts are hard to do with imperative code, and very easily lead to e.g. infinite loops, so it's nice to work with a declarative system that guarantees a stable layout. That said, CSS is far from an ideal such system with so much ad-hoc and legacy baggage.
jampekka 2y ago
It'll probably end up slow and buggy. And likely explode when used with other layouting mechanisms. And it won't benefit from the quite awesome CSS debugging tools we have nowadays. But yes, more powerful "client side" layouting functionality would be very welcome so we wouldn't have to wait the commitees for a decade to center an element etc. And there is the "Houndini" project to get this going, but the browser support is still extremely poor: https://houdini.glitch.me/ https://houdini.glitch.me/
deleted 2y ago
[deleted]
iainmerrick 2y ago
The main problem is that JS runs in a single thread and blocks the browser. Browsers jump through a ton of hoops to do scrolling and rendering on background threads while still allowing JS hooks and callbacks as required by web standards. But, I think it's really the ONLY problem, and if you solve that problem, doing this stuff in JS would be the right answer. You'd be much more likely to get consistent behavior everywhere, without browser-specific quirks. And part of the solution exists already! JS doesn't have to block the main thread any more, because you have things like Web Workers and WebAssembly. Rather than adding another specific layout type, we should add a general-purpose way of hooking into the layout engine from a background task. Update to add: just saw from another comment in this thread that there's already an effort underway to do this, called Houdini: https://news.ycombinator.com/item?id=40130487 https://news.ycombinator.com/item?id=40130487 Cool!
- mmis1000 2y ago
  You can actually make a working masonry layout with css alone(even make it work with browser resize), if you do know the aspect ratio of each item. The hard part is handling the column count change and item prepend/insert because that would always require js to do.(since tha would change the position and column of every item) There is no logic of js required to do handle whatever screen resize. https://codepen.io/mmis1000/pen/gOyZJqE https://codepen.io/mmis1000/pen/gOyZJqE
rezonant 2y ago
There is no reasonable fallback when JS is not present or hasn't yet executed, and that's not acceptable. I can't stress enough how important this is for content experiences. Your content must display reasonably before all bells and whistles load, and when the bells and whistles load, your content had better not shift dramatically (ideally not at all).
- sebzim4500 2y ago
  I would expect most browsers that aren't running JS do not properly handle state of the art CSS extensions.
  - rezonant 2y ago
    Such browsers can also get by based on the semantic ordering of content within the document, which will more closely match the visual reality when a masonry type layout is used. The alternative of defining several columns leads to at least one column being shoved all the way at the end of the document after the previous column, whereas in a masonry layout that wouldn't be the case. This is where a proper solution to this problem shines: After all, when you are on mobile (at least 60% of your users), they will get a single column anyway. Any solution that doesn't solve for them is a nonstarter. That being said, it is the slow loading of JS and the folks using truly modern browsers with JS turned off that are more common, and for those people this isn't a problem.
    - jampekka 2y ago
      JS masonry libraries, e.g. masonry.js, can and typically do use the HTML for the content and just lay it out similarly to what CSS does.
      - rezonant 2y ago
        But the screen size is an important part of how the library will lay out the bricks, and that isn't known until JS runs (this can kind of be done with client hints, but not on initial page load)
greasyphalanges 2y ago
By doing it in CSS you eliminate the need to re-render your DOM and make your JavaScript do more useful tasks, and make your website more resilient to scripts crashing, freezing, or being disabled by the user. Also, one would think that a pipeline of JavaScript + rendering engine falls short to a more direct solution, as browsers cheat by not using JavaScript ;)

If one wants to do a "Masonry" layout, what's wrong with calculating it via JavaScript?

by mg 2y ago

If one wants to do a "Masonry" layout, what's wrong with calculating it via JavaScript?

xrisk 2y ago

I’d rather have browser vendors responsible for a correct implementation. This seems like a rather nuanced feature.

jampekka 2y ago
With browser vendors you have to get them to do the same implementation. With JS/WASM it'll work across browsers given the more fundamental APIs work the same.

tambourine_man 2y ago

It’s less smooth, uses more power, requires more bandwidth, etc.

nolok 2y ago

You're asking "why render it correctly when we can render it wrong and then fix it afterwards".

datascienced 2y ago
An argument I would take more seriously if infinite scrolling was not a requirement too.

isodev 2y ago

Because why introduce a custom abstraction to implement something with an imperative scripting language when you can achieve the same result with a declarative language built specifically to address this use case? You'd rather maintain all the maths and JS dependencies for this than have browsers just render what you want?

pavlov 2y ago
It’s been nearly 30 years now that we’ve heard this refrain about CSS. Somehow the dream of “just tell the browser to render what I want” still remains elusive. But maybe it’s just a few dozen more properties and mini-DSLs away this time! Pay no attention to those sirens and false prophets who still believe in anti-CSS “tell the computer how to do exactly what you want” programming…
- isodev 2y ago
  I'm no prophet and CSS, just like any other language has its quirks. And yeah, generally it is my job to try and tell computers what to do so I like powerful tools that let me do what i want :)
  - pavlov 2y ago
    You’re missing the irony in the second paragraph. CSS proponents are ideologically opposed to simply telling the computer how to do what you want.
    - sham1 2y ago
      Well, as far as I at least understand it, the argument is that by using JS for this, you are indeed telling the computer what you want, you're just doing it by telling the computer it by telling it exactly how to do it. In contrast, in CSS, you're telling the computer what you want by… telling it what you want, and letting the browser engine worry about the how. CSS isn't perfect, but it certainly works nicely for declaring layouts most of the time. It's of course alsp easy to get wrong, but doing all of the layout logic manually doesn't seem like a proper solution.
    - jampekka 2y ago
      I agree that there should be an "escape hatch" to implement stuff that evaded the great wisdom of the commitees. The Houdini project may become such: https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Houdini https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Houdini But I do also see the benefit of a declarative system for most cases. Adaptive layouts are hard to do with imperative code, and very easily lead to e.g. infinite loops, so it's nice to work with a declarative system that guarantees a stable layout. That said, CSS is far from an ideal such system with so much ad-hoc and legacy baggage.

jampekka 2y ago

It'll probably end up slow and buggy. And likely explode when used with other layouting mechanisms. And it won't benefit from the quite awesome CSS debugging tools we have nowadays. But yes, more powerful "client side" layouting functionality would be very welcome so we wouldn't have to wait the commitees for a decade to center an element etc. And there is the "Houndini" project to get this going, but the browser support is still extremely poor: https://houdini.glitch.me/ https://houdini.glitch.me/

deleted 2y ago

[deleted]

iainmerrick 2y ago

The main problem is that JS runs in a single thread and blocks the browser. Browsers jump through a ton of hoops to do scrolling and rendering on background threads while still allowing JS hooks and callbacks as required by web standards. But, I think it's really the ONLY problem, and if you solve that problem, doing this stuff in JS would be the right answer. You'd be much more likely to get consistent behavior everywhere, without browser-specific quirks. And part of the solution exists already! JS doesn't have to block the main thread any more, because you have things like Web Workers and WebAssembly. Rather than adding another specific layout type, we should add a general-purpose way of hooking into the layout engine from a background task. Update to add: just saw from another comment in this thread that there's already an effort underway to do this, called Houdini: https://news.ycombinator.com/item?id=40130487 https://news.ycombinator.com/item?id=40130487 Cool!

mmis1000 2y ago
You can actually make a working masonry layout with css alone(even make it work with browser resize), if you do know the aspect ratio of each item. The hard part is handling the column count change and item prepend/insert because that would always require js to do.(since tha would change the position and column of every item) There is no logic of js required to do handle whatever screen resize. https://codepen.io/mmis1000/pen/gOyZJqE https://codepen.io/mmis1000/pen/gOyZJqE

rezonant 2y ago

There is no reasonable fallback when JS is not present or hasn't yet executed, and that's not acceptable. I can't stress enough how important this is for content experiences. Your content must display reasonably before all bells and whistles load, and when the bells and whistles load, your content had better not shift dramatically (ideally not at all).

sebzim4500 2y ago
I would expect most browsers that aren't running JS do not properly handle state of the art CSS extensions.
- rezonant 2y ago
  Such browsers can also get by based on the semantic ordering of content within the document, which will more closely match the visual reality when a masonry type layout is used. The alternative of defining several columns leads to at least one column being shoved all the way at the end of the document after the previous column, whereas in a masonry layout that wouldn't be the case. This is where a proper solution to this problem shines: After all, when you are on mobile (at least 60% of your users), they will get a single column anyway. Any solution that doesn't solve for them is a nonstarter. That being said, it is the slow loading of JS and the folks using truly modern browsers with JS turned off that are more common, and for those people this isn't a problem.
  - jampekka 2y ago
    JS masonry libraries, e.g. masonry.js, can and typically do use the HTML for the content and just lay it out similarly to what CSS does.
    - rezonant 2y ago
      But the screen size is an important part of how the library will lay out the bricks, and that isn't known until JS runs (this can kind of be done with client hints, but not on initial page load)

greasyphalanges 2y ago

By doing it in CSS you eliminate the need to re-render your DOM and make your JavaScript do more useful tasks, and make your website more resilient to scripts crashing, freezing, or being disabled by the user. Also, one would think that a pipeline of JavaScript + rendering engine falls short to a more direct solution, as browsers cheat by not using JavaScript ;)