Lab 4

MIT Interactive Visualization & Society course

What is npm?

A package manager for JS

A package manager is a tool that automates the process of installing, updating, configuring, and removing software. If you’ve written Python, you have likely used `pip`, its own package manager. You may have used package managers to install software in your operating system, such as`apt-get` or `brew`. They are command-line tools that allow you to install software from a central repository by simply referencing its name (and optionally a specific version). NPM stands for "Node Package Manager". It was originally created for Node.js, a JavaScript runtime that allows you to run JavaScript on the server. These days, NPM is used for much more than just Node.js, and is the most popular package manager for JavaScript. Most front-end developers use NPM to manage build tools and dependencies for their projects. Most NPM packages correspond to GitHub repos. When you install a package, NPM will download the package from the _NPM registry_ and install it in a directory called `node_modules`.

Anyone can publish a package!

# npm 101 - `package.json` A file containing metadata about a project - `node_modules/` A directory containing all the dependencies of a project - `npm install` Installs all dependencies listed in `package.json` - `npm install PACKAGE_NAME` Installs a package and adds it to `package.json` - `npm create PACKAGE_NAME` Create a new prpject, using another package as a template - `npm run SCRIPT_NAME` Runs a script defined in `package.json` (e.g. `build`, `dev`, etc.)

Why use a JS Framework?

  1. Developer Experience
    • Declarative syntax
    • Reactivity
    • Modularity
    • Convenience
There are many, *many* JS frameworks out there. The only reason to use a JS framework is development convenience. In theory, you could write everything in vanilla JS (as JS-without-frameworks is often called), but it would be a lot more work. However, development convenience can indirectly benefit end-users as well, because if you can develop faster, you can iterate faster, and deliver more features and bugfixes in the same amount of time. But how do JS frameworks provide development convenience? On a high level, in two ways: - **Declarativeness and reactivity**: Remember how we discussed that HTML and CSS are declarative and reactive, but JS is not? In CSS you declare what you want to happen, and it autoamtically takes care of the steps, whereas in JS, you have to specify every step. In CSS when a value changes (e.g. a CSS variable), everything that depends on it is automatically updated. JS frameworks expose a syntax that makes JS *declarative* and *reactive* as well. - **Modularity**: JS frameworks give us easier ways to break up the code of a large website or app into small, independent pieces that can be managed separately. This is achieved in many ways, such as components, data binding, etc.

Data binding

What is a build process?

index.md


			---
			title: Build Tools
			---

			# Build Process

			A build process reads *input files*
			and coverts them into *output files*.

index.html


			<!DOCTYPE html>
			<html>
			<head>
				<title>Build Tools</title>
			</head>
			<body>
				<h1>Build Process</h1>
				<p>A build process reads <em>input files</em>
				and coverts them into <em>output files</em>.
			</body>
			</html>
A build process is basically a compilation step that allows us to write code in a language other than those that the browser supports natively. It can do dramatic things like convert (*transpile*) a language that the browser doesn’t understand at all (e.g. TypeScript or CoffeeScript) to JavaScript, or lighter things like convert a language feature that the browser doesn’t understand yet (e.g. CSS nesting) to a version that it does understand. By convention, we run a website’s build process by running `npm run build`, which looks for a `build` key in the `scripts` part of `package.json`.

Modern web apps

Also modern web apps

HTML: `<h1>` `<ul>` `<p>`

Component-driven development

Traditional Architecture

Component-based Architecture

Component-based Architecture

Components give us a *different* separation of concerns than what we have seen so far (and arguably more pragmatic and scalable).

Components Inputs and outputs 


			<ColorPicker format="oklch"
				   allowAlpha
				   bind:color={ themeColor }
				   on:close={ saveThemeColor }>
				Theme color
			</ColorPicker>
Theme color
Components are to UI what functions are to code. They have inputs, called *props*. Props look like HTML attributes, but can actually contain JS objects, arrays, etc. There is also another input: their contents. They are used to provide data and to parameterize the component. Often the only output of components is the UI they render. However, they can also have outputs, passed via *events*.

Svelte (and SvelteKit)

Why Svelte?

Anatomy of a Svelte component


			<script>
				// logic goes here
			</script>

			<!-- HTML (zero or more elements) goes here -->

			<style>
				/* Scoped CSS goes here */
			</style>

Example Svelte component

Definition


				<script>
					// Define a prop "value"
					export let value = 50;
				</script>

				<input type=range bind:value={value}>
				<span>{ value }</span>

				<style>
					span {
						display: inline-block;
						padding: 0 .4em;
						border-radius: .3em;
						background: oklch(95% 2% 200);
					}
				</style>

Usage


				<script>
					import Slider from './Slider.svelte';

					let myValue = 3;
				</script>

				<Slider value={myValue}></Slider>
[Live demo](https://svelte.dev/repl/3ebeaec8826943e3a9deee0a1f0aedd2?version=4.2.12)

Time to get our hands dirty!

Today’s menu:

👩🏽‍💻🧑🏼‍💻👨🏻‍💻