So, you’ve completed scorch, now what? Well throughout the sessions we covered a ton of content from frontend and design, to security, to networking. Lots of things were covered, and so I have broken up this post into sections so you can find the section most relevant to your favorite part of the sessions for the time being.
Design and Frontend
We covered a ton of topics when it came to design and frontend development. This is essentially everything a user see’s and interacts with. This covers UI, UX, as well as HTML, CSS, Component Libraries etc.
Design
For the design oriented section I don’t have a ton of specific topics to recommend, but broadly just a few resources you can look into if you want to continue down the design route, some of these are websites, some are youtubers. Some specific to web design, some more jack-of-all-trades designers:
- Youtube
- Inspiration websites
Front end
On the development side there’s a ton of directions you can go in. Generally more experience with CSS is a good idea, and from there dipping your toes into frameworks is probably a good idea.
Node JS
Node JS is a popular runtime for JavaScript. This basically means you can run JavaScript on your PC without needing a browser. This means we can use JavaScript for anything we would use a normal programming language for. Node JS also has a package management system called NPM, which has thousands of packages. If you want to use JavaScript for more advanced use cases, node JS is the way to go.
Resources
Typescript
In the course we used JavaScript. With JavaScript we can do a ton of great things, but there are issues. If I were to give you the variable a in javasript, you wouldn’t be able to tell me necessarily what type it is. You might think “oh, I’ll just do this”:
function checkType(value, expectedType){
if (typeof(value) == expectedType){
return true
} else {
return false
}
}
checkType("a", 'string')
Great, so we can do our checks and we’re good to go! Well, consider this:
a = "a"
typeof(a) // 'String'
a = 1
typeof(a) // Number
a = 1.5
typeof(a) // Number <-- No difference for int or float
a = true
typeof(a) // Boolean
a = NaN // Not a number
typeof(a) // Number <-- Why
a = [1,2,3,4]
typeof(a) // Object
a = {"name":"kieran", "age":25}
typeof(a) // Object <-- Arrays and JSON are both 'object'
class Dog {
constructor(breed, name) {
this.breed = breed;
this.name = name;
}
}
a = new Dog("Doberman", "Lucky")
typeof(a) // Object <-- Any and all class instances are objects
So… Not a Number (NaN) is a number and arrays, JSON or classes are all considered just objects. How do we actually make sure the information we’re receiving is the correct type when we’re working on things. This has been a well known issue in javascript, and so a language was created called typescript, typescript basically is javascript, except you define types for your variables, and then you compile your code to javascript so it can run in the browser with all the type safety you developed (though there are still issues with typescript).
Here is an example in typescript:
let a:String = "a"
a = 14 // Error: Type 'number' is not assignable to type 'String'.
Great, but what about our ambiguous cases from earlier:
// Integers vs floats aren't built in, but you can give people a hint what you're looking for
type integer = number
type float = number
let a:integer = 1
let a:float = 1.5
let a:number[] = [1,2,3,4]
class Dog {
breed:String;
name:String;
constructor(breed:String, name:String) {
this.breed = breed;
this.name = name;
}
}
let a:Dog = new Dog("Doberman", "Lucky")
// You can then use this to define arguments to functions, which will error at compile time if it's not respected
function pet(a:Dog): String{
return `Who's a good dog ${a.name}`
}
let a:Dog = new Dog("Doberman", "Lucky")
pet(a)
let b:integer = 1
pet(b) // Error: Argument of type 'number' is not assignable to parameter of type 'Dog'.
Libraries like zod can take this even further
Resources:
- About
- Getting Started
- Helpful tools & Challenges
Meta frameworks are systems that are designed to make building sites easier. They help bundle a bunch of functionality together to make it easier to do more complicated things. There’s a few categories I created to discuss these. The ones in this section are based on JavaScript, and mix frontend and backend code. Later in the backend section I will talk about “full-stack/backend” frameworks that separate these concerns more strictly. Some of the UI frameworks we will talk about can be used with these. I would recommend for most people to start with Astro, then down the road integrate a few react components into an Astro site and go from there.
Astro
Astro is a framework designed to make building mostly static sites easy. It’s a mix of a static site generator, a meta-framework, and a framework. It’s designed to work best for things like blogs, e-commerce, and portfolios. Anything where the content is the most important part, and the content itself is not changing daily. Astro is designed to let you create components, and then use those components to build out pages, then at the end use all of this to build a static site (though it can be configured to be a server with a backend as well).
Astro is very beginner friendly, and has a ton of pre-built themes you can start from. It’s meta-framework-ness will also allow you to mix and match some of the other UI frameworks we will talk about later, but you don’t have to. For example you can have an Astro project that has react, or svelte, or view components inside it!
Resources:
Keep in mind Astro is relatively new, they’ve gone through multiple versions quickly, so lots of resources use old versions of Astro
NextJS
NextJS is a react-based meta framework designed to make building apps with react easier. It’s used by a ton of newer companies, and has a ton of functionality integrated and or available in plugins. Unlike Astro next is tied to react, so if you want to use it I would recommend reading the react section first, then coming back to this section.
Resources
UI Frameworks
A while back companies realized as their UI was getting more complicated that they wanted to store more content client-side, while still providing a good experience. Originally people played around with AJAX (video about AJAX, longer video about jax). Ajax is basically just normal JavaScript, except it will occasionally update it’s content. This worked well for chat apps, and other apps, but as social media got more complicated people started creating UI frameworks to keep up with demands of users. I would recommend learning AJAX as a lot of the time it will serve your needs better than a full on UI framework. While most of these libraries are popular you should keep in mind that React as a UI framework is the most popular, and therefore best option job-wise (for now, but that’s changed in the past).
React
React is a UI framework that is incredibly popular. Fundamentally it allows you to create components using JSX, a language built for react. This means you can include your JavaScript, CSS and HTML all in one file, and use/re-use components as much as you need. It works very well when your UI is reactive, meaning it has a lot of changes to it’s state.
Want to have an online map with realtime scrolling? How about realtime video calls? Maybe a massive social media site with realtime likes and comments? All of these are good use cases for react. Just keep in mind that all UI libraries have to use resources on the client browser, so you can easily get slow performance if you’re not careful.
Resources:
- About
- Getting Started
- Technical details
- Other UI Frameworks
Component Libraries
We spoke during the sessions about component libraries. Essentially the idea is to bundle up our site into little bricks of functionality that we can use to construct a larger site. Each brick would be called a component, and consist of the HTML/CSS/JS needed to accomplish whatever the component wanted to do. There are tons of component libraries, but I wanted to give you a few options I’ve found that might be useful for you. You can find even more in our article How to cheat at CSS | Schulich Ignite, this also covers what Tailwind is if you’ve never heard of it:
- Pure CSS
- React
- Astro/Tailwind
Other things to look into
There’s a few other additional resources and topics that might be interesting, and worth looking into:
- Client apps
- Apps that are designed to run in the browser on the users device like native apps
- PWA’s
- Electron
- Expo
- Navigator
- MIDI
- Additional Resources
Backend
Towards the end of the sessions we started looking at the backend. We got into a bit of how some networking worked, and setup a few small apps. If you want to improve your backend skills there are a lot of topics to cover.
Databases
Databases are how we store data for our applications. There are tons of ways of doing storage, but the most common are relational SQL databases.
SQL
Structured Query Language is the most popular language we use to talk with databases. It also informs how data is stored in a database. Essentially a database like this will store data in a table, the table will have a schema (some fields with data). For example this might be what a User table looks like for storing info:
For this we would say we have a table with 4 rows and 3 columns. The columns make up the schema which is:
- Name: A Varchar (basically a string but with a max length)
- Email: A Varchar (basically a string but with a max length)
- Age: An integer
Usually databases are their own apps that will run, and then you will connect to them and send your SQL queries. So if the table above existed I could get all rows with people over 30 using:
SELECT * FROM Users WHERE Age > 30;
Which would return a table with our data:
Or if we just wanted to know how many there are we could do:
SELECT COUNT(*) FROM Users WHERE Age > 30;
Which would return the table
You do also have the option of using something like sqllite which is a great option for beginners because it’s just a file instead of it’s own app you run.
Resources:
- SQL syntax
- Other Database systems
- Optimization & the importance of optimization
No-SQL
No-SQL databases are databases that do not follow the same paradigms as SQL databases. For example mongoDB is a document oriented, schemaless database. What this means is that you don’t need to know exactly what you want to store before you store it, all you have to define is where you want to store it. So you might have a collection of Users that would look something like this:
{
"Users":
[
{
_id:"asdfkjhsdahlkfh",
name: "Kieran Wood",
email: "[email protected]",
age: 25
},
{
_id:"treertyhtreyhrty",
name: "Lucille Johnson",
email: "[email protected]",
age: 37
},
{
_id:"dsfgsdfgsdfgsdfg",
name: "Lonnie Bell",
email: "[email protected]",
age: 19
},
{
_id:"jhgkghjkddddhfdg",
name: "Carole Miller",
email: "[email protected]",
age: 42
}
]
}
Document oriented is just 1 type of no-SQL database, others include graph databases , key-value DB’s , vector databases , etc.
Resources
Networking & Architecture
Throughout scorch we covered various parts of how HTTP worked, and how to deploy your sites using github actions. While our coverage of HTTP covered most of what you needed, there’s still plenty more to learn.
OSI
HTTP was the main networking we covered, but when we covered it we glossed over tons of steps that are taken before we even get to exchanging HTTP requests and responses. If you are interested in more about HTTP you can see our blog posts building an HTTP server from scratch in python. But before we even get to HTTP there are a ton of different “layers” to networks. From the physical wires connecting your computer to another, up to the applications running on servers there’s a whole world of networking to explore. A structured way to do this is to look into the OSI model . This is basically the model we use to understand networking on computers (though some of it is a bit outdated these days). It’s a great way to learn about networks from copper to cloud.
Containerization
I briefly mentioned containerization during CI/CD. Essentially this is running a mini-computer inside another computer. This can also be helpful when creating applications. Separating out multiple parts of your app into separate containers and connecting them together is a common pattern to make code re-use and flexibility simpler.
Resources:
- Docker
- Ansible
- Articles and talks
SMTP (Simple Mail Transfer Protocol)
Another useful protocol to know would be the SMTP protocol. This protocol is what we use to handle email. Learning about how to setup an SMTP server is important because it comes up more often than you think. Want to send a newsletter to someone from your own email, you need SMTP, want to setup a “forgot password” system on your app, you need SMTP.
- SMTP
- DNS records related to email
Frameworks
We talked about UI frameworks and meta frameworks earlier. Both of these approaches are focused on the frontend. They will often allow you to do backend operations, but they are built primarily with the frontend in mind, and try to blur the lines between frontend and backend in many cases. Traditional frameworks are the opposite. The backend is there to have data, to generate the information to send to the client, and the clients job on the frontend is just to display the information, and query the backend for updates. This separation is called Co-location, and it’s a reason why frameworks are still popular today. Frameworks are designed typically to be a “batteries-included” option, with standard ways of interacting with databases, doing security, and managing your data. This makes them very idiosyncratic, and some people would argue it makes them easier to work with since there’s a “correct way” often.
Flask
We covered flask in the sessions, flask is a micro-framework. It provides the tools you need to build your own framework. It will let you do basic routing, and pass data to the frontend. Everything else needs to be installed and configured, but it’s a good base to start from.
FastAPI
FastAPI is a flask-like framework that has some additional features added. It’s primarily a good option when you wan to build some larger API’s that other people are going to be using. It provides built in:
- Data cleaning + validation
- Documentation of endpoints
- Much faster execution
Django
Django is a full framework. It has systems for automating database management, doing security for things like forms etc. It has all the tools you need out of the box to run a full-fledged app, and is designed to be that way. You can even use django just on the backend, and use react on the frontend where it’s data is populated by django.
Resources:
UI Framework Alternatives
We spoke about using frameworks to manage your backend, and then use UI frameworks to manage your state changes, and updates. This is one option, but there have been many systems introduced that can do the same job of a UI library, but without the complexity. Tools like alpine js and htmx will allow you to do state changes more simply.
Resources
Security
We covered some basic XSS attacks and the idea of sanitization quite a bit in the sessions. This is where the majority of vulnerabilities come up, but it’s not everything. The best way to learn more about security is to spend time breaking systems, and watching how other people break in. The best options for this are to sign up for CTF and blackbox challenges. These are challenges where people ask you break into a system for a “flag”, which is some text on a server that confirms you broke in. Below are some good CTF and blackbox challenges + some other great resources.
Resources:
- CTF and Black Box challenges
- Good talks & example exploits
- Other resources
General
This section is just a section of links to various concepts, blog posts and websites that can also be useful in no particular order:
Conclusion
Web development is very complicated. There’s a lot of moving parts. I would recommend just taking it one concept at a time, and not worrying about knowing everything. If you get good in one area you often don’t need to learn other areas (but you should because they’re fun). Take your time, build projects you like, and keep your passion for coding ignited!