Специалисты «по фреймворкам» это очень ограниченный люди, я бы лучше взял в команду в общем плане толкового человека чем некого эксперта одного фреймворка. Фреймворки умирают и рождаются, и при этом желательно чтобы опыт оставался с тобой.
Ну, если принять что за единицу времени два программиста получают одинаковое кол-во опыта/знаний
Это не так, далеко не так. Люди обычно разно мотивированы, и кроме этого некоторые вообще случайные люди в своей професиии.
Вышеназванное ничего общего с фуллстек не имеет. Судя по моему опыту, настоящих фуллстек инжереров очень очень мало, они такими стали не по приказу начальства, а по своей инициативе и ввиду возможно своей любознательности и задротства.
Человек которому доверяют работать индивидуально как правило заслужил такую репутацию, и как правило перед тем как приступить к задаче он задает все нужные вопросы по имеющися требованиям плюс интересуетя перспективой проекта чтобы предвидеть потенциально узкие места.
Но, по-прежнему считаю, что толковый специалист их конкретной области, сделает все быстрее и лучше, чем специалист широкого профиля.
Фуллстек не тратит дополнительное времени на коммуникацию, тк работает один, он привык видеть всю картину и менее зависеть от прогресса коллег. Допустим если нужно сделать фичу быстро (первую версию, скажем пилот, а дальше если нормально пойдет вся команда подключится), то фуллстек в человекочасах сделает гораздо быстрее (раза в 2 минимум быстрее) и без особого ущерба качеству чем команда из ускоспециализированных специалистов.
секретные чаты с временными ключами, но реализованы они неудобно
В десктоп клиенте вообще не реализованы (по крайней меря для Win/Linux).
Я вот не вижу смыла в Telegram тк модель с центральным сервером заведома не безопасная, что бы они там не заявляли. Смысл использования теряется еще более если учесть что используется некая кастомная реализации криптографии (считается плохим тоном), частично закрытый код, необходимость привязки к телефону. Очевидно компаниям не интересно делать чаты без центральногьо сервера, интерес ведь именно в базе пользователей, поэтому вероятно p2p чаты пилят всякие гики, а не компании.
Причем здесь фреймворки, речь шла о функциональщине против ООП с типизацией. Пишите свои глупости если хотите, но комментариев на них с моей стороны больше не будет.
типа, деды так делали, отцы так делали, и мы так будем делать.
Я работаю по обе стороны барикад, сейчас это называют фуллстек, и свой выбор делаю не на основе некой исторической сложившейся истины или хипстерского тренда, а на основе своего опыта тк я имел возможность сравнить различные подходы на практике.
Точно, и мозги тогда уже не нужны. Я хоть и не сторонник использования ФП для серьзеных и больших проектов особенно когда команда разношерстная, но так категоричеки о ФП не высказываюсь. Оно нужно как мннимум чтобы покрасоваться какой я «функциональный» (даже если это идет в разрез с инженерными практиками и делает проект неподдерживаемым) и влепить что-то в блог.
Это очевидно. Coffeescript сыграл свою роль и появился хипстерский ES6. Когда-то может быть и TS сыграет подобную роль и в ECMAScript все таки появится типизация (в очень отдаленной перспективе судя по текущему положению дел). Так вот пока типов в ECMAScript нет (и не появится в скором времени) можно использвать TS. Или предлагаете сидеть на ES6 и ждать пока там появятся типы?
На выходе «говно» код, с большой вложенностью селекторов и высокой специфичностью.
То что вам инстумент не подошел (инструмент ведь вам говнокод вам делает, не вы сами?) не причина его не использовать другим у кого говнокод не получается сделать.
> И в итоге исходный код в общем короче и проще. А всё потому, что у меня архитектура. А у вас решение высосаное из пальца.
Очень спорное суждение, удачи вам с вашей «архитектурой CSS», рад что вы довольны собой и своей архитектурой, я вот часто ставлю под сомнения свои решения и бывает их пересматриваю, но вам видимо это не знакомо потому что и так все идеально.
One feature you might be wondering about is support for async functions in ES3 & ES5. Originally, this was slated for the 2.0 release; however, to reasonably implement async/await, we needed to rewrite TypeScript’s emitter as a series of tree transformations. Doing so, while keeping TypeScript fast, has required a lot of work and attention to detail. While we feel confident in today’s implementation, confidence is no match for thorough testing, and more time is needed for async/awaitto stabilize. You can expect it in TypeScript 2.1, and if you’d like to track the progress, the pull request is currently open on GitHub (https://github.com/Microsoft/TypeScript/pull/9175).
язык запроектирован таким, что бы быть транслируемым
Только вот факт в том что когда JS создавался никто не догадывался какую значимую роль он на себя возьмет в будующем, ознакомьтесь и историей, не нужно притягивать доводы за уши. К тому же он и остается транслируемым, в рантайме.
Мы же хотим, что бы все работало быстро.
Каким образом использование TS влияет на итоговую скорость работы скрипта? В итоге ведь тот же JS получается, и та же история с CSS процессорами.
но он нового класа и под ограничение типа не попал
Учите матчасть и проектируйте систему гибко. Суть как раз в том и состоит чтобы наложить жесткие ограничения.
А если в CSS есть правильное архитектурное решение
Самый простой и очевидный пример. Допустим у проекта много заказчиков и каждый хочет свою цветовую гамму (требование заказчика намеренно упрощено, но предположим кастомизируется только цветовая гамма). Как на чистом CSS вы сделаете это грамотно? C процессором я просто задам набор переменных для каждого заказчика.
TypeScript не рассматриваете как инструмент транслирования TS кода в JS код
Как раз рассматриваю, выше имел ввиду что TypeScript это боее чем просто транслятор и в этом случае нет большого смысла использовать Babel, а лучше взять TS плюс то что он дает в придачу.
Инженеры делают спокойно свою работу в то время когда ФП фанбои пишут свои блоги и заливают ролики на ютюб, им ведь нужны холивары чтобы привлечь к своей персоне внимание.
Странно сравнивать Babel — инстурмент транслирования кода и TypeScript диалект ES. TypeScript сам по себе без всяких Babel может сделать вам ES5, некоторые даже используют TS вместо Babel для ES6 кода (не TS) потому что им больше нравится какой итоговый код он генерирует. Dart не полетел потому что новый синтаксис, сложнее порог вхождения и перспективы не очевидны опять же потому что это не насдстройка над JS. CoffeeScript d наiе время использовать глупо (для новых начинаний), потому что уже есть ES6.
Это не так, далеко не так. Люди обычно разно мотивированы, и кроме этого некоторые вообще случайные люди в своей професиии.
Я вот не вижу смыла в Telegram тк модель с центральным сервером заведома не безопасная, что бы они там не заявляли. Смысл использования теряется еще более если учесть что используется некая кастомная реализации криптографии (считается плохим тоном), частично закрытый код, необходимость привязки к телефону. Очевидно компаниям не интересно делать чаты без центральногьо сервера, интерес ведь именно в базе пользователей, поэтому вероятно p2p чаты пилят всякие гики, а не компании.
Я работаю по обе стороны барикад, сейчас это называют фуллстек, и свой выбор делаю не на основе некой исторической сложившейся истины или хипстерского тренда, а на основе своего опыта тк я имел возможность сравнить различные подходы на практике.
Это очевидно. Coffeescript сыграл свою роль и появился хипстерский ES6. Когда-то может быть и TS сыграет подобную роль и в ECMAScript все таки появится типизация (в очень отдаленной перспективе судя по текущему положению дел). Так вот пока типов в ECMAScript нет (и не появится в скором времени) можно использвать TS. Или предлагаете сидеть на ES6 и ждать пока там появятся типы?
То что вам инстумент не подошел (инструмент ведь вам говнокод вам делает, не вы сами?) не причина его не использовать другим у кого говнокод не получается сделать.
Очень спорное суждение, удачи вам с вашей «архитектурой CSS», рад что вы довольны собой и своей архитектурой, я вот часто ставлю под сомнения свои решения и бывает их пересматриваю, но вам видимо это не знакомо потому что и так все идеально.
Только вот факт в том что когда JS создавался никто не догадывался какую значимую роль он на себя возьмет в будующем, ознакомьтесь и историей, не нужно притягивать доводы за уши. К тому же он и остается транслируемым, в рантайме.
Каким образом использование TS влияет на итоговую скорость работы скрипта? В итоге ведь тот же JS получается, и та же история с CSS процессорами.
Учите матчасть и проектируйте систему гибко. Суть как раз в том и состоит чтобы наложить жесткие ограничения.
Самый простой и очевидный пример. Допустим у проекта много заказчиков и каждый хочет свою цветовую гамму (требование заказчика намеренно упрощено, но предположим кастомизируется только цветовая гамма). Как на чистом CSS вы сделаете это грамотно? C процессором я просто задам набор переменных для каждого заказчика.
$ tsc test.ts:
Аналогичный результат можно получить здесь https://www.typescriptlang.org/play/
Также вот для ознакомления https://github.com/Microsoft/TypeScript/wiki/What's-new-in-TypeScript#typescript-20