Don't use flexbox for page layout (2014) | Hacker News Reader

Don't use flexbox for page layout (2014)

jakearchibald.com

I will be "this guy", but let me rant here. First of all, the article is 3 years old, and though he says basically truth, it is noticeable only on slow machines with a massive amount of content. Initially I was against using flexbox for page layout (for components, of course, it is the best), but after trying in real (big) applications it turned out to work perfectly. And after three years of browsers improving, this advice looks like a nonsense.

And secondly, I would like to blame these google developer advocates, which don't make sense for building applications. For instance, here they say one technology is bad, and they offer you to use another technology, which even now is still under implementation (and it is 3 years ago!), which looks absolutely ridiculous – literally the worst piece of advice you can give to someone who tries to build real software product. And it is not only this article, it is also a thing for a lot of other articles and their talks – like advice to stop using frameworks for mobile applications (I know, it is possible to get rid of JS completely and speed up your app by 500%, but there are a lot of metrics, and also nobody wants to write two separate versions), or promoting of "platform" (Polymer) against of framework. While it might work just fine for small projects, with big project you will end up writing your own routing, event system, utilities, validations, filtering, etc.

Also it is even more funny considering that they are backing Angular, which is a pretty bloated framework.

I honestly think this is just someone who dug up a 3 year old article because they are upset about flexbox in bootstrap 4.

Exactly. Their comment below:

> I was hoping people would come with more examples of things not to use flexbox for with well-reasoned arguments. I had an experience a few months ago where someone had used flexbox to vertically separate sections that could have various sizes of content that needed to have varying spacing between the content and I really felt as good as I thought the developer was Flexbox was wrong and just could not get past 80% to real completion of the design.

Like you say, the article is demonstrably true, and yes it depends on the situations clarified in the article.

My intent here is we shouldn't abandon the work on grid because flexbox is "job done". Unfortunately, yes, work on grid was slow.

Makes me giggle to see you suggest I back Angular, when I often get the Angular team saying I complain about them too much. Where have you seen me backing Angular btw?

There are a couple of really annoying aspects to this article. One, its promoting a feature (css grid) that's got very little support in practical use today over another feature (flexbox) that, while perhaps imperfect, is mostly here, now, and is worlds better than what came before. Secondly, this article is almost 3 years old and its promoting a feature that's got very little support in practical use today.

JS can be a real sh*tshow sometimes, I'll grant you. But holy effing hell, CSS, get it together. Grid systems are not a new thing. Its a travesty there's no standards-based support for them yet.

Grids should be arriving in Chrome stable in mid March

I'm not sure what you mean by that, flexbox has been supported by Chrome for a while now: http://caniuse.com/#feat=flexbox.

Sorry, I meant CSS grids! Edited original comment.

Should arrive in Firefox in early March. Also being tested in Safari.

It's coming for real and soon.

Beware the Grids of March.

Sorry that you found the age of the article annoying. I'll try and write everything closer to the present in future.

Nobody cares that your article is old, dude. They care that it was posted to HN today.

Yes, I was joking about the wording.

Please don't take it personally, I was more complaining about how slowly things evolve when the browser is the barrier. I very much enjoy your blog for knowing what's coming someday!

But in the future, the present will be the past.

I used flexbox for a site (done, not live yet) and used flexbox without noticing this problem. I did look for it, though, but even on GPRS the site loads fine, no noticeable relayout.

Perhaps the difference is that the site I redid has a geographic target, and the median page needs to load 18k of HTML, CSS and Javascript before the final page layout is complete. Retrieving 18k from a server <200km away is not a strain, retrieving an average of 4k for the second and subsequent pages even less.

The "slower connection" animation in the article is completely unrealistic to me. What is it meant to display? Loading a megabyte of Javascript and CSS before the layout is done? If so, then I suggest that there is a problem but flexbox isn't it.

Maybe add (2014) to the title?

I wish it could just be downvoted. Browser support has improved considerably since this was written.

The issues I deonstrate in the article are still valid today. In fact, they're by design.

sorry, I don't seem to be able to edit it to do this?

1995 called and said we invented all this crap years ago and all methods are all valid and needed in different situations.

http://zetcode.com/gui/tkinter/layout/

Amusingly, their grid version of the page (http://output.jsbin.com/iYEmaTUF/2) renders incorrectly for me - the content is aligned vertically as opposed to horizontally. Latest chrome / el capitan

The grid spec has changed a lot since this article was written three years ago. His example is likely incorrect now.

Also in latest Safari / macOS Sierra

HN still uses <table> .. and it works great.

I've been idly thinking about starting a list of 'cargo cult development ideas' - more specifically things that make sense or made sense in a specific domain but got passed around and became detached from their original intent.

There's a related idea that interests me - ideas that were useful mainly for killing something else. These two things overlap somewhat.

1. "Don't use tables for layout" - helped kill the most horrific era of web-design which was largely based on slicing large photoshop images into parts and reconstructing them in html tables. Responsive design would never have been possible if this practice hadn't have been vanquished. The actual arguments for not using tables for layout were much more nuanced and in some places - just wrong. In particular the arguments based on tags having semantic value were laughable when you consider that in most cases we just replaced table/tr/td with div/div/div.

2. REST. Most APIs are still only an approximation of 'true' REST - or just kind of cheating and sticking in some RPC-style endpoints when the going gets tough. The promise of machine to machine API usage without developer intervention is yet to be realised. However - REST stopped SOAP from taking over the world and for that we must be eternally thankful.

3. "Separate content and presentation (HTML/CSS)". Similar to (1) - this was based around a core truth about separation of concerns and maintainability. However it became a mantra rather than just one specific way you could attempt to reduce coupling and create less brittle markup. But it was easy to explain and easy to argue for and it stopped a lot of bad practices.

I had a few more but I can't recall them right now. Maybe the message is "simple to explain but partially inaccurate ideas are easier to transmit than nuanced and complex ones"

Slightly OT nitpick:

> In particular the arguments based on tags having semantic value were laughable when you consider that in most cases we just replaced table/tr/td with div/div/div.

This comes up a lot and it niggles at me every time. div/div/div was a large semantic improvement over table/tr/td, not because it specifically describes the content you've put in divs better (it doesn't, obviously), but because it stops being explicit "dishonest" about the semantics of that content.

Defaulting to div/div/div over table/tr/td makes semantic specificity opt-in and explicit instead of opt-out and implicitly wrong for generic non-table content. It means devs who want to use specific tags for greater semantic specificity can do so, while most devs are using generics (divs) because they don't want/need the specific semantics. The previous alternative was that the majority were following a pattern that made intentionally semantic table content indistinguishable from generic[0] content.

Otherwise, good post. I'd like to see that list started and growing.

[0] By "generic" content I just mean any content where there isn't a strong desire/need on the dev side to describe it very specifically.

What I don't understand, we have a whole bunch of semantic HTML elements for years now (<main>, <section>, <header>, etc.) and no need for <div class="main"> anymore, but they don't get used very often.

There are two reasons:

1) There's no real world benefit to using these elements, in any easily demonstrable way (maybe there's some sort of tiny accessibility or SEO advantage, but it's fractional in comparison with, say, just using H1/H2/H3 correctly), which mostly leaves them as an exercise in academic purity.

2) The definitions are really woolly and require far too much thought, especially given the previous reason. Why bother debating whether something is a SECTION or an ARTICLE or a MAIN when you can just use a DIV, with whatever probably overly specific `class` you were going to use anyway, and it will still work in exactly the same way?

<main> came late - the others were developed while the HTML5 process was being actively watched and talked about (before people got bored following it) so noone really reported widely on the creation of <main> and as such it's rarer. Hence <div class="main">

<section>, <header> and <footer> are not too uncommon.

<article> is by far the most used, and is also put to genuine use in parsing by things such as Firefox/Safari's Reader views and other such tools. <section> gets used similarly by some parsers I think, though I've no direct examples off the top of my head.

I use nearly the full set of semantic elements, but I think they're a pretty stupid idea in general. They only properly make sense when the actual semantics of your content happens to align with what the authors of the specification had in mind.

For the high-level layout elements it's not so bad, but the <i> element being defined as indicating things such as "taxonomic designation, technical terms, foreign idioms, transliterations, thoughts, ship names, or dream sequences" renders it basically pointless. The HTML spec encourages you to use a class attribute to identify why <i> is being used, but then you might as well use <span>.

Most browsers - maybe all modern browsers - actually accept made-up elements and let you apply CSS to them. There's no good reason - other than compatibility - why authors shouldn't create ad-hoc elements - e.g. <dream> or <tabs> - that match up with the true semantics of the content.

I see them get used all the time!

Some of the most common layout tags I see are: header, main, footer, section, article, aside, nav

Other things can have <footer> tags too. I've seen plenty of <footer> elements inside <blockquote> tags!

Their meaning changed through the design process very often, which is normal. But the whole process was too public and people started to play with them and we had so many different interpretations... In the end, I think the developers just gave up.

Being dogmatic about anything is usually going to end up being wrong. But I think a lot of common advice is meant to serve as a baseline. It helps us take mental shortcuts while we familiarize ourselves with the field. Once you're more familiarized with everything, you start to question things more heavily. Otherwise you'll probably end up with decision paralysis.

> "Separate content and presentation (HTML/CSS)"

The wrong thing was the one-to-one mapping of the content, presentation and business logic to some specific technologies (them being HTML, CSS, JavaScript). That's why so many people got confused when they saw XML tags in React. OTOH, as you said, we usually need simpler rules. The moment people started to think that "now it's OK to put HTML in JS", we started seeing blog posts being written in React containers.

Flash replaced <blink>.

It depends which device you use to look at it. It tends to adapt poorly on large screens or smartphones (at least the ones I use). And this is the primary reason to not use table AFAIK.

For me, HN works better then 99% of all sites. On all of my devices. Desktop, tablet, phone. It always does exactly what I want it to do: Fill the whole window with content. So I can always resize the window to the exact size that is most comfortable for me. And it's blazingly fast.

A few years ago HN's nested tables led to random font sizes on mobile. So there have definitely been problems in the past.

But HN is also in a very unique position. It has 170 lines of CSS and thousands of talented web developers have inspected it for mobile problems. Every easy fix has been made. Most websites can't do that.

> A few years ago HN's nested tables led to random font sizes on mobile. So there have definitely been problems in the past.

That was actually a bug in Chrome, that was trying to be overly smart and changing font sizes aggressively.

I imagine you'd have a different opinion if you needed to use a screen reader.

On a new app I'm developing I am using display: table and display: table-cell. These work great. I'm curious as to why this solution is not more widely used or discussed.

1. On many browsers, if you don't use `display: table-row` between those, it'll mess up your content.

2. CSS only almost exposes the HTML table layout system. e.g. There are no column groups, or column or row spans. There's no way to indicate a table header in CSS that would make a browser repeat it when printing a table over multiple pages.

3. People who learn by rote that table is evil without really learning why are likely to assume that using CSS to make something behave (almost) like a table is also evil.

We switched most of our layout to flexbox in my day to day job about year ago, and Im much happier developer since then.

Also I think the issue is not that bad as it affects mainly desktop version (mobile mostly have content stacked) of sites and people on those are "usually" on faster connections.

(Since your profile page says where you work, and these pages do seem to use flexbox - right?)

The sub-pages on this site are relatively bouncy to me during the first load.

Example:

https://www.intercom.com/customers

Environment: Relatively fast PC (4 cores @ 4.0 GHz, 24 GB RAM, SSD, etc) running Chrome. Large screen (40", 4k running in 150% scale with the browser maximized in size). 250/100 Mbit/s connection. Located in northern Europe.

I don't see any bouncing, I'm using chrome and a 13" MacBook Pro. My connection is also much slower than yours.

Also tried throttling the connection and I don't see anything annoying in how the page layout happens.

You can play with CSS grid today on most (all?) modern browsers, it's just locked behind a flag. I'm extremely excited about it. As I understand it, it should go live on all major browsers next year. This means that hopefully there won't be spec incompatibility issues like we saw with flexbox.

If you want to learn more, css-tricks [0] has a great guide for grid.

Once CSS grid is available, you might be able to start using it everywhere if you're willing to ship the polyfill to legacy browsers. Right now there's a polyfill for an older version of CSS grid [1], but the author has said [2] on Github they expect to get a new release out by around February 2017!

I've only dabbled with CSS grid and one of my concerns is performance. I'm not sure what level of performance we can expect with the initial release. I recall reading about mobile performance with flexbox not being great. Hopefully history won't repeat itself. If anyone has more experience with grid, I'd love to hear your insights.

[0] https://css-tricks.com/snippets/css/complete-guide-grid/

[1] https://github.com/FremyCompany/css-grid-polyfill

[2] https://github.com/FremyCompany/css-grid-polyfill/issues/37#...

You don't need flexbox to have content jump around. Often when loading a webpage with an article, I start reading the article before everything is done loading. Sometimes only the massive title and menu fit on my screen, so I scroll down a bit, then the content jumps for some reason (an image or ad loaded, perhaps?) and I need to scroll around to figure out where I was, and sometimes that happens several times.

Am I the only one with this problem? Do major content sites not test their layout? Or is this accepted as normal behaviour?

I was hoping people would come with more examples of things not to use flexbox for with well-reasoned arguments. I had an experience a few months ago where someone had used flexbox to vertically separate sections that could have various sizes of content that needed to have varying spacing between the content and I really felt as good as I thought the developer was Flexbox was wrong and just could not get past 80% to real completion of the design.

> Don't use flexbox for overall page layout

> Don't let this post scare you off flexbox, it's one of the best layout systems we have on the web today. However, there's a growing problem on the web when it comes to content shifting around during loading.

I think a lot of the negatively would've been deflected with a better title.

If you have ever done GUI layouts in other frameworks there is usually something like flexbox and something like grid. Both are valid and you use what fits your problem better. I like flexbox a little more because I find it more responsive.

So this article was wrong 3 years ago and more wrong today since grid hasn't materialized yet.

How do you slow down the loading of a page, like it's done in the article?

Apple's Xcode installs a Network Link Conditioner preference pane that can throttle the whole computer's network connection.

In Google Chrome you can go to Developer Tools -> Network, and change No throttling to something you like.

Chrome dev tools have network throttling

Reply on news.ycombinator.com