Hacker News Reader

Nah, I think the history is important, especially for web development where modern tech stacks are technologies built on technologies built on technologies, and pretty much everything has to be backwards compatible.

I've run into so many situations while learning web development where a design decision seems like nonsense until later when I learn about the history of how it evolved. First example that comes to mind is the `===` situation in JavaScript.

It's also useful to be able to know what you're looking at when reading code that others have written.

Exactly this. When you're starting something _new_ it's possible that you don't care at all about the history. It's when you inherit something _old_ that the history becomes very important.

History can be important, but I don't see what knowing that developers used to (ab)use <table> for layout explains about modern CSS. By all means, include historical context if it helps explain why something works the way it does, but otherwise drop it.

And while backwards compatibility remains a concern for browser vendors, it's much less of a concern for web developers nowadays given the vast majority of users are using auto-updating browsers. Indeed, the purpose of this guide appears to be an explicitly "evergreen" guide to CSS, targeting only the feature set of modern browsers. If you're using grid, custom properties, conic gradients, etc. you're not writing backwards compatible code.

I think it adds a lot of colour to a relatively boring part of the tutorial

tables are still relevant for layout if you work with email at all. In fact, if you want to be able to do email well, you have to be able to do layout like it was 10-20 years ago. There's also lots of legacy code out there to be working with, and sometimes the "old way" of doing it is still better than the new way. A pet peeve of mine is seeing flexbox everywhere, when a simple 'display: inline-block' might work. In my opinion, it's all still relevant so long as it still exists as part of the language.

Email is a different can of worms, but it does not just correspond to web design 20 years ago. You can use a lot of CSS in email, but in a different way and under weird constraints with never exited on the web.

I resent the "(ab)" in "(ab)use tables for layout"... it was all we had AND was still better at vertically centring things until Flexbox arrived!

Abuse only in the sense they were not designed for this purpose. Like people using <blockquote> to create margins.

It is like using a screwdriver to knock in a nail because you don't have a hammer - better than nothing, but not what a screwdriver is designed for.

A table is an extension of a grid and therefore actually in the same ballpark as the proper tool for layout whereas using <blockquote> to create margins is totally random (though perhaps someone could stretch an explanation).

It's of course pedantic to discuss all this now as those days are thankfully long gone :D

I'm confused why the web standards don't include something like a version header for JS and CSS. That's an easy way to eliminate cruft and silo the logic in the browser engines.

How would that eliminate cruft? Browsers would still have to support old version for backwards compatibility. Much better IMHO to extends the languages in a backwards-compatible manner.

My peeve is really about how to structure teaching. Teachers often seem to forget how they learned things themselves. You learn a programming language by diving into it it and making things work - not by first studying its historical roots decades back.

I think it depends. Anecdotally, I personally feel very unanchored and semi-anxious when someone just dives in to the explanation of "how we do it" without the context of why we do it this way and how we got here.

I find it similar to the use of acronyms. When an explanation introduces domain-specific acronyms I always ask what the acronym stands for. It's important to me because just memorizing key "ABC" and associating it with some kind of outcome forms a very weak bond in my brain. If I know what the acronym stands for, the bond is far stronger and larger pieces of the picture are revealed. Interestingly, I find that when I ask an explainer what an acronym stands for there's a couple classes of responses. In my experience, most are simply that the explainer doesn't know. And among those explainers, most don't care. But some will be curious and look it up. A few will know and you can tell that they find it important too. Fewer yet, will explain the definition when introducing the acronym and maybe even comment about its origins.

I'm guessing that these classes of people would also correlate closely to those who prefer turn-by-turn directions vs a route on a map with the full context of other routes in the area.

> The section about layout starts with...This history lesson is not really relevant for newbies.

so folks know what we're talking about:

https://web.dev/learn/css/layout/#layout:-a-brief-history

It's four (pretty short) sentences that give a small amount of context pretty quickly and then links to another resource if you want to know more. I'd agree with you if it were a page or two's worth of history, but there's not much to find distracting here.

More importantly I think you're focusing on the newbies who are coming in with nothing but ignoring the newbies who are looking at existing code and a whole bunch of tutorials and stackoverflow answers out there written over the last two decades. Acknowledging that things have changed in CSS quite a lot in that time and pointing to where they can learn more means you don't distract the really new newbies much but you also don't confuse the other ones, leaving them with lots of questions ("but I read [this] about CSS...") and no idea where to look to reconcile some old advice ("use jquery for all styling!") with what they're learning now.

But it's also four sentences in the eighth chapter of a tutorial. It's not going to solve all confusion but it's also not a derailment.

But there are many generations of cruft. Table-based layouts is just one thing, how about font-tags, quirks-mode-triggering doctypes, frames, float-based layouts, <!--[if IE]> and so on. Each of these might by necessary to understand in some very specific cases of legacy code.

I'm just saying: Don't put this up front in a tutorial.

Don't explain GOTO before explaining if-else blocks.

The contrast helps me.

As someone who made/hosted Web 1.0 websites, isn’t a software engineer, and has over the past few years tried creating/hosting websites again, things got a lot more complicated in the interim.

So I hear your perspective that it sounds like some old person is yelling get off my lawn. No one wants to hear that.

However, for someone like me who didn’t have CSS, the slight history lesson is helpful.

Don’t agree. Historic context is important to understand legacy codebases, code examples in other resources and colleague’s behaviors.

Yup I think this is the most important piece of why new students should know about this, if they ever touch a legacy codebase.

Very few legacy codebases from the tabled 90s still using tables. Yes, a few exist but not that hard to grok.

Sure, but that is an advanced subject. Don't put it before explaining what the technology actually does!

The historical context can be important, but I agree that it can get in the way of the learning for CSS newcomers. I think there's a happy medium here. A link to a separate article or reference of the history would get it out of the way but offer context for those that seek it.

This history lesson is not really relevant for newbies.

If you're working on a new project that's true. If you're working on an old project, and bringing it up to date, then understanding the code that's there is very useful. That starts with understanding how things were in the past, and why people did things that might seem a bit crazy (eg spacer.gif).

You still need spacers in 2021 to add bottom padding to CSS grid:

https://github.com/w3c/csswg-drafts/issues/129#issuecomment-...

Specifically with CSS, if you omit this, the first logical question of anybody who attempts to learn it is "wtf, why does it work in such a stupid way".

Basically, historical context helps to cool down natural negative reaction.

CSS and Javascript both. Forget legacy codebases, people seem to forget how much legacy documentation, tutorials, and Q&A is out there confusing newbies who don't have the context to know what's no longer relevant or accurate.

In answering questions from actual newbies completely new to this, I was a bit surprised at just how much I took for granted because I was around for the historical context.

I think it is more helpful to explain why thinks work the way they do.

It is relevant in html emails, which are basically a time machine to inline styles and table layouts if you want consistent rendering. This would make no sense to a developer unless they understood the progression to where we are today.

Email development is pretty niche and its own category of expertise. CSS straight up doesn’t apply there the way it’s used regularly (via selectors)

Totally disagree. In a technology with a long history, especially one that never breaks backwards-compatibility, a whole lot of things seem nonsensical without context. And this isn't just relevant for apologetic purposes: seeing and internalizing the patterns and the internal logic often requires that background knowledge.

Think about when you're learning to work on a legacy system. You (hopefully) don't just learn the current state of the system in a vacuum. You go through and learn the history of decisions and constraints that got it there, the layer upon layer of changes that resulted in the end result in front of you.

In my view, if you have made it through to module 8, you're not going to be put off at that point by a single paragraph explaining the historical context. If it was the introduction to the whole course, you might have a point.

I disagree. I like to learn about the history and motivations behind a technology. It gives me context and helps me to remember facts that would otherwise be hard to remember, besides being enjoyable.

> This history lesson is not really relevant for newbies.

I disagree. Knowing the context and motivation behind why a certain technology was created is always helpful for learning.

Funny, this very page you're commenting on uses tables for layout.

I see the reason for people’s disagreement, but with a very important exception:

Sometimes new ways of doing things completely free us from the friction of the previous ways, and people who do not already have those scars have the advantage of being unrestricted by them

Consider that part of the audience are developers who've dabbled in HTML/CSS over the years, but never frequently enough to stay current. We have old habits to unlearn. The context helps.

> I don't care about the headaches people had 20 years ago

Hard disagree. Especially with technology, what we have today doesn't usually make much sense unless you compare it with what we used to have: everything started out the simple, but naive way, and evolved out of combat-tested lessons learned to what it is right now. If you don't know what those lessons were, a lot of the design decisions that went into what you see will seem mysterious and, possibly, pointless.

I've worked on a lot of legacy codebases that implemented some of these older design patterns. Understanding the history is essential to knowing what to replace it with.

> When learning a new technology I don't care about the headaches people had 20 years ago

I do. This really puts things into context for me. If I don't get that when learning something, I will look for the answers later. So I'm very happy when it's right there to begin with.

Sidenote: This may be a case where the kids don't have it easier today, as many people I know say that tables were much easier than today's CSS3+ grids and flexbox layout systems.

I don't want to pile on here, but give another reason why you might care how people did things 5, 10, 20 years ago: you're likely to encounter that code at some point.

I think attitudes like this are why so many people don't respond well to math