mattly · May 29, 2019 21:47
diff --git a/frontend b/frontend
 Programming for something on the server typically looks like this:
     * Something happened that you need to respond to. A request, a queue item, etc.
     * You hydrate any state not included in the event from a cache or database or somewhere.
     * You do whatever processing you need to do.
     * You persist any new state that needs to be persisted
     * Maybe you respond to the event if needed, or trigger other side-effects.
     
 This typically happens on a computer you control, with lots of layers of control around making 
 sure the event is properly-formed and handled in a kind of queue, to make sure you're making the 
 best use of your resources, and events are coordinated and dispatched properly.

 You can take a lot for granted, and to a certain point of scaling, I'd consider it 'easy mode'. 
 Making it so is I think the point of all the infrastructure tooling that's become prevalent lately.

 In contrast, programming for a user interface involves:
     * You're running on a device you don't own or control.
     * In the browser, you don't even have control of the runtime.
     * You might have to ask the user permission to do some thigns you
       want to do, such as get their location or send them notifications.
       If they decline those permissions, you have to deal with it.
     * You're often sharing the limited memory and processing resources
       of the user's computer with other things.
     * You can't assume good network access.
     * You're dealing with a lot of disparate events from one place:
       user clicks, keystrokes, window resizes, ajax responses, network
       offline/online notices, etc.
     * In the browser, you're doing this in a single thread.
     * Some of these events come from an unpredictable and easily-frustrated user.
     * Time becomes important in figuring how some of the events relate
       to each other.
     * State management is entirely up to you.
     * Persisting state locally and remotely is entirely up to you.
     * Translating state changes to view changes is entirely up to you.
     * To compound these problems, your user interface is the face
       of your product that people see. If it behaves poorly and unpredictably,
       people are much less forgiving than they are if you communicate errors
       properly. Instagram survived day-long server outages, Twitter survived the
       failwhale, but I don't think either could have survived a janky interface.
 So, no pressure or anything.
	Programming for something on the server typically looks like this:
	* Something happened that you need to respond to. A request, a queue item, etc.
	* You hydrate any state not included in the event from a cache or database or somewhere.
	* You do whatever processing you need to do.
	* You persist any new state that needs to be persisted
	* Maybe you respond to the event if needed, or trigger other side-effects.

	This typically happens on a computer you control, with lots of layers of control around making
	sure the event is properly-formed and handled in a kind of queue, to make sure you're making the
	best use of your resources, and events are coordinated and dispatched properly.

	You can take a lot for granted, and to a certain point of scaling, I'd consider it 'easy mode'.
	Making it so is I think the point of all the infrastructure tooling that's become prevalent lately.

	In contrast, programming for a user interface involves:
	* You're running on a device you don't own or control.
	* In the browser, you don't even have control of the runtime.
	* You might have to ask the user permission to do some thigns you
	want to do, such as get their location or send them notifications.
	If they decline those permissions, you have to deal with it.
	* You're often sharing the limited memory and processing resources
	of the user's computer with other things.
	* You can't assume good network access.
	* You're dealing with a lot of disparate events from one place:
	user clicks, keystrokes, window resizes, ajax responses, network
	offline/online notices, etc.
	* In the browser, you're doing this in a single thread.
	* Some of these events come from an unpredictable and easily-frustrated user.
	* Time becomes important in figuring how some of the events relate
	to each other.
	* State management is entirely up to you.
	* Persisting state locally and remotely is entirely up to you.
	* Translating state changes to view changes is entirely up to you.
	* To compound these problems, your user interface is the face
	of your product that people see. If it behaves poorly and unpredictably,
	people are much less forgiving than they are if you communicate errors
	properly. Instagram survived day-long server outages, Twitter survived the
	failwhale, but I don't think either could have survived a janky interface.
	So, no pressure or anything.