Script in Head vs Body

(nothing placed in the Head should be visible to the user)

When the browser encounters the script tag, it will block progress on parsing the rest of the HTML on the page as it downloads (if external) the script file and executes it.

In the past, this meant putting script tags at the bottom of the body.

The modern approach is to use async or defer.

While the browser is downloading the script, it is also continuing to parse the HTML. It will execute the script as soon as it is done downloading.

Keep in mind, async scripts are not guarenteed to run in a specific order, and you should not use document.write. Instead, add event listeners:

defer:

The browser will download and execute the scripts in order after the document has been loaded.

What makes a website slow?

• Place CSS tags before JavaScript tags: Load CSS before JS because the browser will stop to load the script before CSS can be displayed
• Minify HTML, CSS, and JS: Remove whitespace and new lines to reduce size and speed up load time. Significant for CSS/JS, as this means less data is sent to the client
• Critical CSS: In-line code the CSS needed to load the first display that the user sees, then load non-critical asynchronously (the JS function is a third-party that loads CSS aynchronously):

• Unoptimized Images: Use CSS or SVG instead if possible. JPEG is usually faster (more compressed).
• HTTPS is slower because it's more secure, so browsers allow more options (geolocation, push notifications, etc.)
• Make fewer requests by combining external CSS, JS, etc. files
• Cache-Control: A HTTP header that allows you to cache things (like images, CSS/JS files, etc)
• Prefetching: Tell browser to load other pages in advance after the main one is done, in case the user navigates to it next. (rel="prefetch")
• Use a CDN: Content Delivery Network, edge servers all over the world so a user can fetch content from the one closest to them. Edge servers just store a cache of the pages

Web Architecture

• Basically, your browser asks your router which asks your ISP (Comcast, etc) which searches the DNS (Domain Name System), which finds the computer the desired website is on and returns it to you to connect to. The DNS is like a phonebook: looks up the requested domain name and returns the IP address of the machine it's on.
• Request - an ASCII-encoded text sent to a server:
  POST https://postman-echo.com/get?arg1=value&arg2=query2#fragment_id
  
  • Verb/Request Method: GET, POST, PUT, DELETE. (also HEAD, etc.)
    • Safe vs Unsafe: GET and HEAD are safe (do not change anything), while others are unsafe
    • Idempotent vs Not Idempotent: GET, HEAD, PUT, and DELETE are idempotent, meaning making the same request multiple times will have the same end result
  • Scheme/Protocol: tells the browser how to send the request, and how to make sense of the response
    • http:// - HyperText Transfer Protocol
    • https:// - HyperText Transfer Protocol Secure
    • ws:// - websocket
    • ftp:// - file transfer protocol
  • Hostname: assets.company.com
    • subdomain: assets.company.com
    • domain: assets.company.com (this is the only required one)
    • top level domain (tld): assets.company.com
  • Port: .com(:443)/ ...
    • Every request has a port, even if hidden
    • They allow things on the internet to talk to things on the server
    • http assumes port 80
    • https assumes port 443
    • When developing on local server (http://localhost:8080), try to use a non-privileged port. Ports 1-1023 are special (privileged)
  • Path: anything after the url and before the ? is the path. It says where to go.
  • Query Arguments/Strings: ?arg1=value&arg2=query2
    • Start with ?, key/value pairs of arg=value, each separated with &
    • If there's an = without a value, the key will exist and the value will be an empty string
    • Used to filter the result, for example a site filtering 4k monitors by Dell: .com/monitors?res=4k&make=Dell
  • Fragment Identifier: #fragment_id like an anchor on a page. The server isn't told this information. Some apps use this to display parts of the app without needing to make network requests.
  • Headers: not visible in a URL, but it contains information on cookies, the host (domain), etc.
  • Body: only for POST, PUT, PATCH, (and some) DELETE requests, the body is the "what", or the content of the request.
• Response
  
  • First line is the protocol version, status code, and status line
  • Next is the response headers.
  • Then a blank line separating metadata (top) and the body content (bottom).
  • Body can be a JSON payload if sending the request to an API
  • Responses can be from either the web server or the application
  • Status Code: what the server did with your request
    • 200 OK, 201 Created, 204 No Content - Generally are good, means everything went as expected
    • 301 Moved Permanently, 302 Found, 304 Not Modified (when you're downloading something but already have a local copy of it cached) - Redirection. Things weren't where you thought it was
    • 400 Bad Request (request is not understood), 401 Unauthorized (need to log in), 403 Forbidden (logged in, no permission), 404 Not Found (asking for something that's not there), 405 Method Not Allowed (e.g. sending POST when the endpoint only accepts GET) - server is ok, but you need to modify the request
    • 500 Internal Server Error (code error), 502 Bad Gateway (code error), 503 Service Unavailable (server is too busy), 504 Gateway Timeout (server is too slow) - Server is failing
• SSL (now TLS) - Secure Socket Layer (or Transport Layer Security)
  • TLS is the modern version of SSL, but since the terminology got stuck, SSL is now referred to for both SSL + TLS
  • HTTPS = HTTP + TLS:
    HTTPS is an implementation of TLS on HTTP to secure the connection
  • TLS is needed because on old HTTP sites that haven't been upgraded yet, the connection is insecure, leading hackers to get your data if they have access to your router info, or your ISP can inject ads, etc.
  • TLS provides integrity (content cannot be tampered with), encryption (content cannot be read by others), and authentication (you connect to the server you should be on)
  • The Process:
    1. The browser requests encryption from the server, and sends the encryption protocols it supports
    2. Server agrees, and selects a protocol they can both use. It also sends their SSL certificate (to prove that they're them), and a random string it just generated
    3. Browser double-checks the certificate, and sends a generated random string
    4. Both ends have both strings. The client has the server's PUBLIC key it got from the certificate, and the server has their own PRIVATE key. Using these, both sides should arrive at the same generated code
    5. Browser tells server what code it got, and vice versa
    6. If they match, that code is now the key for the session, and everything else will be encrypted with that key
    7. Whenever the client asks for something, the request will be encrypted with that key and unintelligible to anyone else that may be looking
    8. Similarly, the browser's responses will be encrypted
• Domain - human-friendly address of a website. Computers communicate sites using IP addresses, while people use domains
• Registrar
  • Registry - a list that keeps track of Top Level Domains (.com, .co, .edu, etc)

Soft Skills Q&A

• Introduction: 6 years at IBM, previously CS major at Georgia Tech and worked on campus as a full-stack developer. As a software consultant, worked on various projects honing many different skills, such as communication with clients to Javascript, API connect, and UI/UX design. I enjoy working on front-end design and development challenges the most, and am interested in deeply pursuing this direction. I'm most interested in React development and learning to apply the IBM Carbon design system. I like that this position offers the opportunity to work closely with UX designers, as that's also a field that interests me a lot. I've completed the co-creater badge for Enterprise Design Thinking, and many of my close friends are UX designers, so I learn a lot from them too.
• Why programming?: enchanted by computers since I was young, built webpages for Neopets back in the early 2000s, which things like marquee were popular and CSS wasn't that big of a thing
• How do you stay up to date?: (meetups, communities, show how passionate you are) Can't escape web dev, since using the internet everyday, I'm always curious about how other sites are being built so I learn a lot just from that curiosity. To brush up and keep updated on React, I completed an online course that has its own discord community, and contribute regularly with helping people with questions (since teaching is the best way to learn). I also like working on personal projects, such as game jams.
• Why you?: what makes you unique? why are you better? 3 things that make you unique & proud: UX Design, Game development, etc.
• Why the company?: what interests you about the company? how does it align with your interests?
• Biggest/Most difficult technical/professional achievement?: something you're proud of, can brag about, maybe a conflict at work you helped deescalate
• Conflict at work, how did you react?
• Time you messed up, how did you react?
• Why are you looking to leave your job?
• tell me about your projects, what project did you enjoy the most - why? Note: I was advised to highlight my strengths / past achievements / past work experience irrespective of the field in which you worked (which I was clearly not good at.)

Ask the Interviewer:

• What's the project/team I'll be on?
• What code quality standards does the organization follow?
• Will the code have to support IE11/legacy software?
• Best/worst part of working there?
• Why are you interested in hiring me?
• Have a final statement that relates to your strengths in this role, to make them remember you positively.

etc?

Cache? difference between a variable that is: null, undefined or undeclared (also how to check)?a/b testing system?

python -m http.server

CommonJS vs AMD

SCSS: sass --watch input.scss output.css

Dot Game

https://www.indeed.com/hire/interview-questions/front-end-developer

Write an async queing function that execute functions put in a que. between each function execution, wait 50 mils. (know promise resolution syntax)

"When you feel yourself struggling, it means you're separating yourself from the crowd. It means you're learning something that a lot of people would've given up on by now. So embrace that feeling rather than be discouraged."

Web Design

Accessible and User-Friendly

• Check screen width for multiple devices using 12-column Responsive design format
• Tab Order
• Colorblind

HTML5 Features

• Headers/Footers
• Nav (can go in Header)
• Videos
• Sections

Browser Compatibility

• browser-specific workarounds, how diff browsers render differently, browser-specific problems
• Also, -webkit for MacOS
• Internet Explorer / Microsoft Edge is probably least compatible

Structure your CSS and Javascript for Working with Others

• Organization: Folders, External files, etc.
• Commenting / Documentation

Always-be-Learning

• Learn from MDN Docs
• Interest in React/Angular
• NYC Developer Meetups, there's a group called Codesmith that hosts workshops on more advanced concepts such as Closure and Iterators.

Useful Resources

• Website Color Schemes: https://www.happyhues.co/
• Negotiating Offers: https://haseebq.com/my-ten-rules-for-negotiating-a-job-offer/