This might not be considered hip and modern any more, but I think there's still a lot of good fundamentals described, and well-written:
I'm not sure that this is a good resource for a beginner, because it would teach them practices that aren't just out of fashion, but altogether unused, and would hurt them in the job market IMHO.
Much of this text is now obsolete -- not obsolete like "oh, a new JS lib du jour came out yesterday and we should all adopt it", but obsolete like "if you use this, many browsers won't support it and nobody else in your generation will be able to maintain your code".
Specifically:
- DNS and HTTPS are way more complicated now than when this was written
- Mobile usability isn't done this way any more; WAP and XHTML are not in use
- VoiceXML is not used
- XML in general has largely given way to JSON. SOAP is rarely used except maybe outside of academia and other niches.
- RSS is pretty much dead
- The DOM structure is not as semantic as in the past (unfortunately)
- It presupposes that most data must live in a RMDBS as opposed to other storage paradigms
- It completely ignores (well, predates) the prevalence of abstracted cloud services that most web work uses these days, vs reinventing search etc. from scratch
- Analytics is likewise way more complex today, but in the post-Google Analytics era and in the post-privacy era
- Some of the HTML syntax it uses is deprecated
- It presupposes a simpler full-stack model where a small web team will do the entire full stack work from the UI to the DB admin, vs today where that's usually specialized and/or outsourced to various third parties and APIs
I hope this doesn't come across as snobby... just trying to give the OP some context about where this fits in relative to modern work. Some of the fundamentals are indeed worthwhile reading, but the text itself doesn't make clear what is or is not still relevant. Without prior knowledge to be able to differentiate that, this book could teach a bunch of deprecated practices.
For now, just focusing on the basics of HTML/CSS and especially JS will get you going well enough, and those will all be applicable in web work no matter what specialization you choose.
Those are what we normally consider frontend technologies (though JS can also be used on the backend). If you also want to learn the backend side, having some frontend knowledge still never hurts, if only so you can work with the frontend people better.
This text might be worth circling back to later in your career, once you start considering architectural patterns. But for now you have a lot of other great suggestions :)
It's usually somewhere between 10k users and 1m users where the rules change entirely and you need to start looking to more modern/advanced approaches. 10k is kind of arbitrary, because you can do some really stupid things with a traditional rdbms with sql.
It's not that the principles are invalid these days, but that the specific examples and techniques mentioned in that text are now often done with different tooling. Significantly, a lot the low-level stuff has also been replaced with higher-level, industry-standard abstractions (which embody many standard best practices that might otherwise take an individual years to learn and polish), building upon the lessons and mistakes learned over the decades. This text doesn't really clarify what is a long-lasting architectural principle and what was just a fashion trend of the day and now obsolete.
Realistically, I think new devs coming into the field these days are likely to first encounter those abstractions (whether it's HTMX or Next) before understanding the history of why they exist (and what their tradeoffs are). Those architectural tradeoffs are important to learn at some point, but usually those decisions are not left to the newcomers (in a sane company) and also should be taught in the context of modern tooling and decisions, not software that was common two decades ago.
Like important questions these days might be (as you said) what do we do on the server vs client JS (or rehydration), what do we outsource to a cloud (which clouds?), what do we containerize or not, how do we deal with HTTPS and mobile and cross-platform (web/iOS/Android), etc. Not "what is the best log parser for Apache" or "should we use MS SQL because it works better with Access". In some companies, it might also be "which off-the-shelf CMS best fits our use case" vs "Is C# or Java or more appropriate for our backend?"
If someone wants to take the time to highlight the specific, still-relevant sections of that text, I think it could be worthwhile. But otherwise, without that differentiation, it's just kinda a minefield for newcomers.
Aside: Right now, exploring HTMLX + server-side yew for rendering in rocket (rust), which could be very interesting. Usually do https termination at the platform, or reverse-proxy via Caddy. And I'm a proponent of containerizing all the things (Docker).