Write less code and fill fewer holes – Medium

I’m not the most talented programmer in the world. Yes, I know it’s true. So I try to write as little code as possible. The less I write, the less I break, and the less I have to tweak and maintain.

I’m lazy too, so I think I’ll just get by.

However, it turns out that the only effective way to make the Web efficient is to write less code. Code lite? Compressed code? The cache? Okay, that sounds really fancy. Do everything in your power to refuse to add code or import code written by others at the source? Now you have come to the point. Solving one problem leads to another, and your task can be painful.

And that’s not all. Unlike optimization goals for visible performance gains — if there are visible optimization points, you still need to write more code, but think about it — less code can make your Web application cheaper to use. The content of the data I receive doesn’t matter if you send it in small chunks or in large chunks, it all adds up to be the same.

My favorite argument for writing less code is that you should only do what you really need — what your users really need. Put a light on the button? Don’t say daoguang, plus Kangxi also do not do. Introduce a bunch of third party code to add social buttons and ruin your page design? Kick them out of the way. Customize the user’s right mouse button with JavaScript to display a custom modal dialog menu? For the moon to destroy them.

It’s not just about introducing code that breaks the UX design, it’s also about minimizing your own code. Here I offer some ideas that will help. I’ve written some unnecessary code for accessibility and responsive design. As a result, I’ve learned that a flexible, frictionless Web requires as little human control as possible. Only unwritten code never needs to be rewritten.

WAI-ARIA

First, WAI-ARIA(Web Accessibility Initiative – Accessible Rich Internet Applications) does not equal Web Accessibility. It’s just a tool to improve compatibility with some assistive technology when needed, such as support for screen reading software. Therefore, the first rule of ARIA use is not to use WAI-aria if you do not have to use it.

For Demacia! Don’t write: (LOL, no: LOL stands for Laugh Out Loud, but I intentionally translate it to 😂)

 role="heading" aria-level="2">SubheadingCopy the code

It should read:

SubheadingCopy the code

The advantage of using native elements is that you don’t usually need to script your element behavior either. Looking at the checkbox implementation below, not only is the code tedious to write, but it also relies on a piece of JavaScript to control state changes to simulate follyfill out the basic behavior of the browser-standardized name attribute and HTTP GET. This obviously requires more code and is not as robust. Funny, right?

 role="checkbox" aria-checked="false" tabindex="0" id="checkbox1" aria-labelledby="label-for-checkbox1">  class="label" id="label-for-checkbox1">My checkbox labelCopy the code

The reason for that is to think about style, right? Never mind, if you really need to customize styles, you can.

 type="checkbox" id="checkbox" name="checkbox1">  for="checkbox1">My checkbox labelCopy the code

Grids

Do you remember ever enjoying using/reading a web page with more than a three-column layout? I don’t find that enjoyable. Too much stuff piled up and interfered with my concentration. “I wonder if something that looks like a navigation bar is really the navigation bar I want?” I left the site because it was too convoluted and my task was interrupted.

Sometimes we really want content to be stacked. Like search results or whatever. But why introduce an entire clunky grid framework template just to do this? Flexbox can do this with three or two declaration blocks.

.grid { 
  display: flex; 
  flex-flow: row wrap; 
} 

.grid > * { 
  flex-basis: 10em; 
  flex-grow: 1; 
}Copy the code

Everything is now “twisted” to about 10em wide. The number of columns in a row depends on how many 10em wide cells the viewport can hold. All right, go ahead.

And then, when we get here, what the hell is this:

Width: 57.98363527356473782736464546373337373737%;Copy the code

Did you know that accurate measurements are calculated according to a mysterious ratio? An awesome magic ratio? No, I don’t. I’m not interested. I just want the action button to be big enough for me to find it.

Margins

We did this. Share margin definitions with elements using a common selector. Rewrite it only where it needs to be changed, nothing more complicated.

Margin-top: 1.5mm rem; margin-top: 1.5mm rem; }Copy the code

No, universal selectors won’t break the performance of your page, so don’t be fooled.

Views

You don’t need an entire Angular or Meteor or something to separate a simple web page into a “view”. Views only control the parts of the page you can see and the parts you can’t. CSS can do this too:

.view { 
  display: none; 
} 

.view:target { 
  display: block; 
}Copy the code

“But single-page apps need to execute code when they load the view!” I knew you were gonna say that. I’ll just use the onHashchange event. No libraries are needed, just standard bookmarkable links. This is great. There’s more on this technique if you’re interested.

Font sizes

Adjusting font sizes can really make your @Media block swell. That’s why you need to take care of your CSS. This can be done with one line of code:

font-size: calc(1em + 1vw);Copy the code

Well, that will do. You even have a minimum font size, so fonts don’t get too small on the phone. Thank God Vasilis taught me that.

10k Apart

Like I said, I’m not the best programmer. I just know a few tricks. But understand that every little bit more can destroy a lot. That’s the premise of the 10K Apart competition — to find out what can be done with 10K code or less. The prize for winning this competition is high, and as a judge, I look forward to discovering amazing ideas and implementations. I wish I could come up with good ideas myself. What will you do if you take part in the competition?