This is more of a manifesto but there is a small movement around simplicity at https://grugbrain.dev/ which is written by the guy behind https://htmx.org/ -- a nice little way to add the bare minimum JS needed for a 'modern' app. You can find a community of likeminded people at HTMX-adjacent places like their Discord and Twitter. I've also been an advocate of this kind of 'primitive' dev style and it's great to see it gain some popularity.

This recent talk from Djangocon "React to htmx on a real-world SaaS product" might be of interest: https://www.youtube.com/watch?v=3GObi93tjZI

Ironically, the ultra-modern serverless platforms such as Cloudflare Workers have strict size constraints which is leading to a kind of back-to-basics approach that minimizes dependencies and bundle size. You can find a lot of small libraries for this at https://workers.tools/. The latest JS framework to buzz here, Deno's Fresh, even touts "no JS is shipped to the client by default". We can see there is a resurgence of interest in server-side rendering.

The classics such as Rails are still alive and kicking. Phoenix seems to be a promising candidate for "the modern Rails".

As someone who experienced the Good Old Days of web development, I would recommend at least trying out the managed cloud services for things like databases and cron jobs and deployments. IMO, it's a lot easier to use them than manage it yourself. And with the new serverless stuff, we're actually pretty close to how CGI on shared hosting used to be where you could upload a script and not have to worry about the gory details so much.

https://developer.mozilla.org/en-US/docs/Learn

So I did the same - circled back to html/css/js first. I'd keep this part very light though. If you can code already (any language) then a couple hours skimming over html/css/js gets you far enough to grasp the absolute basics. After that I'd stick to the "exciting web dev" part and circle back to basics on an adhoc basis.

There is a very real risk of losing enthusiasm here so there is definitely something to be said for rushing towards something that works and does something.

I've found code-along youtube sites to be the best. Traversy Media, Web Dev Simplified and James Q Quick are my go to channels. Also Fireship channel is very useful - they have 100 sec descriptions of most web technologies helpful for "wtf is it and do I need this?".

>`cron` jobs; database persistence; difference/explanations of when to use bare-metal v. vps v. vm; what there is to know about reverse-proxying and load balancers and how to correctly setup and deploy those and so on?

You don't need any of that at this stage. In the medium term a VPS would be useful though...web dev on local machine hits limitations in the sense that local isn't all that "web" and vps is good for learning linux basics too.

The Flask Mega Tutorial https://blog.miguelgrinberg.com/post/the-flask-mega-tutorial...

I’m guessing there’s something similar for Ruby on Rails and Laravel.

For persistence, consider Litestream/SQLite. Or just good old PostgreSQL. Or MariaDB.

https://fastapi.tiangolo.com/

Or look at Django - for something more full-featured in python.

also. loved your LISP pun in your about page for HN :-)

Side note: As a Ruby on Rails developer, it's amazing to see so many Rails-based recommendations to the question "how to learn boring web dev?". This is exactly what Rails (and Ruby) is great at. Just get shit done quickly without the shiny things.

There is a full stack JS track with Node instead of Rails.

If you wanted to learn via video and you want html/css/js, search 'vanilla javascript website.'

Currently "vanilla javascript" usually means a native browser website free of npm/node/ecosystem.

To serve a plan old site like this: google, "how to serve a static website", as that is what you are creating here.

Want a DB or persistence? Now you need an api. After creating your static site, now you need an api on a server somewhere. Any tutorial on creating an api (in whichever language you like) will probably work.

Now you have options,

1) run a static web server for your website (this can be done for free via github pages btw) and run another server for your api

2) run two one single server with two different applications-- your api and you static web server (now you need a reverse proxy)

3) run a single server/api that both serves you static website and handles communications.

Easiest/fastest: get a static site (html/images/css/js) made and up on github pages

For some sort of api, whip up an expressJs app with a node server to handle both serving your static site communication needs.

https://www.railstutorial.org/

Closer to what you want is Free Code Camp, which is pretty good for front end stuff:

https://www.freecodecamp.org/

There is nothing more boring than Rails + Postgres! Maybe Django and Postgres…

My definition of boring is a good looking web page with a CRUD flow and user authentication.

This is an afternoon exercise with Rails, a good tutorial, and a couple gems and a bootstrap theme deployed to Heroku or Elastic Beanstalk.

Compare to having to navigate the latest Typescript, SPA front end, server side component, nosql and serverless deployment hotness.

0. Don’t waste your time dicking around with tools. Save that immaturity for the children you will ultimately replace.

1. Make a new language in XML Schema. This will teach you about node relationships, DOM theory, lexical models, semantics and data description. The things you will learn from this will shape everything else.

2. Learn accessibility. This will expand your learnings from step 1 in a very practical way. Added benefits are better SEO and slimmer more precise HTML code. When I say learn accessibility I mean to take this seriously. It is a qualitative investment and not checking a box in a checklist.

3. Learn CSS. When you really learn CSS well you will gain the confidence to create any kind of visual presentation without ruining your accessible HTML.

4. Learn the DOM. Again, this reinforces everything learned in the prior steps. Walking the DOM in Firefox is as much as 250000x faster than querySelectorAll. The DOM is the backbone of everything in web frontend technology.

5. Now it’s time to learn JavaScript, but I recommend jumping straight to TypeScript. Type everything and keep your type definitions extremely primitive. In TypeScript clever code is very slow to compile.

To really really understand frontend JavaScript well all you really need is a thorough understanding of the lexical scope model, functions, and events. Functions are first class citizens, which means functions can be used anywhere primitive types can be used. If you can understand those three with great confidence you can do 98% of everything you will need in the language.

6. Finally, don’t listen to the ignorance. Most of the opinions I have seen in my 25 years of web development are about what people can’t do and how hard life is, great insecurity searching for validation. Toss all of this negativity and weakness aside. Instead, always focus on what you can do. Less is more. When you push yourself to exceed your potential after great effort you will do what the complainers can’t.

You are on the right track…. strive for simple.

That’s exactly what I aim for when doing web application development.

A React application uploaded to a static web server, talking to a plain old Linux server running a simple back end like nodejs or python, talking plain SQL to a Postgres server.

Do you want server-side rendered app or will your app require client-side processing?

Do you anticipate that the app will, at some point in the future, need to be scaled to multiple servers?

Once you answer these questions, then what boring tech stack to choose will become easier.

One example I will give you of a boring stack, but highly effective, that I know of. Postgres as DB, Wt toolkit for both JavaScript and without JavaScript for hybrid server-side/client-side rendering, and HAProxy for load balancing. That is it. Nothing else is required if you are developing a small to medium sized web project.

Why are you suggesting HAProxy for load balancing?

If you mean web applications rather than (mostly static) web sites then I believe that the boring pragmatic approach is to use React + Typescript, at least for the front end stuff. This is where the tooling, documentation, and community all currently come together in the most cohesive manner for modern web application development - or in other words, where you'll be fighting the tech least, and have the most support when you need it.

I know that's a loaded opinion and I spent years resisting it. But I'm glad I overcame my scepticism.

I would love to be working closer to the metal, in this case meaning HTML, CSS, and JS. I spent the first 5 years of my web dev career doing this. But this means you have to deal directly with several different browser engines running across hundreds of potential devices, you have to deal with bundling your assets, transpiling, worrying about what JS and CSS features you can use - it's basically endless, more than one person can handle. Web dev is inherently many layers of abstraction deep and highly fragmented. By using a framework like React and following their best practices, you let someone else, at least partially, deal with that chaos. That's the closest thing we have to a safe, boring, pragmatic path in modern web dev. Yes it's a long way from perfect and you're still barely surfing above the chaos, but I don't think there's a better option.

You will figure out what you need and what you do not very quickly this way.

It won't be easy, but you'll end up with the skills you need in modern web dev.

And be thankful you did not have to spend a decade dealing with cross browser issues. You have it very easy today.

https://nuxtjs.org/ (I prefer Vue).

https://nextjs.org/

I'm currently working on a course for something like this at https://nickjanetakis.com/courses/deploy-to-production.

It won't cover building the app from ground zero but it'll cover a bunch of patterns in development to build apps in a way that makes deploying them flexible, then the majority of the course focuses on deployment related topics.

I screwed up initially by trying to focus the course on everything (single servers, multi-servers, Heroku, Kubernetes, etc.) but since then I've scoped it down to focusing specifically on the boring case of "I just want to frikken deploy my app" and it'll go through a ton of things around taking a web app you've developed and shipping it onto 1 or more servers while doing everything in such a way where you'll be able to Docker Compose up your project on 1 or more servers (not load balanced but you could split up things like your web, worker, db and cache onto separate servers if you wanted to). It won't do things in a half-assed way tho, you'll be set up to horizontally scale if you need to since we'll stick to creating 12 factor style apps.

The course won't cover Kubernetes but if you wanted to "evolve" your set up to that in the future you'd have a really strong fundamental knowledge base to do that so you could focus specifically on learning Kubernetes, not Kubernetes + the 100 other things you need to know beforehand since this course will cover a lot of those other things.

By all means learn about raw DOM manipulation with JavaScript first, but do not go directly for react.

We are repeating the same issues we had years ago where people started conflating JavaScript with jQuery - people are conflating JavaScript with react l.

JavaScript is an insanely powerful flexible and widely deployed language. It is so much more than just react/jQuery. It is the Lingua Franca of modern computers.

Yep, where is the documentation for modern JS without any libraries?

Preferably something that doesn't try to teach you what an if and a loop are first.

Now where's the equivalent for actually using JS in a modern web browser :)

Why did you immediately jump to comparing JavaScript approaches?

It is perfectly legitimate and practical to build a web application using little to no JavaScript. It is also abundantly evident that consumers and professionals are still happy to pay to use web applications which employ little to no JavaScript.

Backend: PHP with Laravel I haven't used it in a while since I work on greenfield projects now. But when I did, Laravel did wonders. Documentation is complete, everything you need is documented and it's basically copy and paste for all the common things.

Frontend: Hard to say. If you don't need much functionality, just use basic HTML, JS and CSS. Render your HTML with PHP and use the minimum amount of JS you can.

Otherwise I'd say React. I work with it every day and I think it's great. But wouldn't consider it to be "boring" at all. There's new things every day and you need to keep up & navigate the traps.

Unfortunately frontend is still very unstable until now.

You have fronted, backend, UI, database and infrastructure layers at least.

Rather than searching for a resource to cover all poorly, I would focus on a resource that covers each.

You can search Pluralsight, Udemy and Amazon for good tutorials books for: HTML, CSS, Javascript, a fronted framework (I like Vue because it seems more sane), a language for the backend (C#, Java, Go etc.) a framework for the backend, infrastructure (bare metal, VM, Kubernetes, cloud Docker etc).

These would be the bare minimum to get started as just the system design is a complex thing which you can't master with just one book.

Since you deal with complex topics there isn't any book or tutorial that can cover all at a decent level.

There's also the Indie Web wiki which has lots of getting started guides for hosting your own website: https://indieweb.org/Getting_Started

https://pragprog.com/titles/rails7/agile-web-development-wit...

(note, not quite finished yet - last chapters should be done in ultimo January).

https://fresh.deno.dev/

And backend can start as simple as https://codeberg.org/jugendhacktlab.qdrei.info/gaestebuch. You may not even need one to start.

Aren't that exactly the things, modern dev teams trying to avoid to know about in their march into bright future with Lambda/Serverless?

Or from another angle - most of the crowd in the "exciting" camp, decreasing the chances for such book to be born. DHH aka DAVID HEINEMEIER HANSSON ( https://dhh.dk/ ) may be? This podcast was not bad https://podcasts.google.com/feed/aHR0cHM6Ly9jaGFuZ2Vsb2cuY29...

1) Where to learn... LinkedIn Learning (Lynda) was super helpful to me in my career. Affordable and excellent lessons + projects and well worth the money, no matter what you want to learn. MDN and Stack are great for questions once you start coding sample projects.

2) I think you're really asking more about "lower vs higher" (levels of abstraction), rather than simple/complex. There is nothing inherently "simple" about managing your own cron jobs, DBs, load balancers, VMs, etc. Each of those, at the right scale, can be a full-time career unto itself if you choose to specialize in it.

On the other hand, a "full stack" web dev can do a little bit of everything juuuuuuust enough to get by, which is often enough for simpler teams & projects, but can sometimes make it harder for others to maintain/scale up. A lot of basic web technologies were invented in the 90s and 2000s under the constraints of those days and it takes a lot of patience and know-how to get them running at scale and still provide a good developer/devops/orchestration experience.

Every project and org is different and there's not necessarily a "correct" level of abstraction, just different business needs and personal preferences. Each stack is a set of tradeoffs between user experience, developer experience, familiarity, cost, openness, maintainability, stability, etc.

At the end of the day they all compile down to the basics: HTML + HTTP. The user doesn't know what your stack is and the browser doesn't care.

3) IMO, the stack you choose shouldn't be based on some rigid ideology that you brought with you, but on finding (and, rarely, inventing) the most appropriate set of tools for the project and the people working on it. To that end, "production ready (yet simple!)" can mean something entirely different from one team/project to the next.

For example, an ecommerce site with 10,000 flat handwritten HTML pages is dead simple... no database, no proxy, no load balancer, no CDN, no HTTPs for most of it. And it's also a pain to maintain or upgrade. On the other hand, a Next.js hybrid app might have fewer lines of code, but if your devs are all used to Shopify templates or WooCommerce or some homebrewed Rails app, having to retrain everyone in a new stack may not be worth it. All of those are going to create a somewhat usable website for your end-users, but they each entail a very different set of developer skills & preferences.

4) If you don't know what level of abstraction you would prefer to work on (i.e. bare metal vs Vercel), start from the middle, which is where they all meet anyway: HTML + CSS. There is no reason to learn the old HTML syntaxes or older versions of CSS. Get really comfortable writing plain HTML in a single file or two, using modern CSS (grid and flexbox, etc.). Try to make a simple blog page using just those two tools, with no backend and no templating and no frameworks. Once you thoroughly understand how that one single page is structured, parsed, and presented by the browser, you can better understand the tradeoffs various levels of abstraction give you.

Let's say you want to hook that simple blog page up to a backend now. You can roll your own DB, spinning up your own Maria/MySQL/Postgres/SQlite DB. How will you do that? How will you make it reproducible on the server that you eventually host it on? How will you sync up DBs between your dev machine and the server? How will you scale this up to 10,000 or 10,000,000 viewers/mo? Can multiple editors work on it at the same time? Will there be multiple geographical regions you would want to replicate across? (Not trying to answer for you, just pointing out some of the interesting questions to solve).

You can do all of that on bare metal. Or a local WAMPServer setup. You can put it in a Docker container, or maybe orchestrate it with a tool like Lando. Or put it inside Kubernetes. Or outsource some of it, either to a cloud VM like EC2 or a managed DB like DigitalOcean's or ElephantSQL, or all the way to an abstracted headless CMS in the cloud like DatoCMS or GraphCMS. Each level of abstraction trades off some level of control/maintenance/cost/transparency/lock-in/etc. Again there is no right answer, just what is right for your project and/or personal preferences.

Back to your blog post, but focusing on the frontend now: You've outgrown that simple blog post and need to add more frontend look & feel kinda stuff. Do you stick with vanilla HTML + CSS? You certainly can. Do you need to make it work with phones? You can write a bunch of media queries, combined with grid and flex. It's plenty powerful, just a bit of work. Are you sick of having to do all that yourself? UI frameworks like Bootstrap exist specifically to make that easier. Or is that still too basic? There are more opinionated/higher-level design frameworks like MUI (derived from Material UI) that provides not only basic primitives but higher-level components (like Autocomplete, or a date picker, or a card with avatars and such).

That's just the styling.

What about the interactivity? What happens when you want to add commenting, categories, search, filtering, user logins, roles, etc.? That's where the really fun/tricky stuff comes in. You can 100% roll your own for all of that (somebody did, obviously, or the web wouldn't have that stuff) or you can use someone else's drop-in solution (like Discourse for comments) that's basically just copy/pasting a single script injection. Or take something like filtering... you can write that as backend (sanitized) queries that the frontend sends back, the BE parses and queries for, and then returns the result set. What does that look like? Does the backend prerender the entire HTML page and send that back? Does it cache any of that? If so, how does it invalidate? Or does it only send back the result set as raw data (JSON/XML/Msgpack/etc.)? Or would you rather handle some/all of the filtering on the frontend, hiding/showing HTML elements with some light Javascript? Do you write that JS yourself and handle state changes, or do you use jQuery/React/Vue/Svelte/Angular?

Then, when you combine ALL of these concerns, you can start to fully evaluate more complete frameworks like Next/Nuxt and understand their pros and cons better.

Some devs prefer to maintain control of everything. Some hate the backend and want to outsource as much of that as possible. Some hate the frontend and want to outsource as much of that as possible. Some want a little bit of everything, but less day-to-day tedium & instability. There's a hundred frameworks out there, probably enough to meet any desired level of abstraction/modularization.

TLDR: There isn't a single right answer to the question of "bare-metal v. vps v. vm [vs managed host vs serverless vs edge KV vs Jamstack vs App Engine/Amplify vs serverless]. Each type of abstraction evolved organically to meet some perceived need that the ecosystem wasn't previously meeting. Most often, a solution gains popularity when it can meet 80% of common needs with much less work -- but it would be the wrong choice for the other 20% of needs, and so another abstraction appears later. Some choose to forego that game and completely maintain their own stack, but you usually see that either for super small projects (a lone dev or two) or giant multinationals who can own their own silicon designs all the way up to global data centers. In the middle, where most projects and businesses sit, everyone chooses SOME particular abstractions to hand-wave away the parts that aren't mission-critical that they don't want to spend time maintaining/configuring. That's the hard part to figure out, and it takes a while to get a feel for it. So don't go in assuming that you either need bare metal or the highest levels of abstraction; you can't know that beforehand. Learn the middle and go up or down as your evolving needs dictate, but be open to different solutions... at the end of the day, web is a common problem and there are a lot of good (but different) solutions out there, each existing for a reason.