Jason Knight

The less code you use, the less there is to break

Oct 6, 2018

If using semantic markup -- A SICK EUPHEMISM FOR USING HTML PROPERLY -- 'slows down' your development time OR results in a slower site, you either don't know enough HTML or CSS to be building websites, or you don't know enough about HTML or CSS to be building websites.

I realize that is in fact only one thing, but it's so important a sticking point I felt it warranted being said twice!

HTML exists for MORE than just the users on your perfect resolution screen -- it's for the blind, it's for search engines, it's for TTY, it's for EVERYONE. That's the POINT! As such if you don't have semantic markup, you're telling users on braille readers, screen readers, and even search engines to go F___ themselves!

As the joke goes, search engines don't have eyeballs.

You MUST have that semantic markup first if you care at ALL about accessibility. Likewise maintaining separation of presentation (CSS) from content (HTML) also allows you to customize your presentation (visual or otherwise) with your media targets like print and aural.

It's why the idiotic presentational tags and attributes that NEVER should have been added to HTML in the first huffing place (FONT, CENTER, ALIGN, BORDER) were stricken from the specification twenty years ago, and why today if you're going to slop out classes like "text-center", "clearfix", "w3-red", "col-4-s", etc, etc you might as well go back to writing HTML 3.2 with tables for layout pretending CSS and the past two decades of progress doesn't even exist!

In fact I think that's what annoys me most about 'frameworks' -- they seem crafted to meet the wants and desires of developers who never extracted their craniums from 1997's rectum. Aka the mindless horde of derps who spent 1998 to 2012-ish vomiting up HTML 3.2 under 4 tranny, and today just squeeze out the same outdated outmoded mentally-enfeebled methodologies with HTML 5's lip-service doctype wrapped around it... Whilst patting themselves on the back over how "modern" they are as they pump out markup techniques that should have died off the same time as Princess Di!

People always talk about frameworks as being simpler, or easier to learn, or the all time classic "makes you more productive" -- in my experience ALL of those claims are nothing more than lies to cover up for impotence. They make you write two to ten times the HTML needed to do the job, they encourage sloppy practices, they piss on separation of concerns from orbit, they introduce specificity hell to debugging, and just plain flat out reeks of being made by people who want to bring back all the things we've spent twenty years trying to break developers of doing!

Frameworks make MORE code, SLOWER code, HARDER to maintain code, HARDER to develop code... so where's the advantage? I don't think I'll ever comprehend how writing more code that relies on more code that relies on having to learn even more stuff on top of the basics that results in pages that are accessibility disasters is something ANYONE would use by choice, much less defend the use of.

I gave up on trying to follow the video though, he's hard to follow. I suspect he made that video so utterly faded you'd think he just got out of a meeting of the minds between Tommy Chong and Snoop Dog. Honestly 30 seconds in I was all "Christmas on a cracker, get a load of this stoner". Speeding it up helps a little, but not much.

But as I always say with tech' videos, anybody got a transcript?

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.

Search Hashnode