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.
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:
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.
My personal landing page(s)/website is hosted on GitHub pages. After two attempts, and at both the occasions I just blindly followed tutorial steps hoping it will show as it should - it did but I didn’t understand a thing, I am back to vanilla HTML/CSS and zero JS (I just didn’t need it). I really like it now. If I have to edit something I just change the text needed.
I am planning to add a blog to this landing portal and debating whether I should have comments on it or not. Because if I’ll have comments I’ll have to deal with complicated libraries and add-ons.
Maybe I’ll just have static HTML files linked from YYYY/mm folders as my blog posts and maybe some simple JS for next/previous if at all (in that case I’d want to name individual post files with some discipline so that I can parse it easily later)
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?
If you're just building a website — i.e., not a highly interactive web application — here's what I'd recommend. I've been building websites since 1998, FWIW, although I'm now a stupid product manager, so take this with a grain of salt.
1. Write semantic HTML in a sane, human-centric order. Do not write any CSS yet.
2. Open your new web page in a browser. Imagine CSS doesn’t exist and you’re stuck with whatever the browser gives you forever (shudder). Is your site well-organized? Is it easy to read, to navigate? Are the most important elements on your page afforded the appropriate level of prominence?
3. Imagine everyone looking at your website reads every line of HTML top to bottom. You’re not allowed to use classes or IDs. Do your readers know what, say, the title of your blog article is? Do they know where the navigation is?
4. Do you have multiple page “types” (e.g., blog post, blog index, about me, home page)? Do this for all of those types. Don’t forget to keep making your HTML semantic. Copy and paste similar bits (navigation, etc.) from pages you’ve already created. Yes, if you make changes to one, you will have to change both.
5. Once you’ve done all of these, put a <style> tag linking to a single vanilla CSS file in the header of your simplest page. Start adding styles, beginning with text styling. Can you still tell that links are links? Is it still easy to find the navigation? Do headers look like headers? Good.
6. Did you have to pollute your HTML with a lot of classes to accomplish what you wanted to accomplish, design-wise? This might be OK, but you probably added too many. Can you accomplish the same thing using semantic elements instead? Do so.
7. Copy that <style> tag to the other pages. Do they look pretty decent? They should. Add whatever additional styles those pages NEED.
8. Yes, it does suck having to copy and paste all these repeated blocks all over the place. Find a static site generator or use something like CodeKit[1] so you can use simple includes rather than configuring the mess that is most static site generators. I use a static site generator for my site[2] for fun but don't really need one.
1. Get a better idea of the tools already at your disposal (HTML5, CSS3). I can recommend Dive into HTML5 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.
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.
If you use a project generator like Next.js or Gatsby you can have a project with the advantages of React that also compiles down to static files with only one line of setup. Imo it's just as easy as what the author does except it also comes with optimizations like pre-fetching.
Do you find * { box-sizing: border box } to be necessary? I don’t know why people need to set it for everything when it only makes a difference in a specific situation.
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.
I used to do that, still do once in a while, but I find Ansible to be much better for provisioning and configuring things. I rarely use modules that are not part of the base install; in fact at present I am not using any that aren't standard. I feel my playbooks are simplistic compared to what I see others doing, but they work for me. The idempotency and error checking that Ansible provides are well beyond what I feel is worth rolling by hand, so it's a good tradeoff. I can still write simple things that I understand.
I could say I am, except that I just use plain sh running under openbsd instead. Not only for web stuff, but I also use simple unix tools a lot to process data - a lot simpler and most of the time it's even faster than using SQL or so-called "big-data" tools.
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.
"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.
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.
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?
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.
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.
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.