Выглядит так, что это экономически оправдано только при условии, что компания может выдержать большую текучку. Те же "бодишопы". Сложно представить, что такой подход будет работать во всех случаях
Вообще звучит как наброс, конечно. Если Wrike работает медленно или неоптимально — такое возможно (хоть и маловероятно). И тут либо отказаться от использования и ударить по нам рублём — будет тяжело, но мы с честью встретим этот удар. Либо, если есть сомнения в профессионализме — то я бы (без шуток), послушал, как лучше сделать. Век живи, век учись, за хороший совет и денег не жалко. Тут хочется понять, какой предмет обиды?
Денис, спасибо за конструктивный ответ! А какой именно презентации, было три докладчика. Просто может быть комментарий адресован Одноклассникам или WarGaming?
что представляет из себя компонент, который вы зарелизели
У нас есть такая штука, как одновременное редактирование задач. Как в google документах, видно кто и что сейчас пишет, есть маркеры и пр. В основе лежит парадигма Operation Transformation. Как раз backend часть этой фичи и написана на Dart. Вкратце приложение общается с MongoDB и Postgress и с клиентом по websockets и передаёт туда-обратно данные
вы полностью его переписали на Dart или он по прежнему гибридный
Код в основном на Dart, есть небольшие модули на node, но в скором времени и их не будет
Что нужно для того что бы запустить на сервере код который написан на Dart?
Тут скорее имелось в виду, что из-за мультипарадигменности и "свободы" JS на нём можно писать многими способами. Сам язык не даёт каких-то подсказок на эту тему. Языки же с более строгим "вектором" конечно ограничивают разработчика, но и дают ему многое. Статический анализ, типизация и прочее. Учитывая популярнось TS, Flow, уже очевидно, что мировое сообщество заинтересовано в типизации в web
А мы сейчас обсуждаем, что лучше Dart или scala? Я не знаю, так как на скале не писал. Из того, что вы перечислили Dart умеет всё, ну кроме маргинальных "data science и Заниматься хардварным дизайном"
Инструмент должен уметь делать что-то хорошо, а не всё, иначе он превратится неизвестно во что.
Я прочитал параграф про «Почему не Typescript» два раза, но ответа на вопрос так и не нашел. Судя по всему, объективной причины нет и просто «так сложилось».
Вот вам ответ: Dart мне позволяет писать в полностью ООП стиле. Именно в том, который в Java / C# / C++. Местные идиомы и особенности наверное хороши для тех, кто пришёл из JS и не имеет опыта в других языках, я же не осуждаю.
Порождаемый Dart код может быть быстрее, чем js. Да, тут наверное самый скользкий плюс, так как он сильно разнится от примера к примеру. Но несомненный плюс в том, что в Dart действует парадигма из Java "Write once — Compile Everywhere". Т.е. когда я пишу код на Dart — я знаю, что с выходом новой версии v8 например, он будет скомпилирован в максимально эффективный js код. Например с выходом DDC (Dart dev Compiler) код компилируется в ES6.
Ну если вкратце:
Типизация 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 есть SDK. Туда входит то, для чего в TS и JS надо подключать сторонние библиотеки. Которые имеют свойство устаревать, конфликтовать и пр. Это напрример потоки (rx.js), зоны (zone.js) и многое другое
А вы были на конференции?
Это, к сожалению, не решает проблемы "оффлайн" общения. Т.е. можно даже в лицо человека не увидеть.
Выглядит так, что это экономически оправдано только при условии, что компания может выдержать большую текучку. Те же "бодишопы". Сложно представить, что такой подход будет работать во всех случаях
Вообще звучит как наброс, конечно. Если Wrike работает медленно или неоптимально — такое возможно (хоть и маловероятно). И тут либо отказаться от использования и ударить по нам рублём — будет тяжело, но мы с честью встретим этот удар. Либо, если есть сомнения в профессионализме — то я бы (без шуток), послушал, как лучше сделать. Век живи, век учись, за хороший совет и денег не жалко. Тут хочется понять, какой предмет обиды?
Денис, спасибо за конструктивный ответ! А какой именно презентации, было три докладчика. Просто может быть комментарий адресован Одноклассникам или WarGaming?
Прошу :-)
https://bunopus.github.io/presentation-ng2-vs-react/#/
Давайте по-порядку:
У нас есть такая штука, как одновременное редактирование задач. Как в google документах, видно кто и что сейчас пишет, есть маркеры и пр. В основе лежит парадигма Operation Transformation. Как раз backend часть этой фичи и написана на Dart. Вкратце приложение общается с MongoDB и Postgress и с клиентом по websockets и передаёт туда-обратно данные
Код в основном на Dart, есть небольшие модули на node, но в скором времени и их не будет
Поставить Dart
Не очень понимаю, к какому, но да, ничто не мешает это сделать. Есть такая штука Aqueduct
Тут скорее имелось в виду, что из-за мультипарадигменности и "свободы" JS на нём можно писать многими способами. Сам язык не даёт каких-то подсказок на эту тему. Языки же с более строгим "вектором" конечно ограничивают разработчика, но и дают ему многое. Статический анализ, типизация и прочее. Учитывая популярнось TS, Flow, уже очевидно, что мировое сообщество заинтересовано в типизации в web
А мы сейчас обсуждаем, что лучше Dart или scala? Я не знаю, так как на скале не писал. Из того, что вы перечислили Dart умеет всё, ну кроме маргинальных "data science и Заниматься хардварным дизайном"
Инструмент должен уметь делать что-то хорошо, а не всё, иначе он превратится неизвестно во что.
Эм. Ну вы уж простите, но как по мне scala ещё более "нишевый" язык. И насчёт
Да, к сожалению пока так :-(
Это не так, я уже выше расписал причины
Вы уж извините, но от GWT уже пахнет :-) Он уже лет пять как устарел.
К сожалению самой свежей инфы нет. Сейчас в планах перейти на Dart 1.24, он делает более эффективную компиляцию в JS. Тогда и обновим данные
Нашёл специально хорошую статью про Rollup и его ограничения
https://medium.com/@Rich_Harris/tree-shaking-versus-dead-code-elimination-d3765df85c80
Да, через него. Ну, каких-то особых не замечено, есть какие-то конкретные примеры?
Я напомню, изначально я отвечал на вопрос
Вот вам ответ: Dart мне позволяет писать в полностью ООП стиле. Именно в том, который в Java / C# / C++.
Местные идиомы и особенности наверное хороши для тех, кто пришёл из JS и не имеет опыта в других языках, я же не осуждаю.
Порождаемый Dart код может быть быстрее, чем js. Да, тут наверное самый скользкий плюс, так как он сильно разнится от примера к примеру. Но несомненный плюс в том, что в Dart действует парадигма из Java "Write once — Compile Everywhere". Т.е. когда я пишу код на Dart — я знаю, что с выходом новой версии v8 например, он будет скомпилирован в максимально эффективный js код. Например с выходом DDC (Dart dev Compiler) код компилируется в ES6.
Ну если вкратце:
Типизация Dart более "строгая". Каноничный пример TS
окей, пишем guard, но только на Plane
Да, можно сказать, что интерфейс это просто набор методов и свойств, так что всё правомерно, но это не так.
В Dart есть такая штука https://www.dartlang.org/guides/language/sound-dart
В Dart есть SDK. Туда входит то, для чего в TS и JS надо подключать сторонние библиотеки. Которые имеют свойство устаревать, конфликтовать и пр. Это напрример потоки (rx.js), зоны (zone.js) и многое другое
Сейчас легаси живёт вместе с AngularDart, бОльшую часть уже переписали, да.