Каковы компромиссы между ReasonML (https://reasonml.github.io/) и TypeScript (https://www.typescriptlang.org/)?
ReasonML vs TypeScript
Ответ 1
В настоящее время существует множество языков, ориентированных на JavaScript. Выбор одного из них зависит от ваших потребностей и идиом, с которыми вам удобно.
JavaScript имеет систему динамического типа. Некоторые разработчики предпочитают статическую.
-
TypeScript или Haxe решает это с новым языком, который статически типизирован и пересылается только на JavaScript.
-
Flow - это препроцессор JavaScript, который предназначен для одной и той же проблемы, но без необходимости изучения нового языка. Я предпочитаю этот подход, если вам нужна только система типов.
Некоторые разработчики JS хотят больше и используют более функциональные идиомы программирования (алгебраические структуры данных, неизменность, сопоставление образцов,...). Это может сделать много языков программирования (OCaml, Haskell, ReasonML, F #, Scala,...).
- ReasonML - это синтаксис для OCaml, который может скомпилировать как собственный, так и JavaScript через BuckleScript. Все, что вы можете достичь с помощью Reason, также может быть достигнуто с помощью OCaml, за исключением того, что синтаксис ReasonML принимает JSX. ReasonML может легко настроить приложение node.js, приложение response.js или собственное приложение.
ТипScript легко узнать, если вы пришли из мира Java или С#.
ReasonML сложнее узнать, если вы никогда не разрабатывали язык ML (OCaml или F #)
Мой совет:
-
Если вам просто нужна система статического типа, вам следует рассмотреть TypeScript
-
Если вам нужна система типов, чтобы сделать приложение response.js или реагировать, вам следует подумать о ReasonML, потому что ReasonReact - это огромное улучшение по сравнению с response.js
-
Если вам нужен функциональный язык программирования, который компилируется в js, вы должны рассмотреть ReasonML
Ответ 2
Есть много компромиссов, многие из которых связаны с ReasonML технически просто OCaml и поэтому наследуют большинство дизайнерских решений из 25-летней истории OCaml, будучи изначально составленным языком, с небольшим учетом этой странной ниши JavaScript в Интернете.
Но, как мне кажется, самый большой компромисс между звуком ReasonML и гибкой системой типов и возможностью TypeScript легко "прокрадывать" всеобъемлющие статические проверки в существующую базу JavaScript кода.
Система типа TypeScript явно предназначена для того, чтобы быть неразумной, и поэтому, в то время как она даст вам руку большую часть времени, она не сможет предоставить вам много гарантий. Вы действительно не можете полностью доверять системе типов, чтобы иметь свою спину, что является одним из самых больших преимуществ наличия правильной системы статического типа.
TypeScript также ограничен решением об исключении информации типа времени выполнения, которая необходима для таких функций, как сопоставление шаблонов и большое преимущество работы с типизированными данными в ReasonML.
ReasonML, с другой стороны, требует, чтобы граница между собой и существующим кодом JavaScript была явно определена. Типы могут быть в некоторой степени выведены, но они все равно должны быть определены во время компиляции. Это делает взаимодействие JavaScript более трудоемким, особенно если граница постепенно перемещается по мере преобразования существующей базы кода JavaScript. Также не всегда очевидно, как набирать некоторые из странных вещей, которые идут в JavaScript, но это обычно возможно, и, надеюсь, просто временно, пока все не будет преобразовано в ReasonML в любом случае :)
Очевидно, я предвзятый, но я надеюсь, что это не получится, если выберете ясного победителя хотя бы потому, что на самом деле этого не происходит. Это серьезный компромисс, по крайней мере, пока мир не идеален.
Ответ 3
В большом приложении вам понадобится множество функций, которые предоставляются по умолчанию в ReasonML: строгие типы, проверка времени выполнения, если вы кодируете/декодируете JSON, быстрое время компиляции, неизменяемые данные.
В TypeScript вам нужно будет добавить:
- ImmutableJS +.
- Валидаторы времени выполнения, такие как json-schema +, его типизация. Затем вам придется писать типы в TypeScript, а также определять схему в json-схемах. Они могут скоро перестать синхронизироваться.
- Некоторые сумасшедшие хаки, чтобы сказать разницу, если переменная имеет определенный тип (например, в официальных документах TS: https://www.typescriptlang.org/docs/handbook/advanced-types.html, абзац "Пользовательские типы гвардейцев"), Эти проверки выполняются с использованием побочных эффектов, таких как a.swim! == undefined. Через 6 месяцев это выражение "если" будет содержать все больше и больше проверок.
- Вам повезло, если пакет, который вы используете, имеет официальные и поддерживаемые определения типов. Или вы закончите с пользовательскими типизациями.
- Если вы разрабатываете гибридное приложение в JS + TS, то TS Compiler не может создать пакетный окончательный файл d.ts, который можно импортировать в другие части вашего проекта. Вам нужно будет написать отдельные файлы d.ts, которые связаны с такими инструментами, как dts-bundle. Если у вас есть все в TS, эта проблема не применима.
- Большим приложениям требуется много времени для компиляции с помощью TypeScript.
С ReasonML:
- Неизменяемые данные на языке.
- Присутствуют валидаторы времени выполнения (по умолчанию у них есть bs-json)
- Согласование шаблонов экономит вас от этих сумасшедших проверок.
- Вам повезло, если пакет npm, который вы хотите использовать, имеет привязки BuckleScript.
- N/A.
- Сборник ReasonML очень быстрый.
Ответ 4
(просто записка)
Отложив все практические аспекты в сторону;
Семейство языков ML основано на теории типов, называемой System-F, которая также используется, например, Purescript и Haskell.
В Typescript отсутствует столь устоявшаяся основа, и вместо этого используется новая экспериментальная система типов со множеством специальных битов (я даже не уверен, что она "формализована").
Таким образом, на первый взгляд, подход TS может показаться "практичным", но он вносит больше сложности, чем необходимо. Система F имеет небольшое количество правил, из которых состоит система, и она очень общая, но все же легче рассуждать об этой "теории" TS. Меньше - больше.
Кроме того, усилия, прилагаемые к изучению System-F, являются вневременными и переводят на другие, более мощные языки, такие как Purescript.
Ответ 5
Они очень разные.
- ReasonML - это отличный язык от JavaScript, который компилируется до JavaScript
- TypeScript - это строгий надмножество JavaScript, которое сводится к JavaScript
Если вы хотите написать typafe-код, то это отличный выбор.
-
Если вы хотите писать типы JavaScript, то TypeScript является опцией.
-
Если вы хотите написать typafe какой-либо язык, который скомпилирован с JavaScript, то ReasonML является одним из многих вариантов. Некоторым языком в случае ReasonML является OCAML.
Больше
Мое предвзятое мнение: https://medium.com/@basarat/typescript-won-a4e0dfde4b08
Ответ 6
Причина ML приходит с функциональной первой школой, если вы настроены на то, чтобы идти. Принимая во внимание, что машинопись может делать fp, а также имеет хорошую поддержку сообщества. Почти во всех популярных библиотеках есть машинопись. Я предпочитаю использовать fpts (https://github.com/gcanti/fp-ts/blob/master/README.md). Он предоставляет все преимущества fp в машинописи, включая проверку во время выполнения. Хотя тип конструктор большой промах в тс. Выберите ts, если вы в порядке, чтобы жить с этим.