Web Dev The Right Way

Summary

This video script humorously explores the world of web development, highlighting the shift from traditional multi-page applications to modern single-page applications. It explains the basics of backend services, HTTP requests, and the DOM, then delves into JavaScript's role in enhancing user experience. The script also touches on frameworks like React, Angular, and Vue, discussing their approaches to building UIs and managing state. It concludes with insights on server-side rendering, build tools, and the future of web development with WebAssembly.

Takeaways

• 😺 Web development is a dynamic field where debates over trends and frameworks are common, and even experienced developers can make simple mistakes.
• 🌐 Backend services can be monolithic or microservices-based, and they handle HTTP requests to perform business logic and update data stores.
• 🌐 The browser's role is to send HTTP requests, parse HTML to construct the DOM, and display the UI, while also handling CSS and JS for interactivity.
• 🔄 The traditional Multi Page Application (MPA) architecture involves full page refreshes for user interactions, which can be limiting in terms of user experience.
• 🚀 JavaScript is crucial for creating dynamic and interactive web pages, with the language continually evolving through the annual EcmaScript updates.
• 🛠️ Libraries like jQuery simplify DOM manipulation, but as applications grow, maintaining code can become complex, leading to the rise of Single Page Applications (SPAs).
• 🌐 SPAs improve user experience by updating only parts of the page without full refreshes, offloading some logic from the server to the client.
• 📈 The rise of SPAs has led to the development of numerous frameworks like Angular, React, Vue, and newer ones like Svelte, Solid, or Qwik, all aiming to solve the problem of building UIs reactively.
• 🔧 Build tools like WebPack or Vite are essential for managing the complexity of modern JavaScript applications, along with tools for formatting and linting.
• 🌐 Server Side Rendering (SSR) can provide a better initial load experience by sending fully rendered pages from the server, which then get 'hydrated' with JavaScript on the client side.
• 🔄 The shift between MPAs and SPAs, and the introduction of SSR, reflects an ongoing evolution in web development aimed at improving both performance and user experience.

Q & A

What is the main issue with Multi Page Applications (MPAs) in terms of user experience?

The main issue with MPAs is that they require a full page refresh for every user interaction, which interrupts the user flow and can lead to a less smooth and slower user experience.

How does JavaScript improve the user experience on websites?

JavaScript allows for dynamic and interactive features in the browser, enabling partial page updates without a full refresh, which enhances the user experience by providing a smoother and more responsive interface.

What is the purpose of a transpiler like Babel in web development?

A transpiler like Babel is used to convert modern JavaScript code into a version that is compatible with all browsers, ensuring that new features from the ECMAScript specification can be used even in browsers that have not yet implemented them.

What is the difference between Single Page Applications (SPAs) and Multi Page Applications (MPAs)?

SPAs load a single web page and dynamically update that page as the user interacts with the app, whereas MPAs require loading a new page for each user interaction, resulting in full page refreshes.

What is an 'app shell' in the context of Single Page Applications?

An 'app shell' is the initial HTML page loaded by the browser in an SPA, which serves as a container for the application. It loads the necessary JavaScript scripts that build the UI and handle user interactions without additional page reloads.

Why is the initial load time of SPAs a concern?

The initial load time of SPAs can be a concern because the browser must first download the app shell and then execute the JavaScript to build the UI, which can result in a blank page or a loading indicator being displayed to the user for a longer period.

What is Server Side Rendering (SSR) and how does it differ from Client Side Rendering (CSR)?

Server Side Rendering (SSR) is a process where the server generates the HTML based on the JavaScript code before sending it to the browser, allowing the user to see a fully rendered page immediately. In contrast, Client Side Rendering (CSR) involves the browser receiving only the app shell and scripts, and then building the UI in the browser, which can lead to a perceivable delay before the UI is displayed.

What is meant by 'hydration' in the context of web development?

Hydration refers to the process of attaching JavaScript event listeners and functionality to a statically rendered HTML page on the client side, effectively turning it into an interactive SPA after initial server-side rendering.

Why might developers choose to use TypeScript over plain JavaScript?

Developers might choose TypeScript over plain JavaScript for its support of strict types, which can help catch errors during development, and for its compatibility with the latest ECMAScript features, which can be used through transpilation.

What are Web Components and how do they differ from traditional web development practices?

Web Components are a suite of different web platform APIs that allow developers to create custom, reusable HTML elements (also known as web components) encapsulated with their own behavior and styling. They differ from traditional practices by offering a more modular approach to web development, similar to the component-based architecture found in frameworks like React, Angular, and Vue.

What role do build tools like WebPack or Vite play in modern web development?

Build tools like WebPack or Vite help manage the complexity of modern web development by bundling, transpiling, and optimizing JavaScript, CSS, and other assets. They also enable features like code splitting, module federation, and hot module replacement to improve the development experience and application performance.

Outlines

00:00

💻 Web Development: The Myth and Reality

The paragraph discusses the world of web development, characterized by a community of developers who often debate over the latest trends and tools. It humorously points out the irony of developers with extensive resumes but limited experience calling themselves 'seniors.' The speaker admits to being part of this group and suggests that despite the perceived complexity, the essentials of web development can be simplified into a brief overview. The explanation begins with backend services, which can be monolithic or microservices-based, listening for HTTP requests. These requests from the browser include actions, headers, and optional data bodies. The server then processes these, validates inputs, performs business logic, updates storage, and sends responses back to the client, which are typically HTML, JSON, JavaScript, CSS, or assets. The browser constructs the DOM from HTML to display UI, and additional resources like CSS and JS are fetched, utilizing caching to avoid unnecessary requests. The paragraph concludes by touching on the limitations of traditional Multi Page Applications (MPAs) and the need for a better user experience, which leads into the discussion of JavaScript frameworks and libraries.

05:02

🔄 The Evolution of Web Development: SPAs and Frameworks

This section delves into the shift towards Single Page Applications (SPAs), which aim to enhance user experience by reducing the need to refresh entire pages for minor updates. JavaScript is highlighted as the key technology that enables dynamic and interactive web features, following the annual updates of the EcmaScript specification. The paragraph mentions the use of transpilers like Babel and TypeScript to support modern JavaScript features across different browsers. It also touches on the challenges of managing increasingly complex JavaScript codebases and the emergence of SPAs as a solution. SPAs load an app shell from the server, which then dynamically builds the UI using JavaScript, allowing for asynchronous data fetching and updates without full page refreshes. The paragraph also discusses the trade-off between improved user experience and increased initial load times, and introduces the concept of WebSockets for real-time communication. It briefly mentions various frameworks like Angular, React, Vue, and newer ones like Svelte, Solid, or Qwik, which all aim to solve the problem of keeping the UI in sync with underlying data changes. The paragraph concludes with a mention of alternative approaches like Alpine, Petite Vue, or HTMX, which blend SPA concepts with traditional MPA architectures.

10:06

🛠️ Tools and Techniques in Modern Web Development

The final paragraph shifts focus to the tools and techniques used in modern web development, particularly in the context of SPAs. It discusses the need for build tools like WebPack or Vite due to the complex nature of modern JavaScript projects. Code formatting tools and static code analyzers are mentioned as aids in maintaining code quality. The paragraph then revisits the SPA architecture, discussing the concept of Client Side Rendering (CSR) and its drawback of showing a blank page during UI construction. As an alternative, Server Side Rendering (SSR) is introduced, where the server generates static HTML that is then hydrated with JavaScript on the client side for interactivity. This approach improves the initial user experience but introduces new complexities in development. The paragraph concludes by mentioning meta-frameworks that build on lower-level frameworks to provide additional features for building performant web applications, suggesting that starting with a meta-framework for SSR is recommended. It also briefly acknowledges the existence of Web Assembly, which allows for UI development in languages other than JavaScript, such as Rust or C#. The speaker invites feedback and discussion in the comments and encourages viewers to check out other videos.

Keywords

💡Web Development

Web Development refers to the building and maintenance of websites. It encompasses both the front-end and back-end processes. In the video, the speaker humorously critiques the field, highlighting the ease with which people can claim expertise and the simplicity behind complex-sounding tasks. The video aims to demystify web development by suggesting that its core concepts can be summarized in a short video.

💡Full Stack Developer

A Full Stack Developer is a professional who has the skills to develop both the client-side (front-end) and server-side (back-end) applications. The term is mentioned in the context of self-proclaimed 'senior full stack software engineers' who might overcomplicate simple tasks, reflecting the speaker's view that web development is not as complicated as it's often made out to be.

💡React

React is a popular JavaScript library for building user interfaces, particularly for single-page applications. It's part of the discussion on frontend frameworks and is used as an example of a tool that developers might argue over or misuse, indicating the common practices and challenges in the web development community.

💡Git

Git is a version control system used by developers to track changes in their code and collaborate on projects. The video script mentions 'messing up checking their duplicated React component into git,' illustrating a common mistake developers might make, highlighting the practical aspects of web development.

💡HTTP Protocol

The Hypertext Transfer Protocol (HTTP) is the foundation of data communication for the World Wide Web. In the video, HTTP is described as the protocol over which backend services listen to incoming requests, showing its crucial role in how web applications function and communicate with servers.

💡DOM (Document Object Model)

The Document Object Model (DOM) is a programming interface for web documents. It represents the page so that programs can change the document structure, style, and content. The video explains how browsers use the DOM to construct the layout of a page from HTML, which is central to understanding how web pages are rendered and interacted with.

💡Single Page Application (SPA)

A Single Page Application is a web application or website that interacts with the user by dynamically rewriting the current page rather than loading entire new pages from a server. The video discusses SPAs as a pattern that emerged to improve user experience by reducing the need to load new pages for every user interaction.

💡JavaScript

JavaScript is a scripting language used to create interactive web pages. It allows web pages to be dynamic and responsive. The video emphasizes JavaScript's role in enabling dynamic features in browsers, distinguishing between client-side and server-side rendering, and its importance in modern web development.

💡EcmaScript

EcmaScript is a trademarked name for the scripting language standardized by ECMA International. It is the foundation of JavaScript. The video mentions EcmaScript in the context of JavaScript development, highlighting the annual updates to the specification and the need for transpilers like Babel to ensure compatibility across different browsers.

💡Transpiler

A transpiler is a type of compiler that translates code from one programming language to another, often from a more modern or specific syntax to a more compatible one. The video uses Babel as an example of a transpiler that converts modern JavaScript into code that all browsers can understand, which is essential for using the latest JavaScript features across different platforms.

💡Component-Based Architecture

Component-Based Architecture is a design pattern where software is constructed by combining independent and reusable components. In the video, this concept is central to the explanation of how modern web applications are built using frameworks like React, Vue, and Angular, where components maintain their own state and update the UI reactively.

💡State Management

State Management in web development refers to the way applications handle and update the state of their user interface. The video touches on state management as a way to centralize shared state within an application, which is crucial for complex applications to function correctly and maintain consistency across the UI.

💡Web Components

Web Components is a suite of different technologies that allows developers to create custom, reusable HTML elements. The video briefly mentions Web Components as an effort to standardize the creation of custom elements with features like reactivity and templating, although it notes that the developer experience may not match modern expectations.

💡Build Tools

Build Tools are software programs that help in the automation of software build processes. In the context of the video, build tools like WebPack or Vite are mentioned as essential for managing the complexity of modern JavaScript projects, helping with module bundling, code formatting, and maintaining a clean codebase.

💡Server Side Rendering (SSR)

Server Side Rendering is a process where web applications generate HTML on the server before sending it to the client. The video contrasts SSR with Client Side Rendering, explaining how SSR can improve the initial load time of web applications by sending a fully rendered page to the client, thus avoiding the blank page issue associated with client-side rendering.

Highlights

Web development is a place where junior developers aspire to become 'senior' quickly and where debates over frameworks are common.

The speaker admits to being part of the group that complicates web development for job security.

Frontend complexity is described as 'smoke and mirrors', suggesting it's simpler than it seems.

A backend service is explained as either a monolith or microservices, running on a server.

HTTP protocol is used for communication between browsers and servers.

The browser constructs the DOM from HTML to display UI.

CSS and JS can be included in HTML, and browsers may cache files to avoid unnecessary requests.

Multi Page Applications (MPA) involve full page refreshes for user interactions.

JavaScript allows for dynamic updates to the DOM without full page refreshes.

EcmaScript specification updates annually, and transpilers like Babel help with compatibility.

Single Page Applications (SPA) move more logic to the client-side for a better user experience.

WebSockets provide a two-way communication channel for real-time apps.

SPA frameworks like Angular, React, and Vue solve the problem of keeping UI in sync with data changes.

Component libraries help developers avoid reinventing common UI components.

Web Components are a standardization effort for creating custom HTML elements.

Build tools like WebPack or Vite help manage complex frontend codebases.

Client Side Rendering (CSR) can lead to a blank page during app loading, affecting user experience.

Server Side Rendering (SSR) generates static HTML on the server, improving initial load times.

Meta-frameworks build on lower-level frameworks to provide additional features for building performant web apps.

Web Assembly allows building UIs in languages other than JavaScript, like Rust or C#.

The speaker invites feedback and discussion in the comments, acknowledging potential omissions.

Transcripts

Web Development. That mythical place where  script kitties turned “senior full stack  

software engineers” argue endlessly over the most  recent dev trends or the best frontend frameworks  

and then somehow manage to mess up checking  their duplicated React component into git.

This is the place where the low barrier of  entry is artificially raised by so-called  

architects who love complexity for the sake  of job security and where people with resumes  

longer than the time they spent in the sun  call themselves seniors once they turn 25.

And yes, guilty, for the past 15  years I’ve been one of these guys. 

One could argue that I am an expert at getting  paid to waste time in SCRUM meetings or to  

rearrange Material components on admin pages.  But this also gives me the credentials to tell  

you that all this frontend complexity is  smoke and mirrors, and that all you need to  

know about web development can be squeezed  in in a 10 minute video. Let me show you.

Trust me, this is actually really easy. After all,  

the most difficult problem we managed to solve as  a community is to center elements on the screen.

Quick disclaimer. This is not going to  be a video where I’m sharing abstract  

thoughts and random lessons learned  from the past 15 years. This is a  

pragmatic review of all my frontend  knowledge distilled in a short video.

It all starts with a backend service running  somewhere on a server. This could be either a  

monolith meaning a single application that runs  your entire logic, or a collection of smaller  

independent microservices, each tackling  parts of your business logic. This setup  

can be hosted on premise, or in the cloud, but  these details don’t really matter right now.

Just know that these backend services can  be written in various programming languages,  

and their main feature is that they listen  to incoming requests over the HTTP protocol.

The browser sends HTTP requests to various  URLs which contain a verb describing the  

desired action, a list of headers providing  information about the request and the client,  

and an optional request body  containing additional data.

On the server, URLs are mapped to  handler functions. If the incoming  

request is matched by one of the  handlers, the input is validated,  

the business logic is performed, and the  data is updated in your storage solution.

Then, a response is sent back to the client  which contains a three digit status code  

indicating the result of the request, a list  of headers and the actual response body.

Since the client is a browser,  

the response body will most likely be  HTML describing the layout of a page,  

JSON when working with REST APIs, JavaScript,  CSS or static assets like images or videos.

The browser will parse the HTML line by line in a  synchronous manner and the markup will be used to  

construct an in-memory tree representation  of the document structure called the DOM. 

This DOM is then used to display  all the UI in the browser. 

Of course, the HTML can also  contain CSS rules and JS script  

either directly embedded or  as links to external files.

When the browser finds such files,  subsequent HTTP requests will be sent  

to the server to retrieve the data. Caching  mechanisms can be used to avoid requesting  

information that’s already available in  the browser from previous interactions.

So at the end of a request-response cycle  the user will see the requested page in his  

browser. At a minimum, he can interact with this  page via links to trigger other GET requests and  

navigate to other pages or via forms to submit  information to the server. Every interaction  

will cause a full page refresh, and this  architecture is called a Multi Page Application.

But there is a problem. While convenient and  easy to implement, these types of applications  

have one big limitation - the user experience.  This is where all the JavaScript libraries and  

frameworks come into play, and this is what  we’ll focus on for the rest of the video.

This is a good time to mention our  today’s video sponsor - Scrimba.  

I know that all the information shared  in this video might feel overwhelming,  

and Scrimba’s new Frontend Career Path  created in partnership with Mozilla MDN  

will help you both master the basics and learn  the latest best practices for modern web dev.

Scrimba offers a unique interactive  way to learn by doing and have fun  

while going through their courses. A big  chunk of the learning material is free,  

and you can get full access to the entire  courses library with a pro subscription.  

Check out the link in the description  for an extra 20% off your purchase.

The easiest way to improve the UX is to  avoid refreshing the whole page on every  

user interaction. Most of the time just part of  the page needs to be updated so there is no need  

to interrupt the entire user flow. Think of a  button that allows you to remove an entry from  

a movie list. Once the button is clicked,  it is much nicer if we simply remove the  

element from the DOM, instead of doing a full  page refresh. We can do this with JavaScript.

JS is what allows us to implement dynamic,  interactive features in the browser. It  

follows closely the EcmaScript specification  which is updated on a yearly basis. Note that  

the browsers have to add support for all the new  features defined by the specification but this is  

usually a fairly slow process. So you can use a  transpiler like Babel to write modern JavaScript  

which is then converted in code that all browsers  can understand. Or better yet, you can use  

TypeScript to support both the newest EcmaScript  features and strict types in your codebase.

Back to our app diagram, when  a specific action is captured,  

the JS script can perform an  asynchronous call to the server,  

and when the response is received only  the relevant DOM elements will be updated.

Working with the DOM can be somewhat verbose,  

and libraries like jQuery simplify  the dev experience in such scenarios.

However, there is one major  issue. We are performing all  

the async communication and DOM  updates in a programmatic manner,  

and this can turn into a maintenance  nightmare especially in large codebases.

One pattern emerges. Once you start  prioritizing the user experience,  

more of the logic initially implemented on the  backend will be moved on the client, closer to  

the end user. This takes off some of the load  from your servers, and makes the final app feel  

snappier. But there is one major caveat regarding  initial load times. We’ll get back to this later.

So more logic is implemented in the browser  and our JavaScript codebase grows at a rapid  

pace. In this context people started to look  for better ways to organize the code, and this  

is how the Single Page Application was born. The idea is pretty simple. Since we are moving  

more of the logic on the browser, why not let the  browser build and manage the entire application?

So when the browser requests a page,  the server will return an app shell,  

not the actual HTML representing the desired page  layout. Then this app shell loads JS scripts which  

are in charge of building the UI from scratch  directly on the client. Subsequent requests  

will be made to REST or GraphQL endpoints to  retrieve user data or perform various actions in  

an asynchronous manner. The server communication  is done in the background, and all UI updates are  

performed through JavaScript directly in  the browser without refreshing the page.

Quick side note, while most client server  communication is performed over HTTP,  

there are use cases such as messaging  or real time apps where a more flexible  

channel is needed. WebSockets provide a  bi-directional communication channel where  

servers can directly push information  to the client. Compare this with the  

standard HTTP protocol where the client has  to explicitly request data from the server.

Back to the Single Page Apps Architecture,  this is what made web dev infamous. For the  

past 10 years a wide range of frameworks were  released, all tackling the same basic problem: 

UI has to be built based  on templates and user data,  

and then it has to be kept in sync  when the underlying data changes due  

to user or server actions. This is the “big  problem” frontend frameworks are solving.

For simplicity let’s classify the SPA frameworks  in two big categories. First you have your big  

established solutions like Angular, React and Vue.  Then, you have a second generation of more recent  

frameworks which focus on efficiency. Think of  Svelte, Solid or Qwik. As you’ll see in a second,  

when you really think about it, there is  little difference between all of these.

It is worth mentioning that you  also have solutions like Alpine,  

Petite Vue or HTMX which combine some SPA  concepts with the Multi page architecture.  

As you’ll see in a second, while  SPAs were very popular for a while,  

we were forced to get back to Multi Page  or Hybrid Architectures in recent years.

But first, let’s review the  anatomy of a Single Page App. 

Just like URLs are mapped  to handlers on the server,  

in an SPA paths are mapped to UI elements  on the client. Whenever a path is accessed,  

the associated layout is built using  JavaScript and then rendered in the DOM.

Note that regardless of complexity, the UI is just  a tree structure containing components. These are  

small independent units which can interact with  the rest of the app via properties and events,  

they maintain their own internal reactive  state, and they define UI elements in  

some sort of templating solution which is then  translated by the framework in real DOM elements.

If too much of the internal state  has to be shared between components,  

this data can be extracted in a  central place called a state manager.

The really interesting thing here is the reactive  nature of the component. Whenever its internal  

state or the associated properties are changed  by some sort of event, the related UI will  

be automatically updated. In the most basic  example, when the count value is increased,  

the new value is automatically updated in the DOM.  Compare this to the vanilla JS based programmatic  

approach where you have to fetch the actual DOM  element and update its value programmatically.

Keep in mind that at the end of the  day this is what all components do,  

regardless of the framework you are using.  They keep track of user data called state,  

and they perform automatic UI  updates when this data changes.

Yes, React might use a Virtual DOM and dirty  checking to detect changes and update the UI,  

while Solid might use signals to track changes  and will update the real DOM directly. However,  

these are just implementation details  which rarely affect the end product  

you are building. What really  matters at the end of the day  

is your preferred User Experience and the  community support around the framework.

Take design for instance. Most modern web apps  have quite a lot of UI components in common.  

Modals, dropdowns, buttons and form controls  are your usual reusable building blocks,  

and component libraries can help you avoid  reinventing the wheel here. You can still  

build your own components and style them  with CSS or a preprocessor like SASS,  

or, if you can have the best of both  worlds with a Headless UI solution.

It is also worth mentioning that while frameworks  are the go-to solution in frontend development,  

there are efforts to standardize the creation  of custom HTML elements via a suite of different  

technologies collectively called Web Components.  They offer similar features such as reactivity  

and templating but the developer experience is not  really matching the modern expectations. However,  

if you are forced to work with Web Components,  you should give libraries like Lit a try.

Before getting to look at some  of the pitfalls of SPAs and how  

we can solve them, we should take one  small detour and discuss build tools.

One of the consequences of moving so much of  the logic on the frontend is that projects have  

larger, more complex codebases. This code  has to be structured in files and modules,  

for development purposes. For a long while  JavaScript did not have a proper module system,  

so bundlers like WebPack or Vite came into the  scene. Tools like Prettier for code formatting  

and static code analyzers like ES lint can  also help with maintaining a clean code base.

Ok, let’s get back to the SPA architecture  for a second. As you might recall, when the  

browser requests a page for the first time, it  receives back from the server an app shell and  

the scripts needed to build the UI on the  client. This is called Client Side Rendering.  

While the UI is built, your users will see a  blank page on the screen. The larger the app,  

the longer users have to wait until they  can see something meaningful on the page.

This is not the best experience, and,  

as an alternative we can execute the  JavaScript code on the backend first,  

generate the UI as static HTML and then send it to  the browser. This is called Server Side Rendering.

Now, your clients will see a static HTML page  with no event handlers attached to it. Then,  

this HTML has to be hydrated. In other  words it has to be associated with the  

JavaScript code in charge of managing events  or handling internal data. When the hydration  

process is complete your users will be  able to interact with the app as expected.

So with Server Side Rendering your customers will  not see a blank page while the app is rendered,  

but when the server is also involved in  rendering a new set of complexities are  

introduced in the dev flow. The hydration process  can be optimized, client-side routing can be mixed  

with server-side file based routing, multiple data  fetching strategies can be employed and so on.

This is where meta-frameworks come  into play. These are advanced tools  

which build on lower-level frameworks and  provide an additional set of features to  

allow you to build performant web  applications. This is why nowadays  

it is actually recommended to start with a  meta-framework directly and build SSR apps  

which then transform themselves into Single  Page Apps once they are loaded on the screen.

Before wrapping things up please note that we  focused on JavaScript in this video since this  

is the status quo for building frontends.  However, Web Assembly based solutions were  

developed in recent years, and these allow you  to build your UIs in languages like Rust or C#.

I’m sure I missed quite a lot of  tools or ideas you might consider  

important. If that’s the case I’d  love to read your thoughts in the  

comments. Please check some of my other videos,  and, until next time, thank you for watching.