Комментарии 49
Angular 3?
Для Dart есть свой Angular, вот тут: https://github.com/dart-lang/angular2
И у него последняя версия действительно 3.
Последнюю версию Polymer ещё не пробовали, но сильно сомневаюсь, что он побъёт Angular по богатству фичей, всё таки это скорее библиотека компонентов + шаблонизатор
На всякий случай добавлю, что у webpack тоже есть tree shaking с ES6 модулями (если используется babel, нужно в конфиге отключить трансформацию импортов/экспортов), да и google closure compiller тоже вроде как умел в такое.
Тут есть принципиальное различие: Tree shaking на уровне модулей это типа
// a.js
class A {
someMethod() {
//...
}
}
class SomeVeryBigClass {
//...
}
export {
A, SomeVeryBigClass
}
--------------------------
// b.js
export class B {
anotherMethod() {
//...
}
}
-------------------------
// c.js
import 'a.js'
let a = new A();
В случае "модульного" перетряхивания модуль b.js не будет подключен. Однако все классы из модуля a.js будут присутствовать, внезависимости от того, используются ли они или нет.
Что же Dart?
// a.dart
class A {
someMethod() {
//...
}
}
class SomeVeryBigClass {
//...
}
-------------------------
import 'a.dart'
main() {
var a = new A()
}
В случае Dart перетряхивание уберёт не только класс SomeVeryBigClass, но и someMethod из класса A, так как он не используется.
Итого разница — Tree Shaking в Дарт более гранулярный, он может убирать всё, вплоть до методов и свойств класса.
Нашёл специально хорошую статью про Rollup и его ограничения
https://medium.com/@Rich_Harris/tree-shaking-versus-dead-code-elimination-d3765df85c80
Dart заставляет нас писать лаконично и правильноА Typescript заставляет писать объемно и криво, подталкивает к ошибкам при проектировании?..
Я прочитал параграф про «Почему не Typescript» два раза, но ответа на вопрос так и не нашел. Судя по всему, объективной причины нет и просто «так сложилось».
Typescript все-таки является расширением Javascript. Грубо говоря, можно переименовать файл js -> ts, и код все равно будет собираться.
Dart это совершенно другой язык, со своей парадигмой. Писать в Javascript-стиле на нем не получится. Поэтому можно сказать, что на Dart код получится "правильнее".
Грубо говоря, можно переименовать файл js -> ts, и код все равно будет собираться.Если задача — не дать разработчикам схалявить, то можно включить жесткие проверки компилятора —
noImplicitAny, noUnusedLocals, allowUnreachableCode, allowJs
.Поэтому можно сказать, что на Dart код получится «правильнее».Нельзя. Парадигма другая, но это не делает ее априори «правильной».
Именно поэтому я взял слово "правильно" в кавычки. Имеется в виду, что на Dart получится более Javaподобный enterprise код чем на Typescript. Во Wrike захотели именно такого, но это не значит что это нужно всем.
Кроме того Dart это совершенно отдельный язык, такой же как и Kotlin, что может транслироваться в JS, а Typescript — это расширение JS.
на Dart получится более Javaподобный enterprise код чем на Typescript
А можно конкретный пример? Я не знаток Dart, но в списке возможностей на сайте не нашел ничего такого, чего нельзя было бы реализовать в Typescript (кроме, наверное, перегрузки операторов).
Кроме того Dart это совершенно отдельный язык, ..., а Typescript — это расширение JS.
Каким образом два этих факта говорят в пользу Dart?
Я слежу за большим проектом на Dart: https://github.com/sass/dart-sass
Код там больше напоминает Java или C#, где в основном используются классы и ООП.
На Typescript в таком стиле тоже можно писать. Но сам язык этого не требует, можно писать просто функции. Вот пример из исходников самого Typescript:
https://github.com/Microsoft/TypeScript/blob/master/src/compiler/core.ts
Поэтому те, кто хотят получить себе ООП в основе языка, а не в виде сахара поверх прототипов, выбирают Dart.
bunopus ниже показывает то же самое на примере типов Car и Ford.
Но сам язык этого не требуетСудя по исходникам указанного вами же проекта, Dart тоже не требует. Да и в целом, язык должен быть гибким и позволять организовать архитектуру как удобно, а жесткие ограничения — это задача фреймворков и корпоративного стайлгайда.
Ну если вкратце:
Типизация Dart более "строгая". Каноничный пример TS
interface Car {
drive();
}
interface Plane {
drive();
}
abstract class Ford {
}
class Focus extends Ford implements Car {
drive() {
console.log('I am driving');
}
}
let my_car: Focus = new Focus();
console.log(my_car instanceof Ford); // true
console.log(my_car instanceof Car); // Нельзя проверять интерфейсы в runtime!!!
окей, пишем guard, но только на Plane
function isPlane(arg: any): arg is Plane {
return arg.drive !== undefined;
}
console.log(isPlane(my_car)); // true, несмотря на то, что my_car другого интерфейса
Да, можно сказать, что интерфейс это просто набор методов и свойств, так что всё правомерно, но это не так.
В Dart есть такая штука https://www.dartlang.org/guides/language/sound-dart
В Dart есть SDK. Туда входит то, для чего в TS и JS надо подключать сторонние библиотеки. Которые имеют свойство устаревать, конфликтовать и пр. Это напрример потоки (rx.js), зоны (zone.js) и многое другое
То, что в Typescript описывается ключевым словом
interface
, на самом деле является формой класса. Она действительно описывает только список методов и свойств и существует только на этапе компиляции. Поскольку типизация с Typescript структурная, классу не обязательно явно указывать интерфейс при объявлении, чтобы его реализовать — даже анонимный класс с необходимыми полями подойдет! С таким подходом можно писать более гибкие абстракции, не лишаясь строгой типизации — например, когда вы используете чужие классы и не можете внести в их объявление собственный интерфейс.По поводу type guard: а почему вы решили, что на основании наличия метода
drive
можно сделать вывод о том, что объект принадлежит типу Plane
? С точки зрения структурной типизации два интерфейса с одинаковыми сигнатурами являются одной и той же формой. Если нужно различать произвольные объекты, то можно использовать tagged union types.Вы пытаетесь скормить Typescript код, написанный для языков вроде Java / C# / C++, без учета местных идиом и особенностей. Неудивительно, что он работает не так, как вы ожидаете.
Немного не так. Не все хотят разбираться с особенностями местных идиом и особенностей, а просто хотят писать так же, как привыкли в Java или C#.
Dart эту возможность предоставляет.
Я напомню, изначально я отвечал на вопрос
Я прочитал параграф про «Почему не Typescript» два раза, но ответа на вопрос так и не нашел. Судя по всему, объективной причины нет и просто «так сложилось».
Вот вам ответ: Dart мне позволяет писать в полностью ООП стиле. Именно в том, который в Java / C# / C++.
Местные идиомы и особенности наверное хороши для тех, кто пришёл из JS и не имеет опыта в других языках, я же не осуждаю.
С другой стороны, при работе с новым языком всегда приходится изучить определенный объем тонкостей — синтаксис, best practices, стандартная библиотека. На фоне этого объема различия между прототипным и классическим наследованием не выглядят такими уж существенными.
Да нет, каноничный вариант на TS будет выглядеть так:
abstract class Car {
readonly brand : string
abstract drive() : void
}
abstract class Plane {
readonly brand : string
abstract drive() : void
}
class Focus extends Car {
readonly brand = 'Ford'
drive() {
console.log( 'I am driving' )
}
}
const my_car = new Focus
console.log( my_car.brand === 'Ford' ) // true
console.log( my_car instanceof Car ) // true
Это например потоки (rx.js), зоны (zone.js)
И зачем эти антипаттерны в стандартной библиотеке? :-)
Порождаемый Dart код может быть быстрее, чем js. Да, тут наверное самый скользкий плюс, так как он сильно разнится от примера к примеру. Но несомненный плюс в том, что в Dart действует парадигма из Java "Write once — Compile Everywhere". Т.е. когда я пишу код на Dart — я знаю, что с выходом новой версии v8 например, он будет скомпилирован в максимально эффективный js код. Например с выходом DDC (Dart dev Compiler) код компилируется в ES6.
Старые куски кода на js используете через package:js? Проблем с отложенной загрузкой не возникало?
Да, через него. Ну, каких-то особых не замечено, есть какие-то конкретные примеры?
Эм. Ну вы уж простите, но как по мне scala ещё более "нишевый" язык. И насчёт
универсальный, пригодный почти для всего язык. Такой как scala.
Звучит очень оптимистично
https://trends.google.com/trends/explore?q=scala.js,%2Fm%2F0h52xr1
1) Писать для десктопа под JVM
2) Писать для сервера (play 2, lift, etc)
3) Писать клиентский код для броузера (scala.js)
4) Заниматься data science (apache spark, tensorwlow, куча явовских библиотек)
5) Заниматься хардварным дизайном https://chisel.eecs.berkeley.edu/ (на этом кстати написан новый опенсорсный процессор RISC-V)
Единственно для чего scala непригодна, это для мобильной разработки(слишком толстый исполняемый код) и написания нативного кода. Да и то мобильная разработка станет вполне возможной в ветке scala-3, в которой обещают оптимизатор, а работа над нативным кодом идёт полным ходом (scala-native). Не покрытыми начиная с ветки 3 остаются пожалуй только две области. Это .NET и встроенные системы. Но к .NET возможно ещё вернутся. А для встроенных систем (работал с ними очень много) я даже С++ применяю с большой осторожностью и пишу фактически на С с классами. Ну и скажите на милость, что из всего этого умеет dart? Мне кажется беда scala — его репутация сложного языка. Причем совершенно не заслуженная. Его изначально боятся. Поэтому и Ваша ссылка показывает то что показывает.
А мы сейчас обсуждаем, что лучше Dart или scala? Я не знаю, так как на скале не писал. Из того, что вы перечислили Dart умеет всё, ну кроме маргинальных "data science и Заниматься хардварным дизайном"
Инструмент должен уметь делать что-то хорошо, а не всё, иначе он превратится неизвестно во что.
И кстати ни data sciense ни хардварный дизайн мне маргинальными не кажутся. Вторым я очень много в своё время занимался, правда на традиционном верилоге. Первым очень интересуюсь сейчас. На scala для продакшена пока ничего не писал. Сейчас этот язык у меня в стадии активного освоения. Следующий веб-проект хочу с нуля делать именно на scala.js. Кстати будет очень хороший повод сравнить scala и dart по удобству. Возможно даже напишу об этом на хабре.
Два года с Dart: о том, как мы пишем на языке, который ежегодно «хоронят» (часть 1)