Some of the opinions reflected in the linked materials
are presented as if they were obvious best practices, statements like "never do X". While it may be initially helpful to beginners for someone to provide guidance in such absolute terms, it can also lead to adoption of cargo-cult approaches and impede deeper understanding and growth. The linked materials are also problematic in their one-sided and outdated perspective on "separation of concerns", claiming CSS belongs exclusively in external stylesheets. Which ignores completely the emergence and widespread adoption of modern component-based architecture. Not just in frameworks like React and Vue, but also standards like Web Components.
Maybe an unfair criticism given it's "introductory"... but I'd urge anyone who seeks a better grasp of the power of CSS to look instead to the axioms and layout examples on https://every-layout.dev for its much more rigorous, up-to-date, "first-principles"-based, expert treatment of this thorny subject.
On a related note, CSS is indeed harder than most think. That being said, I’ve been using CSS going on 20 years now and have seen a lot trends cone and go. One current trend is that there seems to be a lot of unnecessary complexity. SCSS, for example, is indeed powerful, but most sites and web apps I’ve worked on don’t need it and could basically have the entire component-based layout structure rewritten with a single, efficient, well-organized standard CSS file that doesn’t need to be built from 30-odd separate SCSS files. The same goes for so-called transpiled Javascript “languages” such as Coffeescript and Typescript. These, for the most part, add unnecessary layers of abstraction and complexity, making it far more difficult to debug. By using these abstractions, we developers are also doing ourselves a big disfavor because we are often not learning the underlying technology that the browser actually understands. Of course I get that there are domain-specific problems that these tools are trying to solve, but they are often inappropriately employed simply because they’re trendy. With some apps I’ve worked on, it’s anbalagous to using a farm tractor when all you really needed was a lawnmower.
> a single, efficient, well-organized standard CSS
I still haven't seen a single, efficient, well-organized standard CSS file in 20 years, so I think I'll stick to the well-proven SCSS/SASS build pipelines that add considerably more upside than downside. If you're a paid professional, there's no excuse to be doing things the "old way" in 2019.
CSS Zen Garden was, in my opinion, one of the best experiments on web development to demonstrate the flexibility of development that existed in HTML and CSS, but not to demonstrate that you would never again need to touch up your HTML code whatever the project. In 2003 –when this project was born– the average weight of the CSS files was 6KB. Today (2019) we are at an average of ~500KB, so using the CSS Garden argument card is, in my opinion, wrong. First, because it never adapts to the reality of developments, second because the difference in code size required is higher when new development parameters are taken, based mostly on philosophies such as BEM or others. CSS Garden is an HTML doc, with just 54 CSS classes, against more than 2000 classes that can be found in other modern projects.
This. Stuff like this is why the modern web feels so slow and eats absurd amounts of memory. Think how big that is in memory once it's turned into some data structure that can be queried & modified by Javascript, and re-calculated, and consulted again as screen size changes, and so on. And think how much memory has to be allocated to effect that transformation in the first place. And cycles burned actually doing it.
Well, that and no-one cares about shipping massive media files with the initial page anymore (remember thumbnails? Anyone? No?)
And, you know, just all of Javascript.
But still. This is a problem.
I think when your CSS passes short-story length you maybe need to re-evaluate what you're doing. Consider sitting down to write a short story, like a 5,000-10,000 word thing you could sell to a genre mag. It's not all that short. It's a fuckload of text, actually, if you are facing having to write it. That's a lot of CSS. So much any sane person would hate to have to sit down and read it beginning to end. Should be more than enough, even for complex layouts, even for fancy pages, even for responsive. 500K is almost half a Moby Dick, for comparison. There's no possible way your team even knows what most of it does.
That's the way it is. I have found examples with CSS that exceed 2MB. That makes it literally impossible to change the design, maintenance or understanding of the architecture itself. That's why functionally programming CSS eliminates all those problems. Almost 2020 and we have not yet evolved to this style of development.
None of these satisfy the aforementioned qualities. None of them look better, IMO, then an equivalent SASS/SCSS version that likely make most of these even more readable.
And has to be "compiled" into an incomprehensible, bloated, inefficient mess of a new actual CSS file, before it can be used, rather than simply served by a web server.
I was skeptical at first but after using it in real projects I’m a convert to the functional style of css espoused by libraries like tailwind. It’s not a silver bullet for css problems but it’s much better than the component based approach of other paradigms.
>Maybe an unfair criticism given it's "introductory"... but I'd urge anyone who seeks a better grasp of the power of CSS to look instead to the axioms and layout examples on https://every-layout.dev for its much more rigorous, up-to-date, "first-principles"-based, expert treatment of this thorny subject.
Yes, https://every-layout.dev is eye-opening in terms of taking advantage of the power of CSS and using it as it was intended vs. trying to turn into… something else entirely.
While I agree that stating opinions as obvious best practices is problematic at any level, I do appreciate a lot that this guide seems (I only skimmed it) to keep things basic and to the essentials.
From a lot of resources floating around and talking to people interested in getting into web development, I feel that the entry-level tooling and techniques you supposedly need to know has gotten like 10x more complex compared to 10 years ago, whereas I'm not convinced that the majority of people is solving significantly harder problems.
Don't get me wrong, most of the modern tooling and techniques are immensely helpful for aspects that were a massive pain in the past, but they can also create a at least perceived unnecessarily high barrier of entry into the field. E.g. I had absolute beginners asking me questions about problems with their docker setup, errors in their build chain or their confusions with things like redux, etc.
> Some of the opinions reflected in the linked materials are presented as if they were obvious best practices, statements like "never do X". While it may be initially helpful to beginners for someone to provide guidance in such absolute terms, it can also lead to adoption of cargo-cult approaches and impede deeper understanding and growth.
I don't think you need to worry about the likelihood of anyone doing web development, even (especially) as a student, losing sight of the fact that there are a thousand different ways to do anything and no definitive best practices.
The problem is that the OP presents opinions and specific _suboptimal_ ways of doing things in such a way as to discourage the student from questioning them (by omitting mention of alternatives, and treating cargo-cult patterns as if they were foundational principles or axioms.) The danger of learning from this kind of opaquely opinionated resource is that it fosters incuriosity; its students are more likely to discount or ignore other paths when they recognize "violations" of said [false] "principles". It'd be different if the materials were presented as a snapshot of one person's shortcuts, hacks and rules of thumb -- but that's not at all how it comes across. Hence my complaint and warnings.
Not vastly superior, no. I use duck duck go, and nowadays I seldom use the google !bang to supplement a search; when I do Google is usually just as incapable of providing an answer.
The ROI of learning web development has never been higher. With modern-day frameworks and tools like Firebase anyone with knowledge of javascript can build apps. Exciting times.
It is a mess, but that's usually because those easy to use frameworks make them a mess. Big site inevitably are going to be filled with a lot of JS that for things you're not going to implement anyhow. Start small, build upon previous knowledge, incrementally.
As a noob I've really enjoyed Frontend Masters courses. Brian's courses are great, and it sounds cliche but the JavaScript the hard parts by Will Sentence really changed how I think about how JavaScript actually works.
Any user interface is simply a combination of smaller components.
For example, using your basic HTML/CSS skills, you can create a button. Then, create an input field. Then, put those together in a div and use a few lines of flexbox layout css to arrange the two pieces. Maybe you want something below it, which responds to what you input? Create another div below this input/button div, and then put this whole thing in another div to contain it all.
Try thinking of user interfaces in terms of rows and columns. More complex user interfaces are simply rows of columns of rows of columns! Start with small, basic pieces and put them together.
“vi
Oh boy. Here we go. Type vi index.html. This going to open vim which is an editor that's all in the command line.”
Not to sound pedantic, but vi is not vim. While vim was designed as vi-improved, instructing users of vi to use vim direction is not going to be a complete match and may cause confusion for those not familiar with it.
CentOS:
[jachee@jachee:~]
[00:12:29] > ls -l $(which vi)
ls: cannot access alias: No such file or directory
ls: cannot access vi='vim': No such file or directory
-rwxr-xr-x. 1 root root 2294208 Oct 30 2018 /usr/bin/vim
[jachee@jachee:~]
[00:12:53] 2 > which vi
alias vi='vim'
/usr/bin/vim
Homebrew:
[jachee@gyrate:~]
[00:14:15] ▷ ls -l $(which vi)
lrwxr-xr-x 1 jachee admin 29 Aug 6 11:14 /usr/local/bin/vi -> ../Cellar/vim/8.1.1800/bin/vi
[jachee@gyrate:~]
[00:14:28] ▷ ls -l /usr/local/Cellar/vim/8.1.1800/bin/vi
lrwxr-xr-x 1 jachee staff 3 Aug 3 12:17 /usr/local/Cellar/vim/8.1.1800/bin/vi -> vim
No-Homebrew Catalina:
[jacobachee@jachee-mbp15:~]
[00:17:24] ► ls -l $(which vi)
lrwxr-xr-x 1 root wheel 3 Nov 19 11:46 /usr/bin/vi -> vim
