Вот это можно было бы использовать как солидный парсер stacktrace (там есть всякие нюансы, кросс браузерность и тд) https://github.com/stacktracejs/stacktrace.js В принципе эта либа + простейший UI и библиотека не нужна.
Кстати я бы не хотел себе в команду человека эксперта в алгоритмах, но без опыта работы над реальными проектами и задачами, точнее без опыта успешного запуска и развития проектов. Есть ведь мнение что всякие "лаборанты" рубящие в алгоритамах, ученые всякие, пишут корявый код.
Я разработчик экспериментальной системы управления крылатым беспилотником.
Ваши доводы очевидны учитывая специфику работы, было бы странно если бы вам там не приходилось пилить кастомные алгоритмы, даже само слово "экспериментальной" указывает на необходимость этого. То есть доводы оторваны от реального мира, если за таковой брать основную нишу разработки — прикладная разработка.
Естественно TS массово рынок не захватит, потому что на рынке полно простых поделок, и это нормально. Уже ведь давно используют всякие питоны/php/руби для одних задач (стартапики всякие, пилоты, ну совсем упоротые и для серьезных проектов), и Java / C# / C++ для других. Так вот и здесь.
Для работы знать не нужно. Достаточно просто иметь минимальное предствавление о алгоритмах. Нормальный инженер при необходимости (что в обычной прикладной разработке бывает не часто) поднимет нужные материалы, выберет оптимальные алгоритмы и реализует задачу. В прикладной разработке чем проще код тем лучше, лучше использовать библиотечные реализации.
Знать нужно только для собеседований в большие компании. Так как там берут с расчетом что без проблем смогут тебея кидать на любые проекты так как "академическая база" хорошая.
webpack обработает es6 импорты при небольшой его настройке, а в v2 которая в бете это уже из коробки идет. Хотя я хз уживется ли es6 импорт с es5 кодом не пробовал, я require стиль использую.
Но если автор пробовал миграцию старого проекта на ES6, то знает, что эта задача тоже сильно не уступает в веселости.
Я вообще считаю мигрировать на ES6 нет большого смыслы, ну станет год более "сахарным", но все фундаментальные проблемы то все равно останутся на месте, чего не скажешь о TypeScript.
Посмотрел LInkedin профиль этого Austin, вроде опытный человек (хотя не все опытыне являются инженерами), а пишет какую-то желтизну, как будто заказали ему этот пост или просто решил трафика/внимания привлечь к себе.
typescript это superset js, так что любой уже написанный js будет изначально являтся валидным typescript кодом. С 1.8 версии добавился флаг --allowJs, в таком случае даже переименовывать файлы не нужно будет (то есть можно переводить на ts постепенно, но при этом собирая все в один бандл).
Рано или поздно поддержка типов будет в JavaScript и тогда TypeScript окажется никому не нужным.
Как отмечает Austin "Все что нужно будет сделать – это исправить синтаксис с помощью поиска и замены", так вот когда появятся типы в ECMAScript тогда можно будет применить его волшебную "автозамену" :) Вообще не видно чтобы они там планиовалии типы в своих стандартах, так что ждать их появления в стандарте придется долго, не говоря уже о появлении в бразерах, а с TypeScript уже сейчас можно писать как принято говорить maintainable и scalable приложения.
Если это популярная библиотека, то для нее, скорее всего, уже будет написан TSD. А если нет – то его придется писать вам. Или подменять все ее глобальные идентификаторы. Больше работы, больше головной боли, и с этим ничего нельзя поделать.
Для серьезного долгосрочного проекта однократное написание TSD не стоит ничего, к тому же количество добаляемых в проект библиотек обычно довольно ограничено и в первую очередь будут выбираться "взрослые" библиотеки для которыз TSD уже готовы. Полагаю этот Austin работает с серьезными проектами, но тогда мне не понятно зачем притягивать за уши подобные доводы.
Не сложится потому что в ECMAScript даже следующих версиях не предвидится типизации (до них все не дойдет что есть вещи поважнее чем их "сахар"), а TypeScript это и есть ECMAScript + опциональная типизация. Можно считать это расширением ECMAScript.
Как вы себе это представляете в без-серверной архитектуре?
> Как пользоваться на нескольких устройствах?
Из той же серии, нет ведь сервера для синхронихации между клиентами.
Если вам нужно что-то с центральным сервером, то зачем тогда смотреть на Tox.
Скорее кому-то приходится его "ложить", сам то не ляжет.
Ваши доводы очевидны учитывая специфику работы, было бы странно если бы вам там не приходилось пилить кастомные алгоритмы, даже само слово "экспериментальной" указывает на необходимость этого. То есть доводы оторваны от реального мира, если за таковой брать основную нишу разработки — прикладная разработка.
Знать нужно только для собеседований в большие компании. Так как там берут с расчетом что без проблем смогут тебея кидать на любые проекты так как "академическая база" хорошая.
Я вообще считаю мигрировать на ES6 нет большого смыслы, ну станет год более "сахарным", но все фундаментальные проблемы то все равно останутся на месте, чего не скажешь о TypeScript.
Как отмечает Austin "Все что нужно будет сделать – это исправить синтаксис с помощью поиска и замены", так вот когда появятся типы в ECMAScript тогда можно будет применить его волшебную "автозамену" :) Вообще не видно чтобы они там планиовалии типы в своих стандартах, так что ждать их появления в стандарте придется долго, не говоря уже о появлении в бразерах, а с TypeScript уже сейчас можно писать как принято говорить maintainable и scalable приложения.
Для серьезного долгосрочного проекта однократное написание TSD не стоит ничего, к тому же количество добаляемых в проект библиотек обычно довольно ограничено и в первую очередь будут выбираться "взрослые" библиотеки для которыз TSD уже готовы. Полагаю этот Austin работает с серьезными проектами, но тогда мне не понятно зачем притягивать за уши подобные доводы.
так ведь в том и дело, заморачиваться нужно (настраивать, мониторить и тд), а так бы вообще никто SaaS сервисами не пользовался