
It’s 2019 and I Still Make Websites with My Bare Hands - cpach
https://medium.com/@mattholt/its-2019-and-i-still-make-websites-with-my-bare-hands-73d4eec6b7
======
apo
_I’m not even kidding, this is how I still make websites: I open a text
editor, and stub this out (by hand, it only takes like 30 seconds — I’ll even
do it as I write this post to be authentic — except stinkin’ tab doesn’t work
here):_

    
    
      <!DOCTYPE html>
      <html>
        <head>
          <title>I code stuff with my bare hands</title>
          <meta charset="utf-8">
        </head>
        <body>
          Hi there
        </body>
      </html>
    

_Then I open a new tab and make a CSS file; something like this:_

    
    
      * { margin: 0; padding: 0; box-sizing: border-box; }
      body {
        font-size: 18px;
        color: #333;
      }
      p {
        line-height: 1.4em;
      }
    

Same here. The main advantages are brevity, speed, and debuggability.

Having tried CSS frameworks like Bootstrap on the one hand and vanilla
HTML/CSS on the other, I really don't see the attraction of frameworks.

It's not hard to quickly build something that works decently without
prefabricated components. In the later phases of a project, I find it much
easier to maintain a code base free of third party material.

~~~
sho_nuff
I am interested in learning this style but keep getting drawn into some
frameworks. What order would you recommend learning to create sites in this
style?

~~~
apo
I can think of two approaches:

1\. Get a better idea of the tools already at your disposal (HTML5, CSS3). I
can recommend Dive into HTML5
[http://diveinto.html5doctor.com](http://diveinto.html5doctor.com)

2\. Start building. Literally, start with the barebones Hello World given in
the article. Then gradually turn it into your site, making liberal use of
Stack Overflow (direct search) and Google.

~~~
mmsimanga
Thanks for the link. This whole thread is refreshing. I am someone who does
not do web development for a living but occasionally builds a website. Every
time I start building a new site I am at a complete loss where to start. Yet I
have been doing HTML and CSS since 1999. I am going back to basics, starting
with your link.

~~~
raywu
Open web inspector when you develop a website. You can get a better feel for
how changing CSS on the fly take place on the actual webpage.

I would save a copy of the HTML from the top level comment of this thread and
use it as a base to start any new project.

I like to start from scratch and add Bootstrap should I need responsiveness
once I get to that point. L

~~~
mmsimanga
Thanks for the tips.

------
jaredcwhite
Great article, but the takeaway is something so profound I fear a lot of
people will miss it entirely when getting into the details.

It is:

Understand your tools.

And a second but equally important takeaway is:

Use the least amount of tooling to implement your functionality.

If you understand your tools and you use the least amount of tooling in order
to implement your functionality, your website or app will be easier to
maintain, more performant, possibly more secure (less code = smaller surface
area of bugs and other problems to exploit), and it will train future
developers in a more sane art of programming.

I recently inherited a codebase that was a monstrous combination of a Rails
backend broken out into multiple namespaced modules + a giant grabbag of
service objects + a React front-end with a shocking number of various
components — all to accomplish a relevantly small number of basic web app-ish
things. (And to top it all off, it was a failed product and I'm only working
on it now because a biz dev friend of mine had purchased the product from the
original devs.)

All that extra "web-scale" work…for a product that didn't even succeed. They
probably could have _halved_ their dev time with a vanilla Rails app and some
simple JS sprinkled on top (Stimulus for example), it would have worked
perfectly fine, and they would have proven the app in the market (or not).
Wait to get a thousand paying users — THEN rewrite with whatever fancy-pants
frontend framework and microservices backend you like.

We really need to do a better job as an industry of pushing back against
complex tools and complex development processes until they're _absolutely_
necessary. Don't reach for a jackhammer when a chisel will do just fine.

------
AznHisoka
Is anyone else the backend version of this? Instead of using Docker,
Kubernetes, AWS, etc. write your own bash scripts to provision servers, deploy
code, etc.

Instead of using fancy monitoring frameworks, just have a cron job that SSH
into all your servers, and send an email if disk or memory usage spikes too
high.

~~~
j45
Lots of people are the backend version of this. And the front end. In one
person.

If you add the backend skills above to the original post... It's what a full-
stack developer originally was, and in my mind still is.

These folks can imagine a bug, features and architecture from different
breadths and depths.

------
MrLeap
I prefer the workflow that the author does, minus the Jquery just so I can
maintain some street cred. document.querySelector solved 90% of what jquery
solved for me anyhow. For consulting clients, I've done plenty of what I
consider the "exotic workflows".

My determination is that the primary benefits of react, angular, et al is that
they organically create hierarchies among a group of multiple developers. It
also creates a sense of depersonalization / derealization that helps everyone
feel like they're working on their own while they're surrounded by people. Woe
the walls we build!

Proxy was the nail in the coffin for ever using a framework in my personal
projects again. I'll still use whatever your hip new project leader wants for
money though.

~~~
SZJX
"depersonalization" and "walls" is one way to put it. Though think of it from
another perspective: You'd need to keep a team pulling in the same direction
and speak a common language. When one person coded up something without any
framework, they may understand the code structure perfectly, but the others
who collaborate with them can easily get lost/be detoured. Publicly existing
frameworks have conventions, docs and communities and a certain way of
organizing things, which makes it much easier for a team to avoid wasted
efforts.

------
Siilwyn
Erh, I did the same for small personal websites but maintaining the content
and having to change things on multiple pages made me switch to a build step.
I do not understand how the author would deliver a website to clients without
pulling in content from a (headless) CMS.

~~~
mholt
Sometimes you gotta do that. The Caddy blog is run with Hugo after every git
push.

------
xupybd
For web sties this makes sense, but what about applications that happen to run
in the browser. There must be a certain size / number of contributors where
this no longer is the best option?

~~~
naniwaduni
The key is that modal number of contributors is probably 1.

------
darepublic
I used to make websites likewise (html boilerplate, css links and script tags
at the bottom of body). I liked the no frills simplicity of it. But years ago
I switched to using frameworks and don't think I would go back. Yes I _could_
implement my sites in vanilla js and frankly it would be fun! But I would
spend too much time reinventing the structure I get ootb with frameworks.

------
axaxs
I'm not sure I quite get the author's long running (over)use of the term 'bare
hands.'. I don't think the analogy works well in programming, and doesn't
convey what it actually means.

------
dddw
love caddy

------
amerine
Same.

------
Scarbutt
This article is just a poor ad attempt for the author's commercial products.

I don't mind when someone advertises their product through a good article, but
this was way too condescending.

The title is also click bait as in he only occasionally writes extremely basic
static websites for his own products.

