We will study how web browsers work by building our own web browsers from scratch in python.
The course is based on the online textbook Web Browser Engineering. We will cover one chapter per week of the book, for 10 weeks. The calendar page is the best place to get up-to-date information about the schedule.
Each week, students will implement 1 core feature in their browser, plus several extensions. The core feature is covered in detail by the corresponding book chapter. The implementation of this feature usually involves some refactoring of existing code, as well as understanding the content of the book and putting together the starter code into a working implementation. The remaining extensions are exercises that extend the core feature of the week with additional functionality. These exercises will be selected from the list of exercises at the end of each book chapter.
"Week N" of the course proceeds as follows.
Week 1 and Week 10 are a little different. See the schedule.
There are no quizzes or exams.
Lectures may be recorded and made available to all students. They may also not be recorded. Lecture notes will definitely be available for those who cannot attend a given lecture.
gilbo@cs.washington.edu
abagaria@cs.washington.edu
azaank@cs.washington.edu
wj428@uw.edu
You can email the entire staff at
cse493x-staff@cs.washington.edu
,
but we usually prefer you make a private post on Ed if possible.
The best way to contact the staff is to make a post on Ed. If your question is likely to be useful to other students, please consider making it public. (You can make the post "anonymous" to hide your identity from your classmates, but note that course staff can still see your identity on anonymous posts. See anonymous feedback at the very bottom of this page for submitting feedback without revealing your identity to course staff.) If your message is not relevant to other students, make it private. We prefer you send messages via Ed if at all possible, because it allows any staff member to assist you. If you need to contact an individual staff member directly, you can also use email.
Please note that the staff all have busy lives. Do not assume that you will get responses more quickly than 24 hours from when you ask a question. (though we will try to be responsive) Likewise, do not assume that staff will respond on weekends. (This is a good reason to get assignments done by Friday.)
There are three kinds of assignments in this class:
For the browser programming assignments, we have created a Gitlab repository for each student containing starter code and a description of the assignment. Each student should clone their repository, do their work there, and commit and push it back to Gitlab, and then submit on Gradescope when completely finished.
For "typing", we will collect volunteer names at the beginning of each class or section in which students live code. Then each typist will get about 10-12 minutes as we work through the exercise.
The debugging post-mortems can be submitted using a form provided on the debugging post-mortem page.
The class will be graded on an additive points system.
In total, there are roughly 2100 points available, assuming you are a typist once and not including any debugging post mortems.
The course is not curved. Your grade on a 4.0 scale is computed by the following formula.
In other words, your grade will be computed by the following table:
Points | Grade on 4.0 scale |
---|---|
≥1972 | 4.0 |
≥1914 | 3.9 |
≥1856 | 3.8 |
≥1798 | 3.7 |
≥1740 | 3.6 |
≥1682 | 3.5 |
≥1624 | 3.4 |
≥1566 | 3.3 |
≥1508 | 3.2 |
≥1450 | 3.1 |
≥1392 | 3.0 |
... | ... |
≥1218 | 2.7 (grad sat) |
... | ... |
≥ 812 | 2.0 (undergrad sat) |
... | ... |
Every homework has a 48-hour grace period, during which work is accepted without penalty. No credit after the grace period expires.
Note that, unlike some other course policies you might be familiar with, in this class there is no cap on how much total grace time you can use over the quarter. You can use all 48 grace hours on every single homework and still get full credit.
Please read CSE's Academic Misconduct Policy.
You are encouraged to discuss all aspects of the course with and ask for help from the instructor, the TAs, and other students. However, do not cross this line:
Do not share code or written text. Do not look at lab or problem set solutions that might be on the Internet. Do not use someone else's code or text in your solutions or responses.
It is ok to share ideas, explain your code at a high level to someone to see if they know why it doesn't work, or to help someone else debug if they've run into a wall.
Chatbots powered by LLMs and LLM-powered code completion features in text editors have become very popular. Many of you probably use Co-pilot or ChatGPT. Here is our policy on what is and is not allowed.
I do not want to waste my time or your time policing you, trying to catch cheaters, etc. We're all here to learn and we're all adults. So by default I am going to trust you. This trust is sacred. Do not violate it.
The upside of the trust approach is that we don't waste time trying to catch cheaters, and you don't waste time trying to prove you're not a cheater. The downside of the trust approach is that if I find out you are breaking the rules, you will not get leniency or understanding from me. (e.g. I am happy to fail anyone caught cheating from the class.)
Anonymous feedback can be sent to the instructor or TAs via
feedback.cs.washington.edu
.