Lesson: Web Development Overview
May 31, 2019
HTML
RAZOR
BLAZOR
ASP.NET
SQL
AJAX
Server Side Rendering
Client Side Rendering
JS
CSS
HTTP
Canvas
WASM
Flex
WebSockets
Objective
User
Browser
Internet
Server
Presentation
HTML / CSS
Applets
Flash (Flex) (AS)
Canvas
WebGL
HTML
Provides a basic set of elements that can be extended with CSS & JS
Pure HTML can only make the simplest of sites
HTML without JS or CSS is nearly worthless but back in the day it was more common
The DOM
The HTML elements you are viewing do not typically match HTML that is contained in a file.
HTML is a technically a syntax while the DOM is a collection (tree) of objects in memory.
Browsers expose an API (the DOM API) to manipulate the DOM to scripting engines.
Example: dom.html
CSS
The DOM describes the content on the page.
CSS describes how that content is presented.
CSS makes heavy use of “selectors”, a concept that was then added to the DOM as well.
Example: Zen Garden
Example: selectors.html
Semantic HTML
There are multiple ways to write something in HTML (example)
Semantic HTML basically states that just because you can, it doesn’t mean you should.
Semantic elements: section, article, nav, summary, aside, etc.
Why not?: Accessibility, SEO
Example: semantic.html
Canvas
It’s not (really) HTML but it hooks into it.
Allows reasonably efficient pixel-level control of the page
Uncommon but important for certain applications
Low level (no layout manager, etc.)
Example: canvas.html
WebGL
Exposes an OpenGL style interface
Can do sophisticated 3D graphics
Utilizes the client’s graphics card (if any available)
Even lower level than canvas
Scripting
Javascript
Applets
Flash (Flex) (AS)
WASM
Why Scripting
Scripts allow for manipulation of the DOM outside the limited model exposed by HTML
Example: Wikipedia.org (very little scripting)
Example: Discord.com (massive scripting)
“Web 2.0” (https://en.wikipedia.org/wiki/Web_2.0)
-Static
-Dynamic
The Sandbox
Browser
OS
FileReader
Audio
WebGL
DOM
Scripts
HTTP
Remote Server
The Sandbox
JVM
OS
Java Standard Library
Java Program
The Sandbox
Virtual OS
OS
Virtual OS Libs
Programs
Top 10 anime comeback stories: JS
In 2000 JS had the same reputation PHP & Perl do today...and it deserved it.
Slow.
Unpredictable. Easy to shoot yourself in the foot (JS the good parts)
Primitive (limited OOP support, no module support, etc.), poor standard library
Flash / Flex was the natural successor but there was just one small problem. It took a lot of work for browsers to maintain and they couldn’t profit off of it.
Chaos is a ladder
Google, being Google, murdered Flash. This created a power vacuum.
Slow. Google’s v8 engine started doing really fancy JIT compilation stuff and was open source so M$ could use it.
Primitive. There is now more tooling and more libraries for JS than any other language by a long shot (except maaaaybe Java).
Unpredictable. Ok...you can’t fix everything. Still, if you are using TS, etc. it is a little safer. Introduction of let/const, proper classes, etc.
Confusing. Javascript is now slowly settling but is in a very chaotic time.
Chaos is a ladder
JS Today
Could go on for hours
ES vs JS
Babel / TypeScript / CoffeeScript
WASM (when you hate learning new things)
Designed to be a universal assembly language
So it can’t really do anything other than manipulate memory.
But hey...all code is pretty much just manipulating memory.
Stack based, similar to IL.
C++
C#
Java
Rust
WASM
Sandboxed!
Browser
OS
FileReader
Audio
WebGL
DOM
Javascript
Browsers are the biggest anti-virus tool out there.
WASM
WASM Example
SignalR - Who really needs scripting!?
There is a debate that has been going on for ages about how much JS to use vs. how much backend to use.
For example, the extremists on the JS side won’t even make a backend call to load a new page, they simply rewrite the DOM from JS.*
SignalR is a tool for the extremists on the backend side. The idea is to use the backend for as much as possible, if not everything.
*This is called a SPA and we will discuss later.
New DOM elements need to be created for javascript & arrays tags.
�The list of available tags lives on the server.
SPA - Call an API method to get list of available tags, manipulate DOM.
�SignalR - Create the DOM elements on the server.
Transport
HTTP(s)
HTTP2
WebSockets
Server Sent Events
How to talk to others
A website might need to…
Load the initial HTML document
Load a JavaScript script
Load some images
Fetch the current user
Get the current user’s list of friends
Mark a post as “liked” because the user clicked something
Transport
What do we start with?
Wifi/LAN cable (Don’t care)�Ethernet (Don’t care)
IP (e.g. IP address)
TCP (e.g. port number)
^--Provided by OS
TLS (a.k.a. SSL, e.g. certificates)
^--Provided by language
DNS (Maps name to IP address)
If we have an IP address and port number of a remote computer we can send bytes to that computer and receive bytes from that computer.
TCP has concept of client/server (one side is listening for connections, the other is opening connections) but once the connection is established it is 2-way.
Example: Telnet
Transport
A website might need to…
Load the initial HTML document
Load a JavaScript script
Load some images
Fetch the current user
Get the current user’s list of friends
Mark a post as “liked” because the user clicked something
Sending bytes back & forth
We Have (too generic)
We Want (too specific)
A protocol is a set of rules for structuring bytes into a more abstract concept like a “message”.
Need something here
What do we need?
Transport
What do we get?
HTTP (1989)
Method: What do you want to do (GET / PUT / POST / DELETE /…)
URL: What do we want to perform the action on?
Version: Boring, not useful for us
Headers: Freeform metadata that has been around long enough there are lots of standard fields.
Entity Body: If we are creating or modifying something then this is the thing we are creating or modifying.
Tim Berners Lee
Example: telnet
HTTP
A website might need to…
Load the initial HTML document (GET http://mycoolpage)
Load a JavaScript script (GET http://mycoolpage/script.js)
Load some images (GET http://mycoolpage/favicon.ico)
Fetch the current user (GET http://mycoolpage/users/current)
Get the current user’s list of friends (GET http://mycoolpage/friends)
Mark a post as “liked” because the user clicked something (PUT http://mycoolpage/posts/732/liked (body tells if we liked it or not))
We Want
How does it solve our problem?
Mission Accomplished (not really)
Mark a post as “liked” because the user clicked something
Too generic
Should I use PUT or POST?
Should I name the URL /posts/732/liked or should I name it /actions/like-post
Should I put whether I liked it in the HTTP body? Or should I put it in the URL as query parameters?
If I put it in the body should I use a JSON document? XML? Form parameters?
Maybe I could use one URL for EVERYTHING and then in the body I can list the name of the operation as well as a list of arguments! I could solve this problem once and for all for my entire code base!
This is SOAP. Nobody likes SOAP. Don’t be like SOAP.
Is HTTP an RPC protocol?
Thought exercises are fun!
An RPC protocol is designed for making remote procedure calls.
Examples include SOAP, GRPC, .NET remoting
An RPC protocol usually includes the name of the operation and a list of arguments
HTTP by itself is not technically an RPC protocol because you need extra information on how to map the call (method / URL) to the operation (name / arguments)
What is REST?
REST is...just do it!
REST is so overused that the only thing you can safely assume is that people are talking about HTTP but not SOAP.
But..
REST is the philosophy that you should not map HTTP to your API. You should definitely not make your API look like an RPC API.
Instead, you should design your API to match HTTP.
Examples:
It is not “login” it is “PUT the current user”. Logout is “DELETE the current user”
It is not “addFriend” it is “POST to the freinds list”
It is not “isEmailInUse” it is “GET the list of emails matching this name”
Your entire API is just a collection of documents that can be fetched and modified.
What if I don’t like it?
Tough ****
Sockets are not just too generic. They are too dangerous!
We aren’t navigating the world with our wits and telnet. We are navigating the world with our handy dandy web browser.
The browser limits our access to the OS. Instead it gives us HTTP.
This is a browser (obviously /s)
The browser uses HTTP
When you type in a URL and press enter it issues a GET
When you click on a link it issues a GET
When you submit a form it issues a GET or a POST
Script tags, image tags, and so on will also result in a GET request.
Scripts themselves can issue their own HTTP requests...
Scripting APIs
As a script what do I get?
There are two major APIs for making HTTP calls across browsers.
XHR - Older, callback based. The X stands for XML but it has nothing to do with XML.
Fetch - Newer, promise based. Not supported by IE (and never will be).
Also, XHR was so difficult to use that there are a whole host of open source wrappers (e.g. jQuery) but they all use XHR under the hood.
The late 90s were great.
Example: fetch
Flaws of HTTP
Well...no one is perfect
Performance: ASCII is slightly less compact than something like protobuf. This concern is greatly overblown.
One-Way: HTTP is a request / response protocol. There is no way for two-way communication. For example, a chat room.
Too Generic: HTTP is too generic. There are too many ways to solve the same problem.
Too Specific: HTTP is too specific. Give me back my plain old bytes!
Numerous workarounds have been proposed. The most common is “long polling.” The client makes an HTTP call like (GET /notifications) and the server doesn’t answer until it has data to send. The client then makes the call again. This is also sometimes called “comet”
Fixes for HTTP flaws!
It pays to live in modern times.
Gives an API to scripts that looks a lot like TCP sockets (but not exactly the same).
It’s kind of built on top of HTTP. It starts with an HTTP-conformant handshake but once the handshake is complete it switches to something that is NOT HTTP compliant.
Allows the server to send events (fancy that).
It’s built on top of HTTP. The “body” of the response is basically infinitely long so it looks like one massive HTTP response. However, the browser knows to process it on the fly instead of waiting for it to complete.
Server Sent Events
WebSockets
Rules of Engagement
All the cool stuff lives on the server (or is accessed through the server). Our game state, or corporate database, or social media megadata super store, paypal interface, bitcoin mining operation, etc.
HTTP is the language spoken by the browsers
HTML / CSS / JS (WASM) are the tools the browser gives us.
On top of that we have millions of open source libraries, hundreds of mega frameworks, dozens of architectures and approaches.
Static Content Vs. Dynamic Content
Static content never changes. The exact same information is delivered everytime a website is visited. Some of the HTML, the JS scripts, images, etc. all tend to be static.
Dynamic content is based on mutable server data (you know...dynamic data). It changes based on what is in the database or server memory at any given time.
Almost every website is a blend of both.
Apache
Kestrel
Disk
Caches
Sessions
Example: SO / Google
Sample Deployment
Server side vs. client side rendering
Rendering: Turning data -> presentation (HTML/CSS)
AKA: How much do you hate JS?
Server (C#)
Browser (not C#...until now)
Data
Hipsters: King of client side rendering
I invented JS on the server so I could use JS ironically but then my food truck tanked and this NodeJS thing started making major money. Google gives me all kinds of money to lure developers into my weird cult now so that they can shit on Microsoft and I get piles of cash.
Microsoft: King of server side rendering
Microsoft’s browser was IE. They have historically hated JS. It should come as no surprise that they hate any kind of complexity in the browser whatsoever. (^_-)≡☆
Classic ASP - Server side rendering
ASP.NET MVC - Server side rendering
Razor Pages - Server side rendering
Blazor - Server sid...wait...I can do C# in the browser now? Client side rendering is AWESOME
Hybrid approach
You can always do a little of both.
Example: ASP.NET MVC with SignalR
The truth: It doesn’t matter...do what feels good
Web 2.0 & AJAX: Marketing gone wild
I wish I were making this stuff up
AJAX - Asynchronous Javascript & XML except…� It doesn’t have to be asynchronous
It doesn’t have to involve JS
It’s almost never XML these days
Web 2.0 is just the idea that web servers can grab data from the background and not redirect the user. Kids these days will never understand. Back in the day...
Web 3.0?�Semantic web?
SPA?
SPA - Single page application
Not SPA - Not a single page
Example: Reddit vs StackOverflow
Relationship to server side rendering vs client side rendering
Tools of the trade
HTTP Server: IIS / Kestrel / Apache / Nginx
Proxy Server: Apache / Nginx (wait...am I repeating myself?)
Application Framework: ASP.NET
Rendering Framework: ASP.NET MVC, Razor, Blazor
Example: WOTD