I would recommend linters (ESLint) to beginners as I use it as a long time not-beginner to point out silly mistakes, which can be the hardest and most frustrating to spot.

> [T]hey’re as useful to learn coding as it is to use ready-to-heat-up dough and buns to become a baker.

I would imagine getting a familiarity with a new oven would be a good use for a new baker experimenting with ready to bake items.

I get the feeling the author is into a very brutal style of learning that might resonate with some, but probably not most with their steps.

This is from 2018 and updated last in 2019, but the title didn't show that.

I was gonna point out the same. Linters are great, for newbies and professionals alike. If you don't like a rule you can change it. I'd say: As a newby, just don't change any rule and use standard settings.

I remember adding a linter to a relatively large project that I was working on after a few months and then realizing how many errors there were that I was surprised the project even worked in some cases (it probably didn't but I never bothered testing those edge cases).

Plenty of projects that are actually fine blow up linters.

If you to want to add a linter you can either add one rule at a time or make it part of your process that the number of warnings goes down with every merge.

In that project it was about 100 or so errors that were all really easy to fix (no major refactoring required) so I just sat down and went through the list one by one until I had 0 errors, 0 warnings. A lot of the errors were just styling. Some were errors where the value could have been null/forgot a try-catch block (although almost never was in practice unless I changed some code elsewhere accidentally), and a few were so major that one of the features that I implemented wasn't working at all but I never realized (mostly because I was one of the few people using the app and never really tested the feature).

I constantly need to add a couple of exceptions to the defaults though. And only because it's pretty weird syntax to let you get the block level meaning become obvious for a small part of the otherwise current standards we are using. (Whenever the indentation fights settle down...) Couple of constants look good together if you look at their semantics, but the rest turns into a mess!

I do not recommend using a linter in beginner or small-team projects. Instead of spending hours and hours switching between white space conventions, that time is better spent testing the web/app in different browsers, not just Chrome and Firefox, but also mobile and embedded browsers, and less known browsers like Dillo and Konqueror.

There is no reason to spend time on it. Pick a standard, create some shared editor config files or have the linter fix the code as part of the build (like gofmt).

I would argue that reset style sheets or normalizers should be part of your "minimal web dev" process, even if you roll your own version. There are so many browser nuances that these things fix so that you don't have to hack it later down the line.

I think the idea is for you to build your own reset as the need for each individual feature comes up, instead of just throwing in a style sheet and not bothering to understand it.

For example, setting the box sizing properly in order to ensure consistent widths regardless of borders or padding.

Also add polyfills.

Few devices (usually the slightly older fw locked devices) which can get a reuse on local net will get some reuse benefit if you added polyfills. I am doing this by conditional "polyfills with SSR" with nginx/lua at the moment. (kindle os/etc. is a pretty good catchall proxy for those browsers; since they still show some html, you can get a very reliable static+interactive (page refresh syncs nicely with the latency) use out of them. (actually, just to periodically update the view of some react page, running headless...)

Edit: Well, that's an extreme, but it has happened that latest react code won't work on a newly unwrapped device still awaiting next fw update).

that used to be true but in 2020 the differences aren’t significant when it comes to css anymore.

We need less cargo-culting, not more of it.

I recently started a new project using only pixi + vanilla js. No frameworks. No npm. Just pixi.min.js + vanilla js included into an html file. It's super refreshing - the js files are tiny, the load times are insane (instant), other people can read my code without having to learn a new framework.

I am thinking about using npm to get access to linting, uglify, etc. but that would be strictly for distribution, not development.

Never heard of Pixi. What are you using it for?

https://www.pixijs.com/

A video game. A week ago there was a HN post on ct.js[0], and that's when I discovered pixi.js. I suppose I could have also used phaser.js, but pixi is more minimal and I liked the idea of developing a custom engine for my game idea (apart from the rendering bits).

[0] https://news.ycombinator.com/item?id=24176655

I worked on a game for a couple of years and did the same thing. Phaser was too clunky for my purposes and didn't seem to scale for the size of game I was working on. I learned a ton by having to write a ton of the rendering/camera logic that Phaser gives you for free. Highly recommend it for learning purposes alone!

Other people can read your code, only as long as you do not uglify it. If you uglify it and ship source maps, that might be OK, but seriously it's not worth it for a minimalistic approach. It will only waste your time.

As an experienced back end developer that has done a bit of ASP/JSP/PHP in the past but really tried to avoid JS. What is the best place to start now? I figure react is #1 but vue looks simpler. Any moocs or books worth reading first? Or dive in and build something?

Skip the frameworks, start with modern ES5/ES6, don't use babel/ts/etc initially.

Modern JS is pretty clean and the native DOM methods are actually very pleasant generally. You can get really far without even needing a package manager, but eventually something like npm becomes useful if bulky.

Further, you will then understand why you need a framework like React should your project become complicated enough on the frontend.

There's nothing stopping you from tracking client state in a a simple window.state object. This object can be of arbitrary composition, so I see no reason you cannot manage even the most complex UI state in this manner.

For me, minimal web development means doing as much as I can at the server. This includes tracking client UI state if feasible. The more stuff you have in 1 domain like that the easier it becomes to control complexity.

When your state machine is split between 2 realms is when you get into traps that things like React were created to resolve.

I agree that if you have state in two places you're doing it wrong. That's why I keep all my state client-side (the only thing in session storage is your user ID if logged in). My server is basically just a thin wrapper around my database, providing an API for my client to call.

The problem is there aren't many guides for learning "vanilla" JavaScript that aim at newcomers. MDN is a good reference, but I can't think of something more directed tutorial.

If you're interested in learning vanilla JavaScript through an online course, you might like to try Execute Program: https://www.executeprogram.com/

I found it more thorough and challenging than others I've tried, but it doesn't assume any knowledge of JavaScript.

I have a question about an embarrassingly simple problem: "Element Access". Is there a way I could contact you about it?

If by “Element Access” you mean getting pointers to DOM elements, try querySelector [1] or querySelectorAll [2]:

  var element = document.querySelector(...)

  var elements = document.querySelectorAll(...)

[1]: https://devdocs.io/dom/document/queryselector

[2]: https://devdocs.io/dom/document/queryselectorall

Feel free to email me. My Gmail address is "parodieslost". Although I'm not affiliated with Execute Program, I have done the JavaScript Arrays course (including Element Access), and I'd be interested in your problem.

I'm more a back end developer myself, but have really enjoyed Vue. My recommendation would be to try a few basic intros to Vue, but try to avoid the ones that want to get you set up with a whole bunch of command-line tools to compile/pack/whatnot the project. (Those can feel quite daunting to start with, and are actually not necessary if the size of your project doesn't require it.)

Just include Vue from CDN as a script tag.

And if you want a jump-start with ready-made components and good styling, I can also recommend Buefy - https://buefy.org/documentation - like Vue, it can also be included with a simple script tag, without any command line tools.

I like Bulma and Vue, thanks for mentioning Buefy, had no idea it existed.

I think they're a great combo. Had always been scared off from modern front-end work because it seemed to involve a whole bunch of intricate dependencies and build tools. So it's been eye-opening to see just how much you can build with Vue and Bulma (with Buefy making components very easy to use). And I've not yet needed to touch npm/yarn/webpack or any of that stuff for my small projects.

Buefy is my favorite. Most productive I've ever felt on frontend. But it is a little limited compared to most other component libraries, so YMMV but I really love it.

Would be interested to know what you find its limits to be, and what you'd recommend as something more flexible than Buefy.

Don't forget about CSS. Since it's easier to learn than to unlearn, do yourself a favor and start at https://every-layout.dev

Full access to the site / book / codebase costs $100, but the free content alone is worth more than that. Can't recommend it highly enough. Axiomatic CSS, composable layout primitives, and profoundly well-researched and -designed solutions to myriad real-world problems with accessibility and maintainability...

I've been doing web-related stuff for a living since 1998, and have literally never encountered a better resource for getting the hardest part of FE dev right, using standards and building up from first principles.

PS The site's examples implement layouts using HTML and CSS, and the paid version includes a Web Components implementation (trivially translated to React, or integrated / embedded w Vue).

Eloquent JavaScript and the You Don't Know JavaScript series are my favourite books. Both available for free online.

Depends on what you want to do. For work, yes React is king and has an absolutely huge ecosystem built around it. For fun? I'd look into Svelte, fixes a lot of the pain points of React and Vue. Also the Javascript DOM API has come a long way itself and IMO, while a library/framework is helpful if you're building a complex web app with lots of states, the great majority of websites out there don't need a framework and can be built statically with something like Eleventy.

Svelte is even simpler to learn than Vue and has the benefit of having a much smaller/simpler/more efficient runtime.

As a backend dev, it's what I wanted frontend work to feel like when I started learning frontend.

Depends on what you're doing. In general, getting a handle on vanilla JS and the HTML DOM first is a good idea, as everything starts there. If you just want to make web pages move a little, you can stay there.

If you want to do anything with much state or user interaction, a reactive framework becomes useful. Vue is really quite friendly.

As to how to learn, I've been doing it too long to have a good recommendation. Probably read a JS book, it's a bit of an odd language with a lot of wrinkles.

In addition to what the rest of the comments are saying: if you're talking about front-end Javascript, take the time to really learn the devtools in your browser of choice (personally I'd recommend Chrome or Chromium, but I'll grant that I don't have a whole lot of experience with Firefox.) It's basically an entire IDE right there waiting for you to use. (With a little bit of futzing, you can even use the Chrome devtools as a debugger for Node.JS, which absolutely blew my mind when I first gave it a shot.)

I absolutely love Vue, but i would think twice or thrice about using any client side framework. If you can, just use e.g. ASP.Net with Razor to create your website. Depends on what you need it to be able to do ofcourse.

I'm in the same boat. I want to try something like Flutter to keep the JS madness at arm's length. Not sure if going that way will make it worse or better though.

Well, you could... take a look at article that you are commenting about.

Whatever you choose, make sure to use strict TypeScript from the very beginning. You won't regret it.

I'm sorry, but any guide that suggests you start by reading the entire specs for HTML, CSS and JS is just not realistic.

The guide gets it right in the "practise" part, though: the beauty of the web is that you can write an HTML file and immediately see what you created in the browser. You don't need to read the HTML spec's instructions on Microdata before you do that.

Few people have probably read those specs cover-to-cover with full attention.

But never opening them is a mistake. The value of taking a look, skimming around, reading a few parts that seem interesting to you, is HUGE compared to never even having looked in there. And then continuing to do so when a curiosity arises.

This is not a beginner’s guide, and the author acknowledged he himself has not read the full spec - it’s merely encouraged as a reference to go back to.

I feel like for mastery the recommendation to read specs is a valid one. Not necessarily in their entirety, but they're worth exploring. And the HTML/CSS standards also often are useful as references.

Agreed. In my experience, I've learned more from reading MDN than specs.

It is very realistic. The first thing I did when I got interested in HTML was to print out the spec. I do not get this attitude that blindly poking around for hours in hope to stumble upon something that works is superior to reading the docs.

This article is pure poison. Ideological purity is a problem in every facet of human life, and engineering doesn’t have to be so painful. The computer should work for the human.

Just two more generations and writing vanilla js/css is an elitist skill for ancient blue whales.

I think this is a great counter-argument to the current state of the frontend development ecosystem, which is far from minimal. The article might be too extreme, but I would love to see more minimalism on the general approach to things.

Strange no one has yet mentioned Resilient Web Design Book https://resilientwebdesign.com/

Besides those principles I find Pug to be indispensable for writing "pythonic" style HTML https://pugjs.org

You can rearrange the structure easily by "moving" lines of code up or down in your editor, you can set it to auto-compile on saving, just awesome.

As someone who developed web applications appx 20 years ago and back doing it for a few personal projects in the past couple of years, I am a bit disappointed in the progress that’s been made in the web development space.

Edit: specifically front end.

As someone who did the same for the same amount of time: it could not be farther from true.

How so? Any examples?

Front end is generally pretty robust these days. Especially with cash grid and flexbox.

Static site generators are great if you do plain/vanilla static HTML sites. Server-side-include only gets you so far, a static site generator give you much more freedom and it can do a lot more work for you.

What is someone is trying to build a blog? I think the most minimal web development for building a blog comes from Static Site Generators that the author is suggesting to avoid.

You can't get more minimal than Hugo, Jekyll when trying to build a blog. My blog is fully functional and apart from Google Analytics, it doesn't use any JS at all.

> You can't get more minimal than Hugo, Jekyll when trying to build a blog.

Untrue.

> My blog [...] doesn't use any JS at all.

Now suppose there were JS used on some page(s), and that is the static site generator...

This isn't minimal, it's primitive. Knowing the difference is key.

Stopped reading at "Did you know? Not blocking ads helps content creators[...]" How are you gonna advocate for a minimal web when you're so oblivious to adtech current year?

This webpage which is a guide to hand coding things appears to not have a closing </head>, </body>, or </html> tag.

That is completely valid HTML5.

https://html5.validator.nu/?doc=https%3A%2F%2Fmeiert.com%2Fe...

That maybe but it differs from what is shown in the inspector (which shows the <head> and <body> tags). This could be confusing as the source html doesn't match how the browser interprets it.

Web inspectors are showing a representation of the DOM, they are not showing the raw source. Netscape and IE used to have "Show Source" functions that literally showed just the page source.

Inspectors will do things like display colors as their RGB triples i.e. rgb(x, y, z) in computed styles when a color has been defined in the HTML like in a body tag or table cell's bgcolor attribute.

All browsers still have show source. It's just not usually that useful anymore.

Yes I am aware. It can be confusing if you are new. I had someone ask me why it was different the other day.

Just because it is valid does not mean you should do it.

That's true. The reasons to do it are in the article.

TIL!

Others have pointed out that this validates with automated tools. Here's the parts of the spec:

- "An html element's end tag can be omitted if the html element is not immediately followed by a comment." https://html.spec.whatwg.org/multipage/semantics.html#the-ht...

- "A head element's end tag can be omitted if the head element is not immediately followed by ASCII whitespace or a comment." https://html.spec.whatwg.org/multipage/semantics.html#the-he...

- "A body element's end tag can be omitted if the body element is not immediately followed by a comment." https://html.spec.whatwg.org/multipage/sections.html#the-bod...

Personally, I prefer to close all of my elements, it avoids having to worry about accidentally triggering one of these hard-to-spot edge-cases.

And yet, it validates - https://validator.w3.org/nu/?doc=https%3A%2F%2Fmeiert.com%2F...

Neither of the three tags you've mentioned are required anymore in HTML5.

They weren’t required before HTML 5 either.

Your tone suggests that you think this is inconsistent.

However, I think it's evidence the author read the specifications as recommended.

The author mentions something about omitting HTML tags and links to another article of his own, which could explain this (I haven't read it yet):

https://meiert.com/en/blog/optional-html/

You do not even need the opening tags for a correct HTML5

It was the case in previous versions of HTML too. Here is my minimal document from 2005: http://rimantas.com/bits/minimal_html.html

That being said, I very much like the spirit of the document. Many many good points.

small gripe, vanilla is a flavor. Please use plain javascript.