Hacker News Reader

Hacker News

Comment by k__ | Hacker News Reader

Full thread

k__

It always helped me to do an absolute basic concepts course on a new technology I learn.

Like, sure I can play around in Photoshop or Eclipse or CSS or JavaScript and find most things.

But a good 101 course is worth so much saved time.

Most of the stuff in that article was mentioned in a CSS box model course I did 10 years ago.

People were always baffled how I learned all this. Well, I read the docs!

They always assume every one learned like them, by trying stuff out all of the time, until they got something working. Then they iterate from project to project, until they sorted out the bad ideas and kept the good ones. With that approach, learning CSS would probably have taken me 10 times as long.

Sure this doesn't teach you everything or makes you a pro in a week, but I always have the feeling people just cobble around for too long and should instead take at least a few days for a more structured learning approach.

What I didn't learn about CSS in a basic course and what cost me multiple weeks to fix, was `pointer-events: none`. Keep this in mind when your clicks stop working after you pulled some new CSS ;)

View on HN

> I always have the feeling people just cobble around for too long and should instead take at least a few days for a more structured learning approach.

There are two kinds of documentation: there's a list of all the individual things you can do, and there's a "The fundamental abstraction is this". The second is rare, and rarely done correctly, and much more important.

A lot of people assume that X is like Y, but with Z, and they know Y, so they just need to learn about Z. A lot of time that isn't true, the fundamentals are different. The natural way do perform W in Y might be profoundly wrong in X. Examples:

* git is like subversion, but distributed.

* C++ is like C, but with classes.

* C++ is like Java, but you have to remember to delete stuff.

I love git. I love C++. I think these things are the bee's knees. They're so simple and elegant. But I totally understand how people think they're arcane eldritch horrors when you're holding the sword by the pointy end.

> there's a "The fundamental abstraction is this"

In most cases, I'd settle for "what problem this is trying to solve" (although this is obvious for CSS, it isn't nearly as obvious for things like React and Vue).

The problem here is that really understanding "what problem this is trying to solve" often requires a passing familiarity with cognitive science.

How many people here could explain the link between Working Memory and React.js?

New to JS world. Would love to know a brief explanation.

Exactly. Another fundamental abstraction they should have mentioned in the article is [the surprising way z-index actually works](https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Positio...), especially being aware of the existence of [stacking contexts](https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Positio...).

Can’t agree more. The first kind of doc is useful from time to time to check the correct argument of a function. The second one is about the big picture and the overall architecture. And sadly this is what is missing with every codebase I’ve worked on. In my project on the contrary, this is something I try to document.

If someone needs to read documentation for a few days in order to figure out which end of the sword to hold, perhaps the sword was just poorly designed and unintuitive.

So you want a dull sword with handles on both ends just so that nobody can possibly cut themselves? Professional tools are meant to be efficient for those trained in using them and if that means they are slightly harder to learn that's OK.

Cobbler here, currently cobbling a frontend (am a backend dev by trade).

The issue for me is the format these courses and resources take. CSS is the most jam packed with non-intuitive technology I've met. How many dozens of pages or segments of video would I have to go through in a course to learn what the author in OP summarised in two or three sentences? Any time I've considered the structured approach for something like CSS, the material drones on and on with technically correct explanations and example code, but somehow against the odds, almost nothing of substance.

Worse yet are the top google result reference resources. Look no further than the top result for "css grid" if you're in the mood to claw your brain from its stem, and flush it down the toilet.

Link: https://css-tricks.com/snippets/css/complete-guide-grid/

Behold, 8 zillion words and symbols across 7 trillion seemingly randomly organised boxes full of both all of the information, and simultaneously none of the information, about css grids.

Which brings me to where I am now, cobbling. It's more effective for me to cobble, than to spend an entire day figuring out css grids "the right way". If the going gets tough I'll just use some grid tool, or look up some sandbox examples, and be on my way.

If there was more material like the OP, and someone organised it well, well, I'd actually get around to learning it rather than cobbling. It's the best bit of writing I've ever seen on CSS. This is shocking. Not that there is anything wrong with the writing, but it's very, very simple. What on earth have all of the other CSS wizards with basic writing skills been doing? Confusing the issue, that's what.

Which leads me to a sort of meta frustration with learning CSS. I know it's not hard, I know that if someone just wrote about it even half decently it would take only a moment to digest each concept, but watching learner-disconnected authors create resources I can tell have lost sight of what it's like to learn, turns me off.

Yes, web technology is overloaded, because of the history, backwards compatible stuff etc. pp.

Couldn't agree more. I had less issues learning multiple programming languages,some challenging concepts around them and yet when it comes to CSS, most resources aren't very useful. You do something and it doesn't work. You check documentation and it show exactly the same thing that does work. 5 hours later it turns out it was some overriding property+ browser incompatibility+ weird undocumented exception. Very few books do deliver on their promise either. I don't know,maybe it's just me but the whole ecosystem is a bit weird.

" but the whole ecosystem is a bit weird."

It absolutely is.

The web was meant for static documents and some link magic.

Now allmost every complex programm can run in the browser with web technologies. And in the time between you had lots of powerful organisations with their own agenda, as well as millions of single developers with a agenda and a loud voice. How could a sane, clear spec be made, under these circumstances?

Besides, it would be very hard, to make a clean spec that satisfies the needs of the whole population. So by now I say, all in all, it works pretty good.

How could a sane, clear spec be made, under these circumstances?

Serious answer: By respecting and supporting the organisation that had for a long time codified realistic web standards reasonably well. When the Web was younger, you could (and many of us did) learn all you needed to know about things like HTML and CSS by reading the documentation produced by the W3C. In many cases, the official recommendations themselves (the documents that were informally called "web standards") were very readable and short enough for normal developers to go through the whole thing.

My experience with the W3C was very complicated written specs, with sometimes no connection to reality(implementation in the browsers). And they moved too slow.

And no. I don't think you can expect the whole world to wait for some spec commitee.

It wasn't that way in the earlier days. The W3C certainly made some questionable decisions later on that contributed to its slide into irrelevance, but it was Google flagrantly ignoring standardisation, absurdities like "living standards", and the way all of the other major browser developers were asleep at the wheel for years that really sealed the W3C's fate. And now, sadly, a new generation of web developers is about to learn the hard way why browser monopolies are a bad idea. :-(

> the whole ecosystem is a bit weird

The whole ecosystem reminds me of why I did not study synthetic biology or medicine. I prefer the systems I work with not to have evolved but to have been designed by some intelligence with a limited memory for random details.

I had the same perspective on these frontend technologies as a backend/ops guy, and it all finally clicked when it came to me that I just couldn't find a justification for why CSS was the way it was.

This was solved trivially by just reading the history of CSS. It was shocking to finally have made clear all of the quirks and weird aspects of CSS that always made it difficult for me to connect the dots and feel myself lost in a messy tangled up language.

By far the best source I went through was found here: https://news.ycombinator.com/item?id=22215931 - it's a long read, but extremely enlightening!

https://www.w3.org/Style/CSS20/history.html was also useful.

This is a great comment. I expect it only applies to some folks depending on how they learn, but it resonates a lot with me.

I find it very difficult to learn the whats and hows of a new thing without the whys. I tend to construct mental frameworks of things, revising the inaccurate bits as I go, until theory starts meeting practice. (I always did poorly with math "teachers" whose method was, "doesn't matter, just do it." But it did take a while to realize that they were failing, not me.)

So when I encounter complicated, new things with a history, I usually try to start with at least a bit of the history.

This is so true. Though I'd been writing CSS long enough to remember Netscape 4.0 quirks, it wasn't until I learned some troff a couple years back that I had my moment of CSS enlightenment. The fundamental features are the same! CSS (and HTML) were (originally) made for pages of technical/academic writing, not creating user interfaces.

> Behold, 8 zillion words and symbols across 7 trillion seemingly randomly organised boxes full of both all of the information, and simultaneously none of the information, about css grids.

It's interesting, because that's my go to resource for CSS Grid. I find it super handy when I forget something. Although, I'm not learning grid, I'm using it.

> Although, I'm not learning grid, I'm using it.

Precisely. What CSS-Tricks calls a guide is actually almost entirely a reference. It makes a tolerable reference if you already know what you’re looking for. It’s a poor reference if you don’t know what you’re looking for because it’s insufficiently structured and takes waaaaay too much scrolling to explore. (It used to be more manageable—it used to be more a guide. It has been allowed to grow far beyond a healthy point.) And it’s atrocious as a guide.

Reference books aren’t the same as textbooks.

And, typically, there are several levels of textbook. e.g. high school, then freshman physics, undergrad electrodynamics, then Jackson, then specialist references.

My point is you go over the subject completely several times, at increasing levels of sophistication.

Your evaluation is problematic.

I am a front-end dev by trade and I could really easily say similar things about the tech stack you work with daily.

If you want a good reference and a learning guide start with this: https://developer.mozilla.org/en-US/docs/Web/CSS it is what us professional use.

For us professionals that use CSS in our jobs, that have put the same amount of hours into front end technology as you have done for back-end, CSS is a perfectly cromulent technology. It is easy to work with, it is intuitive, it is easy to find a good reference (go to MDN not random blog posts from people that are admittedly not masters of the craft).

If I try to cobble together a back-end I expect to be frustrated with it, I expect not to be able to do everything, I expect I’d need to find poor example and try to hammer them in to fit my needs, I don’t expect to be able to understand all the example snippets. Why are you on your high horse judging my tech stack this way?

If you need a good well crafted front-end for your project, you should hire a professional front-end developer. Or find a friend who is one that is willing to it in their spare time. Or spend a few thousand hours learning and mastering the craft. Alternatively you can cobble together a good-enough front-end that works, just don’t complain about how hard it is because “technology hard wheee wheee”. Us professionals use it every day and are fine with it.

"here I am, at the end of the maze, telling people at the beginning how straight forward it is" is basically all I'm getting here - and you call my eval problematic.

Multiple accounts of people not in your position telling you a problem exists. Ok, great, you worked through it. Doesn't mean it's as good as it should be.

Well you come across as an outsider telling us that the tools that we use—and do a fine job with—are no good, and that our literature sucks.

I am here to argue that this sort of attitude is problematic. If you browse through this thread you will find no shortage of comments describing how absolutely basic this article is (and a little void of insight, and a little out dated), and that there are people in the industry getting six figures while not knowing this stuff. Frankly it is a little insulting. And I think the attitude that you presented above is part of the problem. There definitely exists a lack of respect for the craft of front-end development within our industry. This sort of attitude is not helping.

> There definitely exists a lack of respect for the craft of front-end development within our industry. This sort of attitude is not helping.

There is xenophobia involved in people's attitudes toward kebabs. It doesn't change the impact of phosphates on the human body.

Here: https://www.bbc.co.uk/news/world-europe-42238363

Your argument doesn't change the impact of poorly-encapsulated complexity on the brains and mental health of your fellow programmers.

https://blog.codinghorror.com/programmers-and-chefs/

> Well you come across as an outsider telling us that the tools that we use—and do a fine job with—are no good, and that our literature sucks.

https://en.wikipedia.org/wiki/The_Jungle

---------

Backend programming has this problem too. So does systems programming. The problem of unencapsulated complexity is core to the craft of software engineering.

So is joining the fight against this problem. https://tonyarcieri.com/would-rust-have-prevented-heartbleed...

Or spend a few thousand hours learning and mastering the craft.

Surely the point is that you shouldn't need to spend thousands of hours "mastering" something like CSS? It's not that complicated and it's not that important. If you told a developer working on desktop or mobile applications that they'd need to spend years "mastering" the design tools in whatever GUI framework they were using before they'd be able to independently build a good user interface, you'd be ridiculed.

Anyone with the aptitude and interest to become a web developer, which isn't a particularly high bar as technologies go, should be able to get the hang of all the important parts of modern CSS in at most a week even starting from scratch. The fact that we don't reliably train new developers up that efficiently is a damning indictment of the current state of the industry.

Check out Tachyons or another atomic CSS system. It makes CSS so much easier to use (especially in single-page apps written in JavaScript). https://tachyons.io/ "Create fast loading, highly readable, and 100% responsive interfaces with as little css as possible."

See also: https://css-tricks.com/lets-define-exactly-atomic-css/ "Atomic CSS is the approach to CSS architecture that favors small, single-purpose classes with names based on visual function."

Or from: https://acss.io/ "CSS is a critical piece of the frontend toolkit, but it's hard to manage, especially in large projects. Styles are written in a global scope, which is narrowed through complex selectors. Specificity issues, redundancy, bloat, and maintenance can become a nightmare. And modular, component-based projects only add to the complexity. Atomic CSS enables you to style directly in your components, avoiding the headache of managing stylesheets. Most approaches to styling inside components rely on inline styles, which are limiting. Atomic CSS, like inline styles, offers single-purpose units of style, but applied via classes. This allows for the use of handy things such as media queries, contextual styling and pseudo-classes. The lower specificity of classes also allows for easier overrides. And the short, predictable classnames are highly reusable and compress well."

Mostly though, Atomic CSS is a state of mind or design pattern. So you can do it from scratch without support from something like Tachyons etc. -- but it helps.

You might even find it fits right in with your "cobbling" style of development. As an example, if you want to make some text red, you add the style "red" to it. If you want a border all around something, add a "ba" class. If you develop using HyperScript (like from Mithril) to define your UIs, code might look like this: h("div.red.ba", "This is red and has a border")

I refer to the Tachyons style sheet as essentially a menu of options: https://github.com/tachyons-css/tachyons/blob/master/css/tac...

In the rare case something is missing I do an inline style or add something to a single supplemental stylesheet written in a similar way.

There is also a verbose version of Tachyons without the abbreviations, so "ba" would be "border-all" (though I prefer the abbreviations): https://github.com/tachyons-css/tachyons-verbose/blob/master...

100% agree. I found this to be a good guide: https://developer.mozilla.org/en-US/docs/Web/CSS

After spending a few hours reading up on topics I thought would be relevant, I find that I am significantly more productive with CSS. Instead of trying to find answers on google, I find that I’m better equipped to build things and diagnose issues on my own.

Once I got the basic concepts of CSS I came to realize that of the trio of HTML, CSS, and JS (and SVG for that matter), CSS is the one you really miss when you have to make something using another system.

The amount of suffering I've endured in Latex, PDF, different native layout systems, or even React Native's slightly restricted version of CSS that would have been resolved by a stylesheet is immense.

I totally agree. A good book that introduces CSS in a methodical perspective is a must. I personally cut my teeth on CSS with the book Web Design in a Nutshell, a 2006 book. I remember having written CSS in a haphazard try-and-see fashion before that, which utterly confused me, and then reading an actual book made everything clear. This is an investment worth making. Many years later I'm still almost always "the guy" on my team to go to when there's a weird CSS issue.

> A good book

One under-appreciated value that actual books have over online documentation is that you know immediately what order you're supposed to read them in.

I have tried both approaches a fair amount, and realized that every time I try the cobbler approach I end up getting blocked on some major thing and thus having to rewrite everything because of some basic things that could have been avoided.

I feel like it's getting both better and worse now with docs getting better in general(no of times I end up on stackoverflow has gone down significantly), however a lot of times I end up on medium posts with a list of steps and absolutely zero reason why. Whenever I try cobbling from those articles, I end up very frustrated

I completely relate. Other things I learnt "formally":

- regexps (this is a big one, being able to write a complex regexp without thinking about it is amazing)

- Git

- basic JS when it was mainly used to add snow on your page

Taking the time to properly learn things is extremely valuable.

I'm kinda curious how the long term viability of these strategies look. Intuitively I think that reading the docs will become less and less viable as there are more and more available technologies and they become more and more featured. But I'm not fully convinced. Maybe it can keep working by only teaching the most important subset.

Learning by course is generally good (rust book!), but "overlearning" certainly exists in all technologies. I've been hanging out in freenode's ##learnpython for years helping noobs, and I can't count how many times I've met the scenario of a new programmer working their way methodically and studiously through a 2k page book, stuck on page 1643, because they haven't actually grasped concepts from page 20. They'll be all kinds of worried about how to correctly use slots and metaclasses, when they can't write even basic functions.

CSS suffers massively from this info overload.

What I tell every new programmer who will listen, is that they should first grasp the absolute basic building blocks, and then learn to read the docs. That's really all you need. Unless the particular language or technology their are using sucks, you can essentially compose anything from the basics. Once you've done that, the sortcuts and sugar you learn naturally actually make sense, rather than appear before you as spooky magic boxes and incantations.

My ideal CSS course would just be the absolute basics of syntax and concepts, a primer on understanding and incorporating information from the docs, and then an index of well organised resources, such as the OP's.

This way, it's impossible to overload, and I'm left in a state where I can expand at my own personal rate. Anything that tries to set the pace for you is going to be suboptimal for 99% of readers.

Furthermore, anything that flows easily and without extremely explicit DO NOT PASS GO UNTIL YOU ARE EXCELLENT AT THE LAST CHAPTER, will lead to overload. You can't overload if you don't provide the information one can overload with. Simply ending your course after the basics and docs, absolutely guarantees against this problem. "Leave the learner in a known good state", would be my rule of thumb.

There is a learning method that hasn't been mentioned in this thread. Namely, a middle ground between pure cobbling and pure theory. In addition, you have to find a method that is optimal to you.

For myself, that's a feedback loop where bugs during cobbling naturally present themselves as theory questions needing an answer, rather than practical questions needing a solution.

It is rare to find documentation of such high quality that grasping the fundamental abstraction does not require theory-attentive debugging.

After spending years learning on the job, I started reading the documentation books cover to cover, and I have never looked back. Colleagues are often amazed at my "deep knowledge" of the technologies I use, however I mostly know what is written in the manual. It baffles me that people can't be bothered to read the documentation and at the same time complain that "X is too hard! Let's use Y instead!"

There's a reason RTFM was so prevalent, and we need to make it so, again.

Same here. I tried finding a book about deb and rpm packaging the other day and couldn't find one. Left me feeling anxious.

I built my first site in the 90's too (before CSS)! I've been in higher education lately, but have a YouTube channel with mostly CSS related content (both beginner & advanced). Check that out if you're interested in some great starter learning content for CSS and you prefer video format: https://www.youtube.com/followandrew

For me personally, documentation was just a step one, helping me to discover that some feature exists, what options are, etc. - and then "cobbling around", as you said, was the very important 2nd step where I'd really understand how something works and what's the best way to apply it in real life. Everyone learns differently, I guess...

Reply on news.ycombinator.com