Jason Knight
My bad. I extracted the following transcript from the video via .srt file. (removed all the parts that are mere babblings and not applicable to the discussion)
================================================
Hi, I'm Travis, and this is dev tip!
So, today, I want to spend a few minutes answering a question. This question was left on a recent video we did about CSS frameworks.
I love this question, so I wanted to share it with you. Here is the question.
I've been a software recruiter for over 20 years. During that time I've seen a lot of technology come down the pipeline, and more than my share of trends.
That said, one of the trends that I've seen is the heavy reliance on frameworks and tool sets by new developers. This has become increasingly prevalent in the past five years. For instance, rarely do I not come across a junior front-end developer three years or less experienced in my book claiming to be a "expert at JavaScript" yet has confused it with jQuery or believes that they are one in the same. I say this because when I send out code exercises specifically asking for a JavaScript solution, they send it back using jQuery, then I end up explaining the difference using a few examples of my own, and they think that I don't know what I'm talking about. LOL
And the div soup today is scary. For instance, when I send out HTML and CSS exercises I frequently get the HTML back using some sort of grid system buried in a sea of div tags when I specifically asked for HTML 5 using current semantic markup.
I guess my question is, do you see a hazard for developers getting too hooked on tools that offer a lot of shortcuts and reduce development time? Is there a danger in losing the fundamentals not learning them at all or even properly? Also, at what point in a developer's career would you say is the right time to pick up a development tool, for example, Bootstrap and jQuery?
Again great show, I look forward to many more videos! Also I know that I may have hit a few hot buttons for some readers. So please keep the comments civil.
Isn't that a fantastic question? It's phrased and framed perfectly. Thank you so much for asking it!
Now I'll take a crack at giving my perspective on it. I have never used a framework in one of my personal projects in the past. I've considered them very hack. I think this is because when I learned to code frontends it was back in the day when the idea of Semantic Web was a big deal. It was a big deal in the evolution of the industry and even in the technology itself the very idea of the thing which you so eloquently identified as div soup has always been a very repulsive thing to me. That is until very recently. Being the only designer in a sea of very talented software engineers in my office, I took it upon myself some time last year and created what has become known as the pattern library in the office. The idea originally was to create a set of sass mix-ins that were super cool and super smart, and you could use them to create a beautifully marked up and semantic DOM. And also to provide a number of useful tools to the engineers when they were writing their own SASS.
I thought it was amazing and wonderful, but the engineers ignored it. Why? Because they didn't necessarily care about a semantically marked up page. It's a good thing to have, and they respect it and they understand it. But it turned out that it was not the goal for them. So what is the goal? Speed speed SPEED! Speed. As much as me saying this would make me cringe about six months ago, I understand now that building your interface quickly is more important than making sure that your class name describes your content. When you stop and think about the three building blocks of a rendered webpage; HTML CSS in JavaScript, it becomes obvious why this div soup method is the fastest way to go. The HTML part is the most tweakable and the most commonly changed-out component in the whole group. Whole javascript libraries are being created now not only to talk to servers and gather interpret data and manipulate the DOM in little spaces, but really to render whole entire webpages. Angular, backbone, ember, all of these abstract the markup to JavaScript modules to be inserted in the page as needed. Now, if I'm thinking like an engineer and I'm used to chopping up webpages and spitting them out in different ways, then changing a simple class name to get a visual effect is a natural extension of that paradigm. If you made an engineer that's not great at hands-on CSS stuff, that's because you don't use JavaScript to manipulate style sheets. Use JavaScript to manipulate the DOM and add inline Styles or a new class. So, if the name of the game is speed and you'll already have a set of common conventions or a framework of ideas that will quickly manipulate the DOM to create a visual experience, that's exactly what's going to what you're going to use, and this is why a new front-end framework pops up literally every other day.
Now, in my pattern library at work I finally understood that engineers really want to rapidly prototype ideas and not fuss with semantics. Indeed it's been said that the two most difficult parts of computer programming are, number 1, cache invalidation and, number 2, naming things. Naming things! One of the hardest things about computer programming. So, that's what I did with my library. I output all these very smart mixins into common classes. I divided the classes into an atomic structure and I worked very very hard to document everything. Basically I tried to make it as fast as I can, not performance but usability. Usability for engineers to use.
Now, that doesn't mean that the CSS output is not optimized and it doesn't mean that the markup is not semantic, but the focus is no longer on those things. The focus is on speed. Now, the adoption of my patterns has been a lot greater since then, and, because it's actually faster, the engineers can prototype ideas much faster.
Now, on this channel we have this series where we're looking at these different grid frameworks and this is mostly the first time that I've ever used them, and I've been pleasantly surprised on how well they make good on their promise to build prototypes faster. But, therein lies the rub, right? Their promise is clear but often it's confused by people looking for a shortcut. If you consider the names of these frameworks, bootstrap, foundation, we can see the intention of the authors. These are intended to be tools on top of which things are built. Their danger, though, is that they can be too useful, right? They can be a crutch. In as much as it can be easy to think that being proficient with these frameworks is the same thing as understanding how they work.
So, to answer your question, yes, I do think that it's unwise to use tools that you don't fully understand. Furthermore I think that it can be dangerous to make that practice a habit....
...I don't think that there's a wrong or a right time to pick up frameworks, but I do think that it is always a bad to use a framework if you don't understand how and why it works...
...I think that they can be a great learning tool. Most of them are put together by amazingly smart and talented people with real-world experience. Picking up a new framework and trying to understand it as much as learn how to use it will take you very far, I think.