Where to Start in Web Development: Your Browser as Your First IDE

The reality of starting web development may be very confusing in the beginning. There are so many resources, courses, tutorials, and so on—but how do you choose the right one? Moreover, chances are that right from the start you’ll bump into React/Angular/Vue, because they are very popular frameworks, and it might seem like all web development can be done only with one of these frameworks and it begins with picking a "right" framework.

Plus, a lot of tutorials begin by setting up VS Code as the IDE (Integrated Development Environment). You start using VS Code, learn how to write .html and .css files, do some basic JavaScript scripting, and then—for simplicity—you install the VS Code Live Server. You click here, click there, maybe even run npm run... and—boom—your first web app appears in the browser. Enjoy!

But wait—what’s actually going on? localhost? Some port (:3000)? The browser complaining about an unsecured HTTP connection? JavaScript seems weird, and it’s not clear how or where to use it, or what the use cases are. How is the browser displaying your scripts so nicely? What is Node.js, and how did installing it on your PC allow the browser to execute JS scripts? So many questions might come up...

The worst thing you can do is leave these questions unanswered. As soon as you continue learning without truly understanding, these blind spots keep piling up. Eventually, you might realize you can’t develop anything based on your own ideas—at least not without following a step-by-step tutorial—because you don’t really know where to start.

In general, if you’re just discovering web development field and want to begin somewhere, starting with any of frameworks (React, Svelte, Vue and Angular are frameworks)—will only confuse you, because they’re definitely not the tools to start with web development.

Even though, of course, HTML, CSS, and JavaScript (further - JS) are the fundamentals of web development, but don't worry—this article isn't about that you just need to first master them and you will become web dev.

I am assuming that if you want to do web development, your final aim is to learn how to create web applications or websites—basically something that will be running in a browser.

And here is the first question:

How browsers work? What happens "behind the hood" when you open your browser and homepage shows on your screen? How does your browser manage to display all the web sites you visit?

You may be aware of the fact that most of the web applications have a "backend" that is residing on some mysterious "servers".

And here is the second question:

What exactly are the "backend" and "server," and how does a browser communicate with a "server"? Which code is considered "frontend," and which is "backend"? What determines whether some code belongs to one or the other?

If you cannot answer these question, that's "where" you must start in web development—by finding the answer to them.

In this series of articles I will provide the answers to these questions illustrating them with hands on code examples. I will be writing code in a very direct way—no IDEs, no frameworks, no extra stuff. Just a browser, my PC's Linux OS, and basic JS and HTML. Because I also want to show you that you can do many things with just basic tools and that only your imagination is the limit. You don't need React, Nginx, Express, Angular, VSCode Live Server or something else to start trying some web development.

So, let's start!

---

I’ve decided to write a set of articles on web development, rather than pack everything I want to share into one very long piece. This first article in the series—which you’re currently reading—will focus on using the browser as your powerful tool for web development. Here’s a roadmap:

1. Building confidence with a browser
2. 1.1 Open random files in your browser to see what happens.

3. 1.2 Browser's Developer Tools as an IDE (Integrated Development Environment)

4. How does a browser work?

5. 2.1 What is the document?

6. 2.2 Browser's rendering engine

7. 2.3 Document Object Model - DOM

8. 2.4 Browser's JavaScript Interpreter

The second part of this web development series will focus on the browser's networking layer, specifically on URLs, the HTTP protocol, and a few must-know networking concepts in general. Although the networking field in IT isn’t simple, it’s a tough pill you have to swallow - if your goal is to get your web applications to a production-ready stage—rather than leaving them on your PC in some project folder, you must understand networks.

You might question this statement, especially if you’ve already explored the two well-known branches of web development—backend and frontend—and decided that frontend is what you want to do. However, even if you’ve chosen to focus on one, that doesn’t mean you can completely ignore the other. You still need at least the basic concepts and an understanding of how both "branches" work—frontend and backend. The third part of this set of articles will be dedicated to "backend" with a focus on what makes a code "frontend" or "backend".

---

NB! I use Linux, more precisely Debian, and I have an allergy to any other OS. So, if you use Windows or macOS, you might need to google how to do the same things on your system. Anyway, whatever I do in this article is not related in any way to the type of Operational System.

---

1. Building confidence with a browser

If before web development you were just a user of your preferred browser, that golden time is over—now it's your working horse if you're aiming to be a front-end developer. As a user, you might be very picky about browsers, choosing one that suits you. But the moment you decide to do front-end, hehe, soon you will install all the most common browsers for testing purposes—at least one per engine group they use (yes, even Microsoft Edge). I'll explain why later.

So, the browser... Now, I am writing this article in the browser. In a tab I am working I see in the address bar something like this:

https://dev.to/dev-charodeyka/where-to-start-in-web-development-bla-bla/edit

And if I go to any other webpage, I'll see something like:

https://some-site/home

You may have noticed that you can use your browser not only just to view web sites, but also to open images, PDF files, and other types of files. For example, I don't have any PDF reader on my system, so I use the browser to view PDF files if needed.

1.1 Open random files in your browser to see what happens

Okay, so I open LibreOffice, drop some random text, and save it as a PDF on my PC and... I open it in the browser by typing in the address bar: file:///home/lalala/Projects/DEVTO/webdev/randomPDF.pdf.

Little remark: pay attention to how a local file stored on my PC is opened in the browser vs how websites are opened— "file:///home/lalala/..." vs "https://some-site/home..". Do you notice the same syntax? The key part to notice is: https:// and file:// (third / in file:///home/lalala/... belongs to the absolute path of the file). It is important, I will return to this later in the article.

And here is what I see when I open a randomPDF.pdf file in my Browser:

What if I want to view a text file with the same content instead of a PDF?

# first, I create it 
$ vim randomTXT.txt
Hellow!
I am a TXT file!
I am visualized in a browser!

Then I paste this into browser's address bar to open text file: file:///home/lalala/Projects/DEVTO/webdev/randomTXT.txt

As you can see, the text is just text—there’s no bigger font for a title line, because the TXT format does not provide any way to format/style the text... but a Hyper*Text **Markup **L*anguage does—let’s create one!

# first, I create it 
$ vim randomHTML.html
<h1>Hellow!</h1>
<h3>I am a TXT file!</h3>
<p>I am visualized in a browser!</p>

I paste this into browser's address bar: file:///home/lalala/Projects/DEVTO/webdev/randomHTML.html
Here is the result:

Let's add some spice - styling of one word with Cascading Style Sheets - a style sheet language used for specifying the presentation and styling of a document written in a markup language:

$ vim randomHTML.html
<h1>Hellow!</h1>
<h3>I am a random <span style="color: red;">HTML</span> file!</h3>
<p>I am visualized in a browser!</p>

Result:

I demonstrated HTML and CSS in action. If I want to display more text or change the color of some words, is modifying randomHTML.html file and then refresh the browser's page to see the changes is the only way to do it? Heh, of course not.

1.2 Browser's Developer Tools as an IDE (Integrated Development Environment)

First, I have to open the developer tools (hereafter, "dev tools") in my browser. If you're not sure how to open dev tools, you can easily find instructions online. A common method is to right-click anywhere on the page and select "Inspect" from the drop-down menu; however, this option may not always be available, as some websites block it. In that case, you can launch the dev tools from your browser's control panel, where you also can check a specific keyboard shortcut they are usually tied to.

This is how my chromium based browser Brave dev tools look like (the quality of screenshot is not the best due to the automatic compression of DEVTO attachments):

Development tools of my Brave browsers are grouped into Elements, Console, Sources, Network, Performance, Memory, Application, Security. I add/delete/modify HTML elements from Elements Tab.

Using dev tools I can add/delete/modify HTML elements and CSS styles for them "on the fly". Of course dev tools are a pretty powerful tool and are not meant only for these silly modifications, but I just wanted to demonstrate how you can easily experiment with HTML and CSS directly from a browser.

However, keep in mind that whatever I do with the browser’s dev tools doesn’t affect the original .html file that I opened in the browser—all changes will be lost if I don’t save them into a separate file. The same is true for any web page you inspect with dev tools and eventually modify something - of course it does not affect permanently the original page in any way.

Okay, I played a bit with HTML and CSS from Elements tab of dev tools. There’s another interesting tab in these tools called Console, which is an interactive shell where I can write some JS code and execute it!

Some silly "print" of the sum of two numbers and a couple of evaluations of expressions:

//JS code I ran in the Browser's console:
const a = 2
const b = 3
a>b
a===b
a<b
console.log(a+b)

And you know what? Why not add a new HTML element to the displayed .html file's content opened in a browser with JS? Because JS is definitely capable of it:

//JS code I used to add a new text to my HTML document:

//first, I add <div>
const newRandomDiv = document.createElement('div');
//then, I add child of <div>, <p> with some text
newRandomDiv.innerHTML = '<p>Hellow, I was added by JavaScript!!!</p>';
//my HTML document has the <body>, so I append new element as a child of it
document.body.appendChild(newRandomDiv);

However, you might ask: what is the document? I opened the Console of dev tools and haven’t declared any document variable or anything like that—where does it come from? I guess it’s obvious that the document in question is related to the HTML file that’s open in the tab:

2. How does a browser work?

On the screenshot above, you can see that I used the browser’s JavaScript interactive shell to "print" the document. From the output it is clear that it contains HTML elements from the original .html file I opened in the browser, plus some other elements that I added manually by directly editing the HTML structure in the dev tools and also using JavaScript from the browser. However, what was not originally in the randomHTML.html file that I opened are the tags like <html>,<head> and <body>.

The <html> tag represents the root of an HTML document. The tag defines the document's body.
The <body> element contains all the contents of an HTML document, such as headings, paragraphs, images, hyperlinks, tables, lists, etc.

2.1 What is the document?

Everything, that is enclosed between <html></html> tags is the document. And, roughly speaking, that is what web development (front-end part) is about: working on this document - bending it, mangling it, shaping it to make it look how you want. When I opened randomHTML.html file with the browser I loaded this file into the browser, and its content became a part of document object.

When an HTML document is loaded into a web browser, it becomes a document object.
The document object is the root node of the HTML document.
The document object is a property of the window object.
The document object is accessed with: window.document or just document (W3Schools: HTML DOM Documents)

What about the TXT and PDF files that I opened before? Well, their content also become a part of document objects, when I open them in the browser.

This is the .txt file opened in my browser when I inspect the tab's content with dev tools:

<html>
  <head>
    <meta name="color-scheme" content="light dark">
  </head>
  <body>
    <pre style="word-wrap: break-word; white-space: pre-wrap;">Hellow!
     I am a random TXT file!
     I am visualized in a browser!
    </pre>
  </body>
</html>

You may notice how interestingly the raw text file content was "wrapped" into an HTML document object by my browser. It is not uncommon for modern browsers to create a minimal HTML "wrapper" for a content that a browser was requested to display and that it managed to recognize.

In the plain text file, there was no any styling, like the first line in bold and enlarged font. But content of the .txt file has the line breaks. They were preserved by the browser by attaching CSS rules for word-breaking, white space, and word wrapping!

Let's have a look on the document object structure of PDF file opened in the browser:

<html>
  <head>
  </head>
  <body style="height: 100%; width: 100%; overflow: hidden; margin:0px; background-color: rgb(82, 86, 89);">
    <embed name="DDDBE1725B1DA9C2C0B9CFA699CCB3B9" style="position:absolute; left: 0; top: 0;" width="100%" height="100%" src="about:blank" type="application/pdf" internalid="DDDBE1725B1DA9C2C0B9CFA699CCB3B9">
  </body>
</html>

What is similar to a .txt file is that the browser’s PDF viewer is embedded in a minimal HTML document. While with a text file I was able to see the actual file's content directly and even modify it right from the browser, with a PDF file it's not the same. This kind of embedding is actually a byproduct of how my browser handles and renders PDF files.

Can I mess it up with how PDF file is displayed using dev tools even if it is originally PDF file? Sure:

Here is JS code I used:

const redThingy = document.createElement('div');
redThingy.style.backgroundColor = 'red';

redThingy.style.width = '400px';
redThingy.style.height = '400px';

redThingy.style.position = 'absolute';
redThingy.style.top = '50%';
redThingy.style.left = '50%';
redThingy.style.transform = 'translate(-50%, -50%)';

redThingy.innerHTML = '<p>Hello, I was added by JavaScript to <span style="color: yellow;">mess up</span> PDF!!!</p>';

document.body.appendChild(redThingy);

However, obviously, this red box with text didn’t affect the PDF file itself in any way. What my modifications actually affected was just how my browser rendered the opened PDF file.

I guess it’s time to summarize the point of all of these experiments.

As you can see, a browser is a powerful tool. It's not just an "app" to open websites with added features like a photo viewer or PDF viewer.

2.2 Browser's rendering engine

Any browser has its own engine that renders what you see on its User Interface (UI). Roughly speaking, to render anything a browser uses instructions in a markup language—HTML.

Different browsers work differently. However, let me explain the process slightly generalizing:

1. When you enter a query in the browser's search bar (a URL), networking layer of the browser delivers your "request" to a destination point that is retrieved from URL and bring back to browser a response which could be any type of file or data. Some file types can’t be displayed directly (for example, if the file is corrupted or has an unrecognized format), in which case the browser may display an error or prompt you to download it instead.
2. If the received data is recognized as HTML, the browser parses it to build a Document Object Model (DOM) tree. This process involves reading the HTML and turning it into a structured hierarchy of nodes that represent the page’s elements. If the received data isn’t HTML but the browser can still display it (like plain text or PDF), the browser will process it in a specialized way. For plain text files, most browsers apply a minimal HTML “wrapper”; for PDFs, the browser’s PDF viewer is embedded in within an HTML context, so browser can position it, handle scrolling, zoom, and so on.
3. The browser then creates or updates a render tree, which is the combination of the DOM and the CSSOM (the CSS Object Model). The layout step figures out the exact positions and sizes of all elements on the page.
4. Finally, the browser paints (or “rasterizes”) the render tree onto your screen. This is what you actually see in the browser’s viewport.

There are many variables in the rendering process. Every element in the DOM tree is an object that the browser needs to render by calculating its position (this is where responsive design comes in, since an element’s positioning depends heavily on the available space on the user’s device), appearance, and any dynamic changes. The DOM tree isn’t static; the browser continually re-renders it as elements move or change appearance—like those animations you see on some websites.

2.3 Document Object Model - DOM

I want to elaborate more on the DOM tree.

The backbone of any HTML document is its tags. In the Document Object Model (DOM), every HTML tag is an object. Nested tags are considered “children” of the enclosing tag, and even the text inside a tag is treated as an object. The DOM represents HTML as a tree structure of tags. (Source)

<html>
  <head>
  </head>
  <body>
    <h1>...</h1>
    <div>...</div>
    <...>...</...>
  </body>
</html>

You can notice the nested structure of HTML document: each tag is an object, and the nesting forms a tree-like hierarchy.

I'm repeating this: if you're aiming to be a front-end developer, the DOM is everything. In front-end development, almost everything ultimately revolves around DOM manipulation. I've shown how to manipulate the DOM using browser's dev tools—adding HTML elements, applying CSS, and most importantly, doing it through JS. Because in front-end development, JS is primarily about manipulating the objects in the DOM tree, which are (at their core) HTML elements.

All these DOM objects are accessible via JavaScript. I’ve only shown a small part, and it might have seemed very easy. Well, it was easy because I was working directly with those DOM objects—there were only a few, and everything was clear.

But remember this: the JS libraries you use to "simplify" certain features—and especially any framework (React, Angular, Vue, etc., though each to a different extent)—actually take you one step further away from direct manipulation of the DOM objects.

Frameworks abstract direct DOM manipulation, so you write your code in a more declarative way. Behind the scene, any framework still manipulates the DOM — but you interact with a framework’s abstractions instead of directly selecting or updating DOM elements.

The key point is that these abstractions are not "bad" - they make development more efficient and your code more maintainable, as long as you have a basic understanding of how the DOM works. If you rely on abstractions without knowing what’s happening underneath, you are cooked. No fancy framework will make you a good developer if you don’t at least keep the DOM tree in mind whenever you manipulate it with JS.

I’ve shown how to do manipulate DOM directly in the browser—not to promote this style of coding (obviously, no one codes like this for a full project). I just wanted to show you what your browser is truly capable of. Everything I did was handled entirely by the browser—there was no server behind it, no external tools, just the browser.

2.4 Browser's JavaScript Interpreter

And this leads to a very important point: I was able to execute JavaScript in the browser because browsers have a built-in JavaScript interpreter. Think about it—if you’re a Python developer, before you could run Python code, you had to install Python on your PC (unless you're on Linux, where it's usually pre-installed). That’s because Python isn't machine code, so your PC can’t understand it without an interpreter. The same goes for JavaScript. The key point is that modern browsers come with a JavaScript interpreter embedded in their engine.

Sounds great, right? But here’s the cornerstone: different browsers have slightly different JavaScript interpreters inside their engines. For basic, standard JavaScript usage, this isn’t a big deal. But when you get into non-standard usage, things get trickier. And every external library you add to your code potentially brings you slightly closer to using a JS in "non-standard" way that may be not supported by some browsers. And these browsers may be the favorite browser of potential users of your web applications :).

To conclude, here is a very generalized scheme of how browsers work:

In the next article of this series on Web Development, I’ll elaborate on the format of the "query" you see in the browser’s search bar, as well as the role of "servers".

This query format is very important—I’d even call it crucial— because the routing in your future web apps result in these "queries".

Jumping ahead, I should mention that "query" is actually a bit of an oversimplification of what appears in the address bar, because the correct technical term is URI (Uniform Resource Identifier). The true query is just one part of a URI, and URIs are closely tied to the HTTP protocol in web development, which in turn is tied to networking.

In the next article, I’ll do my best to simplify and clarify all these concepts!

---

Summarizing the main points:

• Browsers have a built-in JS interpreter and they do run JS code.
• The browser’s JS interpreter is not the same as your PC (or server)’s JS interpreter—they’re different. Keep this in mind.
• The internal components of browsers are complex, and each browser implements them differently. In my humble opinion, that’s what makes the frontend part harder than the backend in modern architectures.
• You need to understand both backend and frontend to be a good web developer—you can’t just master one and completely ignore the other.
• In front-end development, almost everything ultimately revolves around DOM manipulation (= you have to understand the concept of DOM as clear as possible)
• If "network" for you only means "the Wi-Fi at home", you must invest your time in studying networking.