“Dearest server, I am Chrome, the 64th of that name, child of WebKit, grandchild of KHTML, a disciple of Gecko, follower of the great Mozilla/5.0, running on Windows NT 10”
— 

 service. a lot of these tutorials are based on their service and using Ubuntu 18.04.

once you create an account at DigitalOcean you’ll want to go through these steps to get started:

 that goes over how to login as root and then create some users. Basically:

weirdly, I had to disable Apache later…

if you’re using a cheaper hosting solution that doesn’t have much memory it’s a good idea to have a swapfile

after that, let’s go modern and support the latest version of HTTP. in your nginx.conf file:

in theory, you could also do this at your server-level (e.g. in Node using the 

 module) but a.) i’ve found it tricky to setup with things like the 

 server. (which doesn’t support it quite yet, see 

 since it would make things worse on your backend and c.) developing on SSL on your localhost is annoying because of the self-signed certs having to be approved by your browser — to make this work you can use the tool called 

some sane defaults for the above stated headers for nginx:

if you really must have inline scripts in your site (which you should absolutely avoid doing for security reasons), you can add the 

 tags. this is especially true if you’re dealing with older sites that have legacy code including inline scripts. if you can’t manage that, then the fallback to this method, then you can add 

 sections of the CSP policy. really though, try to get the nonce’s in there before doing the 

if you don’t want to use nginx and want to set these at the Express level you can use 

 will make sure cookies aren’t modified in transit.

pm2 keeps your server up and running in addition to starting it up upon system reboot.

 is looking like a promising project to rebuild nodejs from the ground up (from the original creator of node)

(there’s probably a better way of doing this…, related DigitalOcean


in case you’re not using pm2 + node.js you can use sv + runit to make sure your server stays up and running and starts up on system reboot.

📟 appendix: setting up a self-hosted server

if you’re absolutely new to CSS, start 

 at the Mozilla Developer Network (or MDN). they’re the people that make Firefox and have the best reference guides for CSS. in general though this guide assumes you’ve got a base understanding of CSS so go forth and mess around with the language as much as you can before moving on to the rest of the more complicated stuff.

an easy way to get started is by checking out some of these tools that let you play around with the language:

 of standards around color, beginning with 

 and including other fancier things like 

. the new “king” of color definition is 

 not a regular webpage. to that end, you shouldn’t be using regular CSS with 

 tags anymore — as your application grows and more contributors add to it, you will drown in a sea of madness and salty tears. yes, your mother taught you to wash behind your ears, brush your teeth, and never, 

 use inline styles in your HTML. but those days are over and a new era has come.

the truth is that this space is still rapidly in development and the dust isn’t quite settled yet. i think there are compelling arguments for both CSS-in-JS and CSS Modules. you’ll probably fine going with either these days.

 are a great way to get a lot of the benefits of CSS-in-JS without leaving the CSS world altogether. here’s a 

CSS-in-JS forgoes CSS files altogether and says we should have our styling where our components are. think about it this way. when you’re sharing HTML these days, we tend to do so via 

. in other words, one can create React components and publish them to the general web to share to fellow developers. similarly, one could argue, the best way to share CSS is to package them inside of something standard like JS.

again, there’s so much action going on in this space that it’s still to be decided what paradigm will win here. for now though, my tentative recommendation is 

this is an opinionated guide, remember? everything in my soul tells me to keep Tailwind away with a 10-foot pole. it's vendor lock-in embodied in a library, it has its own bespoke version of CSS that you have to learn, it becomes a garbled, cluttered mess within your HTML/JSX, ugh, ugh, ugh!

yes, it's very conveniently "spoken" by LLMs but trying to maintain it is untenable. Tailwind just ends up being a bloody mess once the codebase has any amount of real complexity or the number of collaborators grows.
we webdevs went 

 this experience with CoffeeScript before. yes, it was elegant, neat, enticing — and, in the end, we needed to rewrite it all to stay relevant.

 out that are built on Tailwind, and, yeah, they look a peach.
but ugh, mark my words, in 10 years, this madness will (hopefully) be behind us, leaving us to cleanup the strangling 

-like vines of unmaintainable code for decades to come.

, i’ll mention again here the technologies included by default related to CSS for you to use out of the box.

 is a CSS Reset that helps normalize things across browsers, a lesser problem these days but still important.


when you can, it’s suggested to use CSS Modules which provide great scoping for your CSS to a particular JS module. first, name your CSS file 

 and then you can use it in your JS module as such (take note of the 

given the recommendation for CSS Modules/CSS-in-JS i might steer you away from CSS preprocessors (which would add yet another layer top of an already complex stack of technologies). but, if that’s your thing, then take a look at 

the advantages Sass can give you are things like:

: other packages in the space are things like 

 but the community isn’t as strong there and the support from other vendors isn’t as robust.)

there’s a bunch of CSS features constantly in the making. i had this section listing things from 2018 that were exciting and the neat thing is that the CSS development flywheel has only continued to produce great stuff!

🎨 cascading stylesheets

i don’t have too many things to comment on as far as databases go. they’re probably my weakest area. (i’m open to suggestions!)

 is a simple layer to have your code interface with your db.

 against using ORM’s since they can add cruft to your queries. as mentioned in the JS section about using frameworks, in general, using a higher-level wrapper doesn’t excuse you from learning how the underlying technologies works!

again, i’m ill-equipped to talk about db’s. but here are some options on NoSQL to explore if you’re into that kind of thing:

for when you can’t use the GUI and have to use the command line.

💿 db

the “rinse, lather, (hopefully don’t) repeat” part.

 powerful these days. there’s a lot to say on how to use these tools. you should start by just taking any random website you like and mess around with it using the tools. once you’ve played with it a little bit, go read the 

 with your bundling tool. create-next-app’s bundler config should have these on by default.

i won’t go over every feature in this guide, but i’d like to point out some highlights and tricks/tips that i’ve found commonly ignored by engineers:

 so that your files that are bundled for your app can be mapped backed to the original code in development mode for easier debugging within Chrome’s DevTools.

on the topic of your bundler, another mention here in your workflow is that webpack allows for 

. this allows for a much faster iteration cycle, especially when debugging a particular section of code.

a must-have tool to debug React components, changing their state and props on demand.

some highlights and tricks/tips for React DevTools:

to be able to debug node.js, you must launch it with the 

 flag. from there, you can use your favorite editor/IDE and attach the debugger to the process. you usually have to specify the port (defaults to 9229) and then you’re off to the races! it should work more or less like Chrome’s DevTools debugger.

 in your browser, this will allow you to connect your editor to the V8 debugger protocol.

at the very least, you need to gather exceptions from your clients and send them up to your server so you know what errors are happening to your users out in the wild. if you’re lucky you will have passionate users that will mercifully report to you bugs they are experiencing. (thank your lucky stars!) but a lot of bugs will go unnoticed and unreported manually by users. and, they might only happen in certain special cases or in certain browsers/countries/days of the week/what have you.

related to the above is logging on your backend. you should be logging not only exceptions but everything you can on your backend. this will prove to be 

 when you inevitably come across a problem and, like a detective, try to piece together the series of events that led to a failure.

a paid option that is useful in production is 

. i wish Sentry was better: it feels heavy-handed, the dashboard UI can be clunky, and there’s a lot of background noise from random browser bugs that are false positives…but there’s nothing else contending with it. i’m exploring the tool 

at my previous company we called errors “freakouts” when something went so horribly wrong, that all safety checks had failed and a user’s data was at risk of being lost. the right thing to do here, albeit annoying for your users, is to notify them of this fact and freeze your app from further interaction. see the related section below about a “kill switch”.

related to the “kernel panic” above, another safety check that can be implemented is having your clients “phone home” every once in a while to see if they are healthy and not causing problems for your server. especially as your apps become more cached offline and don’t refresh from page-to-page navigation your clients in the wild can become stale and, unfortunately, potentially dangerous. with clients checking with the server if they are still valid, you can send them a signal that they need to reboot (either a “hard”/immediate or “soft”/when-you-can) so that the clients don’t become problems. you should obviously try to do this as unobtrusively for your users as much as possible. only in the case where your clients are DDOSing your server or something grave of that nature should you send a hard reboot.

one thing to mention here is documenting via a process called a “post-mortem” 

 if they happen in production taking your website down. by writing down what went wrong and how you solved it, you start to build the to help notice patterns of failure, learn from your mistakes and cohesively learn how to solve it going forward.

🐛 debugging

learning how to use the terminal of your computer is a console without any buttons. you are expected almost to know which “buttons” are hidden there below the surface. no one ever gave me a primer and it was painful to learn over time through trial and error what those hidden commands are. here’s a compilation of some useful commands to get you through most basic functions and some more interesting ones.

. ugh, i think they’re the worst syntactically. my tendency is to write node or python scripts instead because at least they make bore sense to me.

this is a pet peeve of mine that no one ever taught me these 

 handy shortcuts and i didn’t know about them for many years.

[ctrl] + a — go to beginning of the line
[ctrl] + e — go to the end of the line
[ctrl] + c — kill the currently running program
[ctrl] + k — clear screen
[ctrl] + z — pause the currently running program

⌨️ how-to linux

" part. 😜 or, who are we kidding, it’s actually TypeScript these days.

despite the image at the top of this section, i ❤ javascript (typescript) so hard (tbh, typescript has taken over!). i’ve been coding in it since the 90’s and it’s only gotten better over the years.

 at the Mozilla Developer Network (or MDN). they’re the people that make Firefox and have the best reference guides for JS. in general though this guide assumes you’ve got a base understanding of JS so go forth and mess around with the language as much as you can before moving on to the rest of the more complicated stuff.

an easy way to get started is by checking out some of these tools that let you play around with the language. another great way is to a project that you like and checking out it’s code. view the source, luke!

to be able to use JS effectively, you’ll need to have a set of tools to give you visibility into what’s happening and fiddle with your code. this is the absolute best way to learn. read the section on 

let’s get something straight: vanilla JS is something you absolutely should know. you need to understand the underlying principles and fundamentals of the frameworks you’ll be using so that you can effectively use them.

that being said, practically speaking, you won’t be writing vanilla JS a lot of the time and a well-chosen suite of frameworks will help immensely in your quest. a lot of the best of breed frameworks have come from a Cambrian explosion emanating from Facebook’s developer team. Google has tried through many, many, iterations to provide compelling alternatives but we should have seen the downward trend with frameworks ever since they started with the ill-conceived 

. (i say this with love, y’all, since i used to work at Google. their contributions to browser tech and tools are amazing, but their frameworks have always been lagging.)

there are other competitors in this space and while i do 

 recommend React down below, there is something to be said about React starting to lose the plot these days (in particular with RSC, or, React Server Components).
for an interesting take on this you can read: 

 way to write your application these days. if there’s one place to make sure you devour all the documentation, it’s here. go through the tutorials and starter guides (using 

, mentioned in a section of its own below, is also a good leg-up.)


a compelling feature that comes bundled with React is it’s ability to describe HTML and custom components 

 JS itself. this was high heresy not long ago (much like CSS-in-JS is still heresy in lots of circles but gaining traction.)

underneath the hood, the code will be transformed into:

GraphQL is a language that lets your client talk to the server to get data it needs in an efficient and forward-compatible way. there’s a lot to learn here and since it can be some of the more mind-bending stuff to learn in the React-verse, i recommend checking out this 

 to let your brain wraparound how it works.

 is a lighter weight option, less fully featured but an easier integration.


because GraphQL can be complex there are some great frameworks built around it. i recommend using Apollo to get you up and running with GraphQL quickly. to install:

 about when to use GraphQL and when to use gRPC: “Use GraphQL for client-server communication and gRPC for server-to-server.”

probably the more cultish side of the React-verse 😛. you’ll find a lot of acolytes and haters here. i actually might not recommend Redux for you, at least not off the bat. it’s another one of those mind-bending parts of the React world that can be a lot to take in. besides, even the creator suggests that sometimes 

allows you to build native mobile apps using React. i don’t have much experience here but i hear good things and that it’s getting better over time. related libraries that are of interest: 

: interesting tact to address bundle size and performance for fetching data.

there’s a lot that goes into a javascript app these days. 

 helps bundle together a lot of the popular tools that are part of modern development. i’ll get into what React is in the first place in a section below this one.

btw, Node is great but there's definitely competition in the space. 

as an alternative, for this guide, i’ve created an even more comprehensive version of 

 that adds even more tools straight out of the box.

you’ll find several folders and properties that are relevant to you:

 brings to the table. the bundler acts as the glue for these packages. let’s look at the different things that come bundled in 

learn more about all the ways the Next.js App Router works with 

as mentioned above, i’ve created a custom template that plugs into 

 ✨ that are mentioned in this entire guide bundled in by default. love it ❤ or leave it 🏃‍♀️.

, every engineer is a security engineer. you need to act like it and protect your app from the forces acting against you.

in addition to the protections at the server level, there are some things to implement at the application level as well. this is called “

”, adding multiple layers of security to protect yourself.

fun articles to read (to make you more paranoid):

if there’s one thing that will last after the earth is gone, it’ll be cockroaches and js libraries. there are 

 of them. try not to overdo it, because with each library you add, you become beholden to it.

☕ javascript

if your performance is poor, it should be considered Bug #1 and a huge reason people won’t use your product. if your page takes more than a couple seconds to load, people will abandon it and potentially never come back again. a speedy app shows shows consideration for your user’s time — the faster they can get what they need done and move on with their life, the more they will consider it a indispensable tool.

make sure you measure how your app is actually behaving in the wild! just because it “works for you” in the lab of your home or office doesn’t mean it actually works for the wide variety of people using your app with a wide variety of connection speeds, browsers, and usage patterns.

there are a lot of facets to attaining performance gains. Google puts out a model called 

 as a helpful mental model when thinking about prioritizing work here. in general, Google dominates in this area of knowledge — most of the resources below are from them. here’s a list of approaches to consider.

one of the simplest things you can do is reduce the number of HTTP requests to your server. by bundling together your assets (JS, CSS, and traditionally your icons into a sprite file) you can reduce the number of round-trip requests from client↔server and improve speed 

. you can get this for free basically via your bundler.

 tags at the bottom of your HTML (near the 

 closing tag) whenever possible to improve page load. JS blocks page execution so saving it for the end makes your page more usable faster. additionally, one can use the 

 tag to make execution faster of other parts of the page. 

 will download the file asynchronously and pause HTML execution once it’s received, and not necessarily in order. 

 on the other hand waits until HTML execution is done, but it will execute in order.

 on the other hand, HTTP2 turns the previous item in this list on its head and says, “no need to bundle assets anymore!” in practice, i’ve found that you shouldn’t go whole hog and unbundling everything — the right balance is needed. it will take playing with your app and it’s particular needs a little bit to see what things can be unbundled vs. not to see what works best.

 speed, or “fake it ‘til you make it” 🙂. here, we add visual assets that load quickly on page load to give the user the impression that 

gives your app offline capability and faster loading times.


related to Service Workers is the standard being put out to:

you usually don’t need all the images to load on page load. the browser does optimizations of its own to load what it considers more important (JS and CSS) but you can also help out by reducing the amount of traffic your user has to download for your app and, likewise, reduce the amount of traffic your server has to handle.

no need to load the images below what’s currently visible on the page. you can load them in as the user scrolls! check out any page with video thumbnails on 

 for an example of this works as you scroll (i point it out because i implemented this at YouTube back in the day when i worked there 😉). check out 

pick an appropriate image format. PNG is lossless and will tend to be larger. JPG is probably your best bet. there are a 

 coming out but they’re not widely supported yet.

again, you can add placeholders for your images, perhaps getting a . check out any 

 to combine your images. however, as mentioned above, if HTTP2 is enabled on your server, you might not even need this.

there are several tools available to reduce the sizes of your images.

a surprisingly expensive operation for your browser is resizing your images on the fly to fit into a particular space, especially if it’s a high quality image. if you resize your images beforehand to be the correct size for where they’re going to be displayed you’ll gain some benefits in page responsiveness.

a new HTML attribute that will help hint to the browser that an image can be loaded later. just add 

there are a couple of HTML attributes that can work in your favor:

 tags can optimize your resources loading in more quickly.

a new HTML attribute that will help hint to the browser that an image can be loaded later.

not supported anywhere yet but would let you specify priority hints on particular assets.

optimizing fonts is probably one of the last things you should look at, it’s more of a micro-optimization. but you can fine-tune unicode ranges and things like that. WOFF is widely supported these days and safe to go with these days.

my backend-optimization-fu isn’t the most robust but i can offer a couple suggestions to delve into.

make sure your assets have caching headers on them.

don’t have your app serving static resources. make sure 

 to serve up static files without hitting your app server.

goes without saying maybe, but your server should have this enabled when serving assets.

 will cache data in memory which would be much faster than retrieving it from your DB or somewhere else.

an HTTP header that hints to your server that you should serve up a more lightweight page, if possible.

if you’re app will need to be searchable by search engines or will need to be shared on social media, then you’re going to need to look at server-side rendering. the bonus to this is that it can help perceived load time for the user since the user will get HTML immediately instead of waiting for your JS bundle to download, parse, and execute.

on the other hand, if you’re building an app that is more in the lines of something like Gmail that shouldn’t be searchable, then by all means, skip the SSR step. for a compelling argument towards this path check out 

if that’s all confusing (and it is for most people), here’s 

 to help you decide and weigh the benefits.

a couple things to keep in mind in the JS world during runtime and load. 

. since JS is single-threaded and tied with UI updates, you’ve got about 16ms of time to do any processing before your app starts feeling 

load only what’s really necessary right now and lazy-load other stuff later. webpack, along with a bunch of other libraries, provide support for this. i would recommend that you consider at least splitting off:

speaking of code splitting, newer versions of React offer the ability to dynamically split on components vs. splitting on routes. it’s awesome. word of warning that this isn’t working on server-side quite yet at the time of writing (Jan 2019).

tools like webpack and the like will take your code and reduce its size significantly.

discover what’s in your bundle but not being actually used. webpack also provides supports for this.

 of events to your JS. you should take a sample of them every so often (reducing it to at least once every 33ms is a good start).

don’t run (too much) JS when scrolling. if you do, take a look at the ‘passive’ option to make sure your scrolling stays smooth.

use this function instead of setTimeout for visual updates.

a new function (not supported by all browsers yet) that lets you do work when the user is inactive or when the browser has spare cycles it can give you.

a very simple win for your React components is to use 

. they will help reduce the amount of times your component needs to re-render.

in general, fine-tuning CSS is one of the hardest areas to squeeze out performance gains and i recommend saving it for last. that being said, there are a couple areas that are worth mentioning.


CSS is parsed from right-to-left. that is to say, for a rule like 

 the anchor tags on a page before parsing the rest of the rule. thus, an especially expensive rule is something like 

 elements on the page first and then match by the class.

reduce the number of descendant/child selectors


along with the previous rule, in general, you should reduce the number of selectors such that your browser has to do less of the right-to-left traversal of the DOM tree. a rule like 

 is much more performant than something like 

 which effectively might match the same thing, but the former rule is more specific in its intention.


the classic rule to put an element on the GPU layer to have it render faster. the 

 rule mentioned above should supersede this one but 

 isn’t completely supported yet (not on Edge, as per usual).


not widely supported yet but can ostensibly give you some performance gains during rendering.


gives a performance hint to the browser on how a particular element will change over time.

AMP was a strongarming/vendor lock-in technology from Google that promised speed to users but really ended up being a disingenous play by Google to lock-in more to the Google ecosystem. i’m not going to hyperlink to it here because it’s not worth doing so — just know that as, a web developer, you should push back on any efforts to add AMP rendering to your stack.

on top of the obvious category of speed, is analyzing your product for usage patterns. are your users using the product as you intend it? are they using it in creative ways that perhaps you never imagined? with insights into 

 your users are navigating around your product, you’ll gain insight into what areas of your app need improvement, in addition to which areas of your product are the most popular and perhaps deserve even more devoted attention. you’ll want to track things like:

tracking clicks will help you gain insight on what your users are using and whether they are finding your UI usable in the first place.

an example of this is your user going from search→product page→details tab. or, perhaps most users don’t even use search or the home page and get to your product pages directly and organically via links passed around by friends! in that example, you could consider that your homepage or search might not need to be bundled by default into your app and loaded in later on demand as needed. optimize your app for the most common usage patterns that you observe your users to be taking.

looking at the browsers your users use (especially mobile vs. desktop skew) will help inform your app’s direction and support you should be providing.

maybe you’re big in Japan and you don’t even know it! embrace that there are nearly 200 countries in the world and your user base might not be in your backyard or even on your continent. (just wait til we have people on Mars and then start talking to me about latency speeds 😜)

🗜️ performance

the “let me Google that for you” part.

Shawn Wang coined a term for a new stack this year: 

📟 the server

tl;dr

Vercel

Vite + bundlers