## Table of Contents

## Console.log를 기록하는 wasm 만들어보기

`Cargo.toml`

```toml
[package]
name = "consolelog"
version = "0.1.0"
edition = "2021"

[lib]
crate-type = ["cdylib", "rlib"]

[dependencies]
wasm-bindgen = "0.2.74"
web-sys = { version = "0.3.56", features = ['console'] }
```

`lib.rs`

```rust
use wasm_bindgen::prelude::*;

#[wasm_bindgen]
extern {
    // js_namespace는 console을 할당했다.
    // 즉 log만 쓰면 console.log가 된다.
    #[wasm_bindgen(js_namespace = console)]
    fn log(s: &str);

    // 여기는 console.log
    #[wasm_bindgen(js_namespace=console, js_name=log)]
    fn log_u32(a: u32);

    // 여기도 console.log
    #[wasm_bindgen(js_namespace=console, js_name=log)]
    fn log_strings(a: &str, b: &str);
}

macro_rules! console_log {
    // log 함수랑 연결된다.
    ($($t:tt)*) => (log(&format_args!($($t)*).to_string()))
}

// rust extern으로 하는 방법
fn rust() {
    log("Hello yceffort!");
    log_u32(42);
    log_strings("Hello", "yceffort")
}

// macro
fn using_macro() {
    console_log!("Hello {}!", "yceffort");
    console_log!("Hello yceffort");
}

// websys library
fn using_web_sys() {
    use web_sys::console;

    console::log_1(&"Hello using web-sys".into());

    let js: JsValue = 4.into();

    console::log_2(&"Logging values are".into(), &js);
}

#[wasm_bindgen(start)]
pub fn run() {
    rust();
    using_macro();
    using_web_sys();
}
```

![console.log](./images/consolelog.png)

## 번들러 없이 직접 import 해서 사용하기

`Cargo.toml`

```toml
[package]
name = "without-bundler"
version = "0.1.0"
edition = "2021"

[lib]
crate-type = ["cdylib"]

[dependencies]
wasm-bindgen = "0.2.79"

[dependencies.web-sys]
version = "0.3.4"
features = [
  'Document',
  'Element',
  'HtmlElement',
  'Node',
  'Window',
]
```

`lib.rs`

```rust
use wasm_bindgen::prelude::*;

#[wasm_bindgen(start)]
pub fn main() {
    let window = web_sys::window().expect("there is no window in global");
    let document = window.document().expect("there is no document in window");
    let body = document.body().expect("there is no body in a document");

    let p_element = document.create_element("p").expect("fail to create P element");

    p_element.set_inner_html("Hello from rust");

    body.append_child(&p_element).expect("fail to append element");
}

#[wasm_bindgen]
pub fn add(a: u32, b: u32) -> u32 {
    a + b
}
```

![without-bundler1](./images/without-bundler1.png)

![without-bundler2](./images/without-bundler2.png)

## js 코드를 import 해서 rust에서 실행하기

가령 자바스크립트에 아래와 같은 코드가 있다고 가정해보자.

`defined-in-js.js`

```javascript
export function name() {
  return 'Rust'
}

export class MyClass {
  constructor() {
    this._number = 42
  }

  get number() {
    return this._number
  }

  set number(n) {
    return (this._number = n)
  }

  toString() {
    return `My number is: ${this.number}`
  }
}
```

위 코드를 rust에서 실행하기 위해서는 먼저 해당 js코드를 추상화하는 작업이 필요하다. 위 코드에 대한 추상화는 아래와 같이 작업하면 된다.

```rust
use wasm_bindgen::prelude::*;

#[wasm_bindgen(module = "/defined-in-js.js")]
extern "C" {
    // name 함수 정의
    fn name() -> String;

    // 클래스 정의
    type MyClass;

    // 클래스에 new keyword를 constructor로 정의
    #[wasm_bindgen(constructor)]
    fn new() -> MyClass;

    // getter
    #[wasm_bindgen(method, getter)]
    fn number(this: &MyClass) -> u32;

    // setter
    #[wasm_bindgen(method, setter)]
    fn set_number(this: &MyClass, number: u32) -> MyClass;

    // toString
    #[wasm_bindgen(method)]
    fn toString(this: &MyClass) -> String;
}

// console.log를 정의한다.
#[wasm_bindgen]
extern "C" {
    #[wasm_bindgen(js_namespace = console)]
    fn log(s: &str);
}

#[wasm_bindgen(start)]
pub fn run() {
    log(&format!("Hello from {}!", name())); // should output "Hello from Rust!"

    // 클래스를 선언한다
    let x = MyClass::new();
    // 테스트 코드!
    assert_eq!(x.number(), 42);
    // setter에 숫자 주입
    x.set_number(10);
    // toString
    log(&x.toString());
}
```

`run()` 함수 내부에 있는 것들이 순차적으로 실행될 것이다.

```
Hello from Rust!
My number is: 10
```


Rust로 web assembly 만들어보기 (3) - Rust로 다양한 Web Assembly 만들어보기

## Table of Contents

## 개발 환경

1. [Install Rust](https://www.rust-lang.org/install.html)로 먼저 Rust를 설치한다.
2. 그리고 wasm을 만들기 위해, [wasm-pack](https://github.com/rustwasm/wasm-pack)을 설치한다.

```shell
cargo install wasm-pack
```

## 패키지 만들기

```shell
cargo new --lib hello-wasm
```

이제 아래와 같은 파일이 생성되었을 것이다.

```rust
#[cfg(test)]
mod tests {
    #[test]
    fn it_works() {
        let result = 2 + 2;
        assert_eq!(result, 4);
    }
}
```

일반적으로 단위테스트는 src 디렉토리의 각 파일에 테스트 할 코드와 함께 작성한다. 여기서 사용되는 규칙은 각 파일에 `mod tests`라는 모듈을 `#[cfg(test)]`와 함께 선언하고, 그안에 테스트할 코드를 작성하면 된다. `#[cfg(test)]` 로 선언된 모듈은 `cargo test`를 할 때만 실행되고, build시에는 컴파일 되지 않는다. 따라서 빌드 시 시간과 공간을 절약할 수 있다.

> cfg는 configuration 이라는 뜻이다.

`[#test]`는 이 함수가 테스트 함수임을 가리키는 역할을 한다.

## Rust 작성하기

먼저 `Cargo.toml`에 `wasm_bindgen`을 의존성 목록에 추가해주자.

```toml
[package]
name = "hello-wasm"
version = "0.1.0"
authors = ["yceffort <yceffort@gmail.com>"]
description = "A sample project with wasm-pack"
license = "MIT/Apache-2.0"
repository = "https://github.com/yceffort/rust-playground/tree/main/wasm/tutorial/hello-wasm"

[lib]
crate-type = ["cdylib"]

[dependencies]
wasm-bindgen = "0.2"
```

```rust
// import * from wasm_bindgen/prelude와 같다.
use wasm_bindgen::prelude::*;

#[wasm_bindgen]
extern {
    pub fn alert(s: &str);
}

#[wasm_bindgen]
pub fn greet(name: &str) {
    alert(&format!("Hello, {}!", name));
}
```

[wasm-bindgen](https://github.com/rustwasm/wasm-bindgen)은 자바스크립트와 러스트 사이에 일종의 다리 역할을 한다고 보면 된다. 자바스크립트에서 rust api를 호출하거나, 반대로 rust가 js에서 발생한 예외처리를 하는 등의 처리를 할 수 있도록 해준다.

`#[XXX]`는 일종의 wrapper를 생성하는 속성 값인데, 이것이 무슨일을 하는지는 이후에 알아보자.

`extern` 키워드는, 이 것이 rust 외부에 정의된 함수라는 것을 알린다. 외부에 `alert`라는 함수가 있으며, 이는 문자열 타입의 `s` 를 받는 다는 것을 의미한다. 눈치 챘을 수도 있지만, 이는 `window.alert`를 의미한다.

즉, 자바스크립트에 무언가 함수를 호출 하고 싶다면 `extern` 키워드와 함께 추가하면 된다.

```rust
#[wasm_bindgen]
pub fn greet(name: &str) {
    alert(&format!("Hello, {}!", name));
}
```

이번에는 `extern` 키워드 대신 다른 것이 나왔다. 이번에는 `fn` 구문을 wrapping 하고 있다. 이는 rust 함수를 자바스크립트에 의해 호출될 수 있도록 처리한다는 것을 의미한다. 즉 `extern`과는 반대가 되는 기능이다.

함수를 보면 알겠지만, `greet()`는 문자열 타입 `name`을 받고 `hello {name}`이라는 문자열을 만들고 이를 alert에 넘겨주고 있다.

이제 이 코드를 빌드해보자

## 빌드하기

```shell
wasm-pack build --scope yceffort
```

마지막 scope는 npm 계정의 아이디를 넣어주면된다.

이 빌드는 다음과 같은 과정을 수행한다.

1. Rust 코드를 WebAssembly로 컴파일
2. WebAssembly위에서 `wasm-bindgen`을 실행하여, WebAssembly가 npm이 이해할 수 있는 모듈로 감싸는 자바스크립트 파일을 생성
3. `pkg` 폴더를 만들고, 자바스크립트 파일과 WebAssembly 코드를 그 안으로 옮긴다.
4. `Cargo.toml`과 동등한 `package.json`을 생성
5. `README.md`가 있다면 패키지로 복사

빌드가 완료되었다면, `pkg` 폴더가 생성되어 있는 것을 볼 수 있다.

`hello_wasm.js`

```javascript
import * as wasm from './hello_wasm_bg.wasm'
export * from './hello_wasm_bg.js'
```

`package.json`

```json
{
  "name": "@yceffort/hello-wasm",
  "collaborators": ["yceffort <yceffort@gmail.com>"],
  "description": "A sample project with wasm-pack",
  "version": "0.1.0",
  "license": "MIT/Apache-2.0",
  "repository": {
    "type": "git",
    "url": "https://github.com/yceffort/rust-playground.git"
  },
  "files": [
    "hello_wasm_bg.wasm",
    "hello_wasm.js",
    "hello_wasm_bg.js",
    "hello_wasm.d.ts"
  ],
  "module": "hello_wasm.js",
  "types": "hello_wasm.d.ts",
  "sideEffects": false
}
```

## 빌드한 패키지 사용해보기

이 npm package를 사용할 수 있도록 한번 설정해보자.

```json
{
  "name": "hello-wasm-npm",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "serve": "webpack-dev-server"
  },
  "dependencies": {
    "@yceffort/hello-wasm": "../hello-wasm/pkg"
  },
  "devDependencies": {
    "webpack": "^4.25.1",
    "webpack-cli": "^3.1.2",
    "webpack-dev-server": "^3.1.10"
  },
  "author": "",
  "license": "ISC"
}
```

```javascript
const path = require('path')
module.exports = {
  entry: './index.js',
  output: {
    path: path.resolve(__dirname, 'dist'),
    filename: 'index.js',
  },
  mode: 'development',
}
```

```html
<!DOCTYPE html>
<html>
  <head>
    <meta charset="utf-8" />
    <title>hello-wasm example</title>
  </head>
  <body>
    <script src="./index.js"></script>
  </body>
</html>
```

```javascript
const js = import('./node_modules/@yceffort/hello-wasm/hello_wasm.js')
js.then((js) => {
  js.greet("yceffort's first WebAssembly")
})
```

![first-wasm](./images/first-wasm.png)

## `wasm-bindgen`의 대략적인 원리

`wasm-bindgen`의 가장 중요한 개념은, wasm module이 ES Module의 한 가지 종류로 인식하고 연동한다는 것이다. `pkg`에 있는 `d.ts`를 보면 (타입스크립트 시그니쳐까지..!) 다음과 같이 선언되어 있다.

```typescript
/* tslint:disable */
/* eslint-disable */
/**
 * @param {string} name
 */
export function greet(name: string): void
```

WebAssembly는 이러한 처리가 불가능하므로, 이 것을 수행해주는 것이 `wasm-bindgen`이다. 이 중 자바스크립트 파일은 러스트를 호출할때 사용되는 인터페이스 역할을 하고, `*_bg.wasm` 파일이 실제로 방금 컴파일한 것과 구현체를 가지고 있다.

`hello_wasm_bg.js` 파일은 다음과 같이 구현되어 있다.

```javascript
import * as wasm from './hello_wasm_bg.wasm'

// ...

function getStringFromWasm0(ptr, len) {
  return cachedTextDecoder.decode(getUint8Memory0().subarray(ptr, ptr + len))
}

/**
 * @param {string} name
 */
export function greet(name) {
  var ptr0 = passStringToWasm0(
    name,
    wasm.__wbindgen_malloc,
    wasm.__wbindgen_realloc,
  )
  var len0 = WASM_VECTOR_LEN
  wasm.greet(ptr0, len0)
}

export function __wbg_alert_a5a2f68cc09adc6e(arg0, arg1) {
  alert(getStringFromWasm0(arg0, arg1))
}
```

`wasm.greet(ptr0, len0);`를 보면, 이 함수는 문자열이 아닌 포인터와 length를 인수로 받고 있는 것을 알 수 있다.

조금 더 깊이 들어가서, WebAssembly의 `greet`함수가 러스트 컴파일러에 의해 컴파일되는 시점을 보면 이런식으로 코드가 작성되어 있다.

```rust
pub fn greet(name: &str) {
    alert(&format!("Hello, {}!", name));
}

#[export_name = "greet"]
pub extern fn __wasm_bindgen_generated_greet(arg0_ptr: *mut u8, arg0_len: usize) {
    let arg0 = unsafe { ::std::slice::from_raw_parts(arg0_ptr as *const u8, arg0_len) }
    let arg0 = unsafe { ::std::str::from_utf8_unchecked(arg0) };
    greet(arg0);
}
```

원래 작성한 코드와 함께, 이상한 이름의 함수와 `#[export_name = "greet"]`가 붙어 있다. 이는 JS가 던진 pointer와 length를 받는 부분이다. 이 두개 인자를 받아서, `greet` 함수에 전달한다.

정리하자면, `#[wasm_bindgen]`는 두개의 wrapper를 생성한다.

- JS 타입을 받아서 wasm으로 변환 (자바스크립트)
- wasm 타입을 rust 타입으로 변환 (러스트)

즉, 앞서 언급했던 것 처럼, `wasm-bindgen`는 자바스크립트 - WASM - 러스트 사이에 다리 역할을 하고 있으며, 이를 위해 많은 일들이 뒷단에서 일어나고 있음을 알 수 있다.


Rust로 web assembly 만들어보기 (2) - Rust로 간단한 Web Assembly 만들기

## Table of Contents

## Web Assembly란 무엇인가?

웹 어셈블리는 최신 웹 브라우저에서 자바스크립트 코드 외에 실행할 수 있는 새로운 유형의 코드를 의미한다. 웹에서 실행될 수 있는 코드는 자바스크립트 밖에 없지만, 웹 어셈블리를 활용하면 자바스크립트 외의 다른 언어, 특히 처리가 빠른 저수준 컴파일언어 (c, c++, rust 등) 를 사용할 수 있게 도와준다. 이를 활용하면 자바스크립트와 서로 상호 보완하여 동작이 가능해지고, 나아가 자바스크립트 수준에서 처리하기 어려운 일들도 처리할 수 있게 된다.

웹은 모바일, PC 등 다양한 플랫폼에서 동작하지만, 기본적으로 다른 언어에 비해 성능이 느린 자바스크립트 밖에 사용할 수 없다는 한계를 가지고 있었다. 그러나 웹 어셈블리를 사용하면 이전까지는 웹에서 돌릴 수 없던 다양한 클라이언트 앱을 네이티브에 가까운 성능과 속도로 실행할 수 있게 된다.

### Web Assembly가 달성하고자 하는 목표

> [https://www.w3.org/community/webassembly/](https://www.w3.org/community/webassembly/)

- 빠르고, 효과적이고, 이식성이 좋을 것
- 읽기 쉽고 디버깅이 가능한 구조일 것
- 안전할 것
- 웹 환경을 망가뜨리지 않을 것

### Web Assembly의 동작 구조

웹 플랫폼은 크게 두 가지로 나눠서 생각할 수 있다.

- 자바스크립트와 같은, 앱을 구성하는 코드를 실행하는 가상머신
- 웹브라우저나 하드웨어 기능을 호출해서 애플리케이션이 무언가를 할 수 있도록 만드는 Web API (DOM, CSSOM, WebGL....)

첫 번째로 언급한 이 가상머신에서는, 오직 자바스크립트만 실행이 가능했다. 태초에 웹이 탄생했을 무렵, 자바스크립트의 비중은 거의 없었다. 그러나 기기의 성능 발전, 웹 표준화, ajax 등으로 인해 자바스크립트가 웹 애플리케이션에서 차지하는 비중은 점차 늘기 시작했다. 그리고 사람들은 점차 더 많은 것들을 웹에서 구현하길 원했다. 3D 게임, 가상현실, 영상처리, 이미지 편집 등 네이티브 성능을 필요로 하는 작업은 자바스크립트라는 한계에 부딪혔다. 오늘날의 웹 애플리케이션은 사이즈에 따라 다르지만, 아주 큰 자바스크립트를 받고 컴파일하고 파싱하는데에만 감당하기 어려운 비용을 처리하는 경우도 있다. 특히 모바일과 같은 경우에는 이러한 성능 병목 현상이 두드러진다.

WebAssembly는 자바스크립트와 다른 언어지만, 자바스크립트를 대체하기 위해 만들어진 것은 아니다. Web Assembly와 자바스크립트는 서로 부족한 점을 보완하여, 웹 개발자가 다양한 작업을 처리할 수 있게 끔 도와준다.

- 자바스크립트는 웹 애플리케이션을 작성하기에 좋은 고수준의 언어다. 동적타입 언어로서 컴파일 과정이 필요없고, 다양한 프레임워크, 라이브러리, 도구를 제공하는 아주 거대한 생태계를 가지고 있다.
- WebAssembly는 어셈블리와 같이 컴팩트한 바이너리 포맷을 가지고 있는 저수준 언어로, 네이티브에 가까운 성능을 제공하고, C++, Rust와 같은 저수준 메모리 모델을 가진 언어로 작성된 프로그램을 웹에서 실행할 수 있게 해준다.

필요하다면 다른 형식의 이 두 코드가 서로를 호출할 수 있다.

### Web Assembly의 핵심 컨셉

- 모듈: 실행가능한 컴퓨터 코드로, 브라우저에서 컴파일된 바이너리를 의미한다. 모듈은 stateless 이고, 윈도우와 워커 간에 `postMessage()`를 통해 공유가 가능하다.
- 메모리: Web Assembly의 저수준 메모리 접근 명령어에 의해 읽고 쓰여지는 바이트를 의미하며, 사이즈 조절이 가능한 Array Buffer다.
- 테이블: raw 바이트로 메모리에 저장될 수 없는 레퍼런스를 의미한다.
- 인스턴스: 모듈, 그리고 그 모듈이 사용하는 모든 상태를 의미한다. 여기서 말하는 상태란 메모리, 테이블, import 된 값의 집합 등이 있다.

### 사용 가능한 언어

- C/C++
- Rust
- [AssemblyScript](https://assemblyscript.org/introduction.html) (타입스크립트와 비슷)
- C#
- F#
- Go
- Kotlin
- Swift
- D
- Pascal
- Zig
- Grain

> [https://webassembly.org/getting-started/developers-guide/](https://webassembly.org/getting-started/developers-guide/)

## 왜 러스트인가?

### .wasm 사이즈가 작다

`.wasm`은 네트워크를 통해 받아야하는 바이너리 파일로, 이 코드 크기는 성능에 있어 매우 중요하다. 러스트는 가비지 컬렉터와 같은 추가적인 bloat이 포함되어 있지 않아 작은 크기의 `.wasm`을 사용할 수 있다. 즉, 실제로 사용하는 함수와 기능에 대해서만 값을 치루면 된다.

예를 들어 Go와 같이 상대적으로 작은 런타임 언어도, hello world 수준의 프로그램을 컴파일 하면 2MB가 넘는 바이너리 트리를 갖는다. 반면 rust는 1.46kb에 불과하다. 또한 `.wasm`으로 컴파일 시에 네이티브에 애플리케이션에 비례하는 실행 속도를 누릴 수 있으므로, 속도와 성능 모두를 잡을 수 있게 된다.

### 자바스크립트와 비슷한 생태계

[이전에도 언급했던 것](/2022/02/rust-for-javascript-developer-chapter1) 처럼 자바스크립트와 러스트는 비교적 비슷한 생태계를 가지고 있다.

### Web Assembly를 위한 다양한 도구

WEb Assembly로서의 rust를 사용하기 용이하게 하기 위한 다양한 도구들이 존재한다.

- [wasm-pack](https://github.com/rustwasm/wasm-pack)
- [wasm-opt](https://github.com/MrRefactoring/wasm-opt)
- [wasm2js](https://github.com/thlorenz/wasm2js)
- [twiggy](https://github.com/rustwasm/twiggy)

특히 이 중에 첫 번째 라이브러리는 오직 rust 를 위해서 만들어져있는데, 이도구가 정말 강력하여 다른 언어에서는 여러 프로세스나 도구를 거쳐야하는 번거로움을 한번에 해결 할 수 있다.


Rust로 web assembly 만들어보기 (1) - Web Assembly란 무엇인가?

리액트 서버 컴포넌트의 동작 방식

## Table of Contents

## meme?

먼저 인터넷에 떠돌고 있는(?) HTML 프로그래밍 언어 관련 짤을 보고 가자.

![meme1](https://i.redd.it/m41loixjno811.jpg)

![meme2](https://i.kym-cdn.com/photos/images/original/001/382/372/e8b.jpg)

![meme3](https://pbs.twimg.com/media/EPgQXItUcAAQE9V.jpg)

## Introduction

> HTML은 프로그래밍 언어가 아닙니다.

라는 말은 프론트엔드 개발을 시작하면서 지겹게도 들어보았다. 정말로 프로그래밍 언어가 아니라는 것을 강조하고 싶었던 것인지, 자바스크립트 개발자로서 HTML은 매우 쉬운 언어이기 때문에 차별성을 두고 싶었던건지, 어쨌는 건지 모르겠지만 흔히들 하는 말은 '로직이 없다' 라든가 [튜링 완전(turing completeness)](https://ko.wikipedia.org/wiki/%ED%8A%9C%EB%A7%81_%EC%99%84%EC%A0%84) 이 없다 라든가 등의 논리를 들며 HTML은 프로그래밍 언어가 아니고 마크업 언어라고 주장한다.

> 튜링 완전(turing completeness)이란 어떤 프로그래밍 언어나 추상 기계가 튜링 기계와 동일한 계산 능력을 가진다는 의미이다. 이것은 튜링 기계로 풀 수 있는 문제, 즉 계산적인 문제를 그 프로그래밍 언어나 추상 기계로 풀 수 있다는 의미이다.

그렇다면 정말 프로그래밍 언어로서 HTML은 부족한 점이 있는 것일까? HTML은 정말 프로그래밍 언어가 아닌 것일까? 흔히들 HTML이 프로그래밍 언어로서 무언가 결함이 있거나 부정확하다고 주장할 때 언급되는 논리에 대해서 하나씩 살펴보자.

## HTML이 프로그래밍 언어가 아니라고 하는 주장들

대표적인 주장들을 살펴보자.

### HTML은 마크업 언어지, 프로그래밍 언어가 아니예요.

이 문장 자체는 맞는 것 같아 보이지만 틀렸다고 생각한다. 마크업 언어도 프로그래밍 언어가 될 수 있다. 모든 마크업 언어가 프로그래밍 언어인것은 아니지만, 그럴 수도 있다. 두 개의 벤다이어그램을 그린다면, 약간은 교차하는 모습이 나올 것이다.

변수, 제어, 루프 등을 가지고 있는 마크업 언어 또한 프로그래밍 언어가 될 수 있다. 이는 상호 배타적인 개념이 아니다. 마찬가지로 수학 수식을 그릴 때 사용하는 `Tex` 와 `LaTex` 도 프로그래밍 언어로 볼 수 있는 마크업 언어다. 이 두언어를 가지고 개발을 하는 것은 일반적인 상황은 아니지만, 온라인에서 이러한 예시를 찾아볼 수는 있다.

- https://www.ctan.org/tex-archive/macros/generic/basix
- https://sdh33b.blogspot.com/2008/07/icfp-contest-2008.html

따라서 마크업 언어라고 해서 프로그래밍 언어가 아니라고 하는 것은 잘못되었다. 요점은 두개의 개념이 별개가 아니라는 것이다. 마크업 언어는 프로그래밍 언어일 수 있다. 따라서 HTML이 마크업 언어이기 때문에 프로그래밍 언어가 아니라고 말하는 것은 애초에 전재 조건이 잘못되었다고 볼 수 있다.

### HTML은 로직을 가질 수 없어서 프로그래밍 언어가 아니예요.

로직이란 무엇일까? 튜링 완전과 마찬가지로, 이 주장을 다루기 전에 로직이란 무엇인지 확실히 정의내릴 필요가 있다.

보통 프로그래밍 언어에서의 로직은, 변수나 조건, 루프 등이 있어 사용할 수 있는 것을 의미한다. HTML은 그런데 이러한 것을 사용할 수 없기 때문에 프로그래밍 언어가 아니라고 생각할 수 있다. 하지만 HTML 속성 중에는 변수가 있으며, 변수와 함께 사용할 수 있는 제어구조가 있다. 내부 논리를 제어하는데 자바스크립트나 CSS 가 필요없는 HTML element 가 있다. 여기서 말하는 것은 과거 표준이었던 `<link>` `<noscript>`가 아니다. 사용자의 입력에 따라서 element의 현재 상태와 변수에 값에 따라 조건부 작업을 수행하는 element를 말하는 것이다.

아래 예시를 살펴보자.

```html
<dialog id="dialog1" open>
  <h2>This is an HTML <code>&lt;dialog&gt;</code></h2>
  <p>Dialog</p>
  <p>CSS나 자바스크립트 없이도 닫을 수 있습니다?!</p>
  <form method="dialog" action="#dialog1">
    <button>닫기</button>
  </form>
</dialog>

<details>
  <summary>화살표를 눌러보세요</summary>
  <div>
    <p>띠요옹</p>
    <p>CSS나 자바스크립트 없이도 여닫기를 할 수 있다?!</p>
  </div>
</details>
```

https://6710t.csb.app/

- https://developer.mozilla.org/ko/docs/Web/HTML/Element/dialog
- https://developer.mozilla.org/ko/docs/Web/HTML/Element/summary

따라서 HTML에는 로직이 없어서 프로그래밍 언어가 아니라고 말하는 것도 오해의 소지가 있다. HTML이 사용자의 입력 (클릭)에 따른 결정을 내릴 수 있다. 물론 HTML이 로직을 가지고는 있지만, 데이터를 조작하도록 설계된 다른 언어의 로직과는 본질적으로 다르긴하다. 어쨌거나, HTML이 프로그래밍 언어가 아니라고 말하기 위해서는 더 논리적인 주장이 필요하다.

### 튜링 완전함이 없어서 프로그래밍 언어가 아닙니다.

튜링 완전성이 무엇인지에 대한 논의는 여기저기서 많이 다뤄지고 있기 때문에 굳이 언급하지는 않겠다.

> In the simplest terms, for a language or machine to be Turing complete, it means that it is capable of doing what a Turing machine could do: perform any calculation, a.k.a. universal computation. After all, programming was invented to do math although we do a lot more with it now, of course!

> 언어나 머신이 튜링 완전성을 가지기 위해서는, 튜링 기계가 할 수 있는 것을 똑같이 할 수 있어야 한다. 모든 연산, 즉 보편적인 연산을 수행할 수 있어야 한다. 프로그래밍은 비록 우리가 수학으로 할 수 있는 것 보다 더 많은 것을 하고 있지만, 본질적으로는 수학을 하기 위해서 발명되었다.

> https://notlaura.com/is-css-turing-complete/

대부분의 현대 프로그래밍 언어들이 튜링 완전하기 때문에 사람들은 이를 프로그래밍 언어의 정의로 사용한다. 하지만 사실 튜링 완전성의 정의는 그것이 아니다. 앞서 위키피디아에서 본것 처럼, 튜링 기계를 시뮬레이션 할 수 있는지 여부를 나타내는 것이다. 튜링 완전성은 프로그래밍 언어를 분류하는데 사용할 수 있지만, 튜링 완전성을 가지고 프로그래밍 언어의 정의를 내리는데 사용하기엔 조금 무리가 있다. 예를 들어 마인크래프트나 매직더 게더링도 튜링 완전성을 가지고 있지만, 이를 프로그래밍 언어라고 생각하는 사람은 없다.

튜링 완전성은 아주 과거 일부 사람들이 컴파일 언어와 인터프리터 언어의 차이를 '좋은 언어'의 차이로 나눴던 것과 마찬가지 방식으로 사용되고 있는 것 같다. 백엔드 개발자가, 프론트엔드 개발자를 '가짜 프로그래밍을 하는 사람'으로 평가 절하했던 것과 마찬가지로.

프로그래밍의 정의는 시간에 따라 달라진다. 천공 카드에 어셈블리 코딩을 입력하는 것이 진짜 프로그래밍이라고 주장하는 사람들도 있을 것이다. 보편적이거나, 모세의 그것 처럼 돌로 쓰여진 것은 아무것도 없다.

튜링 완전성은 공정한 기준이라고 볼수도 있지만, 편향되고 주관적인 기준이라고 보는 것이 맞다. 튜링 완전 기계를 생성할 수 있는 언어는 프로그래밍 언어로 판단되는 반면, [유한 상태 기계](https://ko.wikipedia.org/wiki/%EC%9C%A0%ED%95%9C_%EC%83%81%ED%83%9C_%EA%B8%B0%EA%B3%84)를 생성하는 언어는 그렇지 않는 것으로 보는 이유는 무엇인가? 이는 완전히 주관적이라고 생각한다.

마찬가지로, HTML은 튜링 완전하지 않다라고 하는 사람들도 정작 튜링 완전성이 무엇인지 모르거나 이해하지 못하는 것 또한 사실이다. 튜링 완전성은 품질 보증서가 아니다. 프로그래밍 언어를 정의하는 것이 아니라 분류하는 방법이다. 프로그래밍언어는 컴파일/인터프리터일수도, 명령형/선언형 일수도, 절차적이거나/객체지향적 일수도있다. 그리고 마찬가지로 튜링완전할 수도 그렇지 않을 수도 있다.

## 그래서 HTML이 프로그래밍 언어라구요? 아뇨, 더 중요한 것은..

그래서, 프로그래밍 언어가 아니라고 하는 주장을 반박하면 HTML이 프로그래밍 언어가 되는건가? 그런 건 아니다. HTML 표준이 상상 이상으로 발전하거나, 프로그래밍 언어의 정의가 바뀌지 않는 이상 이 논쟁은 아마두 계속 될 것이다.

그러나 중요한 것은 개발자로서 이러한 질문을 받아드릴 경우 심각한 논쟁을 야기하는 것이 아니라, 이러한 논쟁으로부터 개발 생태계를 분리시키는 것이다. 이러한 논쟁은 의도를 숨긴채 쓸데없는 논란을 불러 오기 때문에 매우 경계해야 한다.

> They say you’re not a real programming language like the others, that you’re just markup, and technically speaking, I suppose that’s right. Technically speaking, JavaScript and PHP are scripting languages. I remember when it wasn’t cool to know JavaScript, when it wasn’t a “real” language too. Sometimes, I feel like these distinctions are meaningless, like we built a vocabulary to hold you (and by extension, ourselves as developers) back. You, as a markup language, have your own unique value and strengths.

> 사람들은 여러분이 다른 언어처럼 진짜 프로그래밍 언어라고 말합니다. 이는 단지 마크업이고, 엄밀히 말하면 저는 이것이 옳다고 생각합니다. 더 기술적으로 이야기 하자면, 자바스크립트와 PHP는 스크립트 언어 입니다. 자바스크립트를 아는 것이 자랑이 아니었을 때, 자바스크립트가 진짜 언어 취급을 받지 않았을 때를 기억합니다. 때때로 이런 구별과 논의가 무의미하다고 생각합니다. 마치 이러한 논쟁이 마크업 개발자를 자바스크립트 개발자 뒤로 붙들기 위한 어휘 처럼 느껴집니다. 마크업 언어로서, 여러분 (마크업 개발자 분들)들은 자신만의 고유한 가치와 장점을 가지고 있습니다.

https://css-tricks.com/a-love-letter-to-html-css/

## 결론

HTML 은 프로그래밍 언어인가 아닌가는 별로 중요한 논의도 아니고, 누군가 결정을 내려줘야할 문제도 아니다. 과거 프론트엔드 개발자들이 백엔드 개발자들에게, 나아가 개발자 커뮤니티에서 알게 모르게 무시 당했던 것과 비슷한 느낌이다. HTML과 프로그래밍 언어 이 논쟁은 의미도 없고 아무런 가치도 가지고 있지 않다. 개발을 하는데 개발자가 컴퓨터 공학과 인지, 동양인지 전혀 상관없는 것 처럼 개발자는 개발자 일 뿐이고, HTML은 HTML 일 뿐이다. 웹 생태계, 나아가 현재의 소프트웨어 생태계를 보았을 때 HTML이 차지하는 비중이 결코 작지 않다. HTML은 다른 것들과 마찬가지로 방대한 문서와 광범위한 문법을 가지고 있고, 간단하게 배울 수 있는 것도 아니며, 그 복잡성으로 인해 숙달하는데 있어 몇년이 걸린다. 프로그래밍 언어든 아니든 중요한 것은 HTML이 있다는 것, 그리고 좋은 품질의 웹 애플리케이션을 만들기 위해 반드시 사용해야 한다는 것, 그 것 뿐이다.

## 살펴보기

- https://notlaura.com/is-css-turing-complete/
- https://css-tricks.com/a-love-letter-to-html-css/
- https://css-tricks.com/html-is-not-a-programming-language/


Html 1

Rust로 web assembly 만들어보기 (3) - Rust로 다양한 Web Assembly 만들어보기

Rust로 web assembly 만들어보기 (2) - Rust로 간단한 Web Assembly 만들기

Rust로 web assembly 만들어보기 (1) - Web Assembly란 무엇인가?

리액트 서버 컴포넌트의 동작 방식

HTML은 프로그래밍 언어인가? 라는 논쟁보다 중요한 것