Давид Хейнемейер Ханссон (David Heinemeier Hansson), автогонщик и автор веб-фреймворка Ruby on Rails, объявил о прекращении поддержки языка программирования TypeScript в коде развиваемого им проекта Turbo и переходе на использование чистого JavaScript начиная с выпуска Turbo 8, без задействования строгой типизации. Уход от использования TypeScript во фреймворке Turbo не повлияет на возможность применения TypeScript в клиентском коде или подключение библиотек, написанных на TypeScript...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=59729
> В Turbo применяется концепция построения интерактивных web-приложений "HTML-over-the-wire", при которой сервер вместо использования JSON напрямую отправляет клиенту HTML-код. Отмечается, что реализованный подход позволяет минимизировать использование JavaScript в web-приложении, обеспечить высокую производительность и упростить процесс доработки приложений.Это как в HTMX?
Когда-то деды называли это Ajax.
ASP.NET WebForms же.
Delphi forms же, ну. Какие еще asp.net'ы?
Компании стало тяжело поддерживать свои проекты на двух похожих языках, так как экосистема тоже отличается, хоть и не значительно.Решение понятное, но грубое.
Svelte тоже перешел недавно на JS+JSDoc с типам, и там была интересная дискуссия, о том что библиотеки вообще следует делать только на чистом JS, чтобы например при каких-то ошибках тебе указывало точно на номер строки, а не пыталось из скомпилированного из Тайпскрипта представления найти где же это было в оригинале.Вот тут он пришел к главному фанату раста на ютюбе и объяснился. https://www.youtube.com/watch?v=zPOHY-cZ1wE
> главному фанату растаДа вроде уже перестал фанатеть.
Это он просто обиделся немного. Отойдёт и снова вернётся)
> Svelte тоже перешел недавно на JS+JSDoc с типам, и там была интересная дискуссия,
> о том что библиотеки вообще следует делать только на чистом JS, чтобы...чтобы наслаждаться багами сразу в либе, а ошибки - какие ошибки, если типов нет, в самом деле? И на все остальные ошибки - тоже забить, так кодить еще проще будет! :)
Для решения подобной проблемы существуют Source Map
создадим проблему и создадим инструмент её решения
Руби не стал топчиком и это не станет)
топчик это эликсир
"... но пользоваться им я конечно не буду"(Ц)?
Так мы и рубями не пользуемся. Зачем? Есть бидон, глагне, тупоскрипт и сисиплюс для людей
> Так мы и рубями не пользуемся. Зачем? Есть бидон, глагне, тупоскрипт и
> сисиплюс для людейНу вот да. Разве что крестов нету - есть C#/java
Турбой не пользуюсь, но решение одобряю. Понакрутили обёрток вокруг обёрток.
а дюшей метелкиным пользуешься?))
Только Стасом.
> Турбой не пользуюсь, но решение одобряю. Понакрутили обёрток вокруг обёрток.Их накрутили не от хорошей жизни. А заметив что если проект становится крупным, без типов баги начинают задалбывать - а дебажить это все становится почти невозможно. Хотя конечно откатить и вспомнить почему это было - вариант. А потом охренеть с такого дебага и перейти обратно :)
> Давид Хейнемейер Ханссон (David Heinemeier Hansson), автогонщикчто?) у этого драйвера ещё страничка на вики есть, полюбому самописная
хотя, он Ли Ман выиграл, что уже неплохо
У гонщиков и javascript разработчиков особый склад ума.Гонщики: сейчас и так сойдет, все равно к концу сезона машине нужен будет капитальный ремонт.
javascript разработчи: "укажите тип аргумента функции, чтобы Number вместо String туда не засунули" - нафига, к концу месяца еще пять раз перепишем с нуля.
Это пока им не выдвинули требования поддерживать их поделки лет 20, с ответственностью за качество кода-)))
Да, когда нам выдвинули: реально пришлось на TS перейти. В больших проектах даже ES6 не спас, только добавлял трудности поддержки IE (хорошо что уже помер).
Большой проект нужно резать на маленькие кусочки. И все прекрасно поддерживается.
+,!! и `${}` если боишься, что засунут не то и слишком ленив писать гарды. двоечник
> +,!! и `${}` если боишься, что засунут не то и слишком ленив писать гардыЗачем? Завтра ведь нужно будет на другой фреймворк переписать, чтобы быть в тренде и этой функции уже не будет.
Это Javascript, baby, это javascript baby.
Руби не без строгой типизации и там принято везде использовать TDD. Турбо, по своей сути - это фронтовая часть Рельс(руби фреймворка). Странно не использовать строгую типизацию на бэке и использовать на фронте.
*Руби без строгой типизации и там принято везде использовать TDD
fix
Типы не нужны. Они только запутывают и усложняют не только код но и логику.В будущем появятся инструменты которые сами будут майнить типы и не добавлять дополнительный уровень оверхеда коим щас является турескрипт
> Типы не нужныУ вас [object Object] новых сообщений.
> Они только запутывают и усложняют не только код но и логику
Пользователь undefined лайкнул ваш пост от Invalid Date.
Что не так? Возьми да поправь.
> Что не так? Возьми да поправь.Для этого надо найти где это происходит. Без типов то это довольно веселое начинание.
Только тайпскрипт это не исправляет )
Разве что геммора добавит
Исправлять должен не тайпскрипт, а разработчик. Тайпскрипт лишь указывает, где ты присваиваешь ежика зайчику.> Разве что геммора добавит
В больших проектах гемором будет отсутствие тайпчекера, так как абсолютно любое изменение будет на авось. Впрочем, в хелловорлд-проектах на максимум 50 lines of code -- да, можно обойтись без тайпскрипта.
Кто-то, уровнем чуть выше самого новичкового новичка и так об этом в курсе
Вдобавок, весь код в конечном счёте блоками проходит через ведущего разработчика или кто там сидит на бочк... на репе и принимает реквесты
Отдельная проблема тайпскрипта в том, что нередко приходится делать конкретные исключения. Для строк ли, блоков ли или целых файлов
И в итоге код, помимо всего прочего тайскриптового мусора, обрастает ещё и тоннами директив к нему> В больших проектах гемором будет отсутствие тайпчекера,
> так как абсолютно любое изменение будет на авось.В любых сколь-нибудь серьёзных проектах где более одного разработчика, есть какой-нибудь ведущий/старший программист, который чётко отслеживает каждый коммит и пинает ж.еппы
Вдобавок, код, который не протестирован локально и, желательно, тестировщиком, вообще не должен попадать в основные ветви, есть ли тайпскрипт или нетЕсть баг/доработка - есть работа проггера - есть тестирование что поправилось но и ничего не отвалилось - есть реквест в репу - есть ведущий программист что глядит код и требует переписать даже если по пробелам что-то не сходится
> Впрочем, в хелловорлд-проектах на максимум 50 lines of code --
> да, можно обойтись без тайпскрипта.На тайпскрипте те хеллоу и ворды разве что и писать
Ибо совершенно неприлично развязывают проггеру руки в плане беспредельного го.мнокода с обилием всевозможных наследований и прочих радостей псевдо-ООП с лишним слоем абстракций и зависимостей
> весь код в конечном счёте блоками проходит через ведущего разработчикаКоторый помнит все сотни тысяч строк проекта, верно? В голове удерживает всё то, что едва-едва умещает тайпскрипт в RAM, да? Я же говорю: твой уровень -- хелловорлд, а с по-настоящему крупными проектами >1,000,000 LoC ты не сталкивался.
> Отдельная проблема тайпскрипта в том, что нередко приходится делать конкретные исключения
> в итоге код, помимо всего прочего тайскриптового мусора, обрастает ещё и тоннами директив к немуИменно тайпскриптовые исключения -- это редкость. Гораздо чаще (на нашем - раз в 20 чаще) приходится глушить именно eslint, а не тайпскрипт. Тонны директив -- это признак того, что ваш проект провалился просто потому, что никто толком не продумывает типы, или все владеют тайпскриптом на каком-то чудовищно начальном уровне.
> с обилием всевозможных наследований и прочих радостей псевдо-ООП с лишним слоем абстракций и зависимостей
Тебя заставляют пользоваться классами? У нас они только там, где их зачем-то требуют third_party-либы. Наследованиям есть альтернатива -- композиция. Про "псевдо-ООП" бабушке своей рассказывай.
> а с по-настоящему крупными проектами >1,000,000 LoC ты не сталкивался.
> Тебя заставляют пользоваться классами? У нас они только там, где их зачем-то требуют third_party-либы.лол, а как ими не пользоваться-то? так можно и 2,000,000 ск проекты выдавать))))
я, правда не спец в жб, так, пых-самоучка))> Наследованиям есть альтернатива -- композиция.
а вот за наводку на композицию и агрегацию спасибо, что-то подобное интуитивно и приходило. мож ещё строчек в проекте урезать смогу - знакомство с классами в своё время очень помогло, надо посмотреть))
ща, он ещё раз IOOSOO подумает..)))
> Типы не нужны. Они только запутывают и усложняют не только код но и логику.А ты тонкий. Даже с чувством юмора.
> Типы не нужны. Они только запутывают и усложняют не только код но и логику.
> А ты тонкий. Даже с чувством юмора.и не говори, у меня бдешка, которая вебприложуху обслуживает, уже минут двадцать под столом катается))) ладно хоть на тестовом всё в морду льётся - на продакшене так целый юнит 24/7 на варлог сажать надо, ну или админов косоглазых брать сразу)))
> В будущем появятся инструменты которые сами будут майнить типывы про джэнерики слышали? а они уже пришли...
Они за дверью, стесняются постучать.
> Они за дверью, стесняются постучать.не пускайте, им дашь волю, и опять типизация боком
> им дашь волю, и опять типизация бокомВ нормальных языках на них можно ограничения наложить, а не как в С++ (и да, концепты все еще не решают всех проблем).
Дженерики то тут при чём? Автор про нейросети писал и инструменты на их основе. В жабаскриптах нет женериков.
> Автор про нейросети писал...Сорри, но я не телепат
ТипЫ типа вас не нужны, в будущем будут аннигилированы автоматически
Типы нужны для рефакторинга.Js разработчикам это не нужно, у них можно раз в год выкидывать и с нуля переписывать
> В будущем появятся инструменты которые сами будут майнить типыС разморозкой. Уже есть flow от запрещенной соц. сети. Правда у них все как обычно.
Будущее уже давно здесь, это Python! Никакой тебе типизации, только АННОТАЦИИ к типам!
Он как раз и падает в рантайме все время, не хуже JS. Весьма характерно.
>избавляет разработчиков от выкрутасов с типами, производимых для удовлетворения капризов компилятора TypeScriptЭто они еще не видели, какие выкрутасы нужны для удовлетворения компилятора Rust...
яваскрипт без тайпскрипта все равно, что сишка, в которой все указатели -- void*
Это как к буханке к которой добавили антены
Да же не рядом.
> какие выкрутасы нужны для удовлетворения компилятора Rust...Это не для удовлетворения компилятора, это для вразумления твоей порочной логики построения приложений. Не теми путями задачу решаешь с точки зрения безопасности, корявыми. Это легко понять, оглядываясь потом на свалку CVE и убытки от ошибок. Используй раст и со временем мозги вправятся, начнешь думать над решением задачи как дОлжно и не будешь замечать того компилятора. А может и не вправятся (мозги), тогда будешь растохейтить на опеннете.
> и со временем мозги вправятся, начнешь думать над решением задачи как дОлжно и не будешь замечать того компилятораПрям как про армию. А потом будешь удивляться
"- Раз они такие умные, почему строем не ходят ?"
Да, хорошие аналогии - они на вес золота. А чего не привел в пример в плане вправки мозгов, допустим, какую-нибудь музыкальную консерваторию, где всё строго и по науке (раст) супротив дворовой гитары с пацанами, где ори во всё горло что хошь и как хошь (си)? Конечно, во дворе с пацанами ЗНАЧИТЕЛЬНО лучше и веселее - напрягаться не надо и весело и можно матерные песенки Юры Хоя (Клинских) орать и в любой момент петуха пустить - все вместе поржёте.Да, критические CVEшки многа-многа лучше - они такие мягонькие, тепленькие, ламповые. А главное - кормят долго и надежно. Плевать, что пользователи страдают.
> Прям как про армиюНет, здесь прям как про арифметику.
ты написал 2+2=5. Нет, вправляет тебе мозги раст, 4 и никак иначе. Вот такая тут аналогия. И твои мухлёванные доказательства обратного и горбатые аналогии - от лукавого. Раст не от всего тебя ограничивает, а только от техник программирования, чреватых ошибками. Всё. Дальше твори, что хочешь. Это как в свое время был переход в создании программ от DOS к Windows/Linux. Что угодно и как угодно, как в ДОСе, с машиной уже не сделаешь, как-никак защищенный режим и куча ограничений, но творить, в определенных рамках ("в песочнице"), можешь что угодно. Если же ты постоянно вылезаешь за выделенную память или пытаешься напрямую работать с железом - ну, значит ты что-то делаешь неправильно.
>сервер вместо использования JSON напрямую отправляет клиенту HTML-код.Хоть кто-то адекватный в JS-сообществе!
Отправляет HTML, а внутри него script тег, а там jQuery. Как в старые добрые
Нафига? На странице может вообще не быть js! Достали его пихать везде, где надо и не надо.
Только 99% фич типа активных форм и навигации без круглосуточной перезагрузки всей страницы немножк не работают, а так может не быть, конечно, особенно если это страница "сайт заблокирован во имся специальной чебуречной операции"
И всё это заинлайнено так, что без сумасшедших регулярок фиг разложишь чтобы просто взять полезный пэйлоад у (ч)удаков, которые не умеют в человеческий API
Библиотек по разбору хтмл целый миллион, какие регулярки?
Для чего вам в интерфейсной либе парсить хтмл для извлечения данных? Присылайте сразу данные и проблема решена.
Не знаю. Загрязняет гимнастикой с типами? Я наоборот как то привык к строгому объявлению типа void Func(int X), чем потом в теле этой функции наковыривать жуткие конструкции типа if typeof(X) = string then...
а сразу написать на javascript религия не позволяет?
ну это у тебя с архитектурой что-то не так
Правильным курсом идёт товарищ!
Я тоже поддерживаю. Классы в ES6 завезли, так что подождать немного и будет там все что сейчас есть в TypeScript.
Колеблющаяся типизация. На самом деле, похоже, дятел владел английским, это "строго-типизированный" против "свободно-типизированный". Термина слабая типизация не существует как такового, ты его только что придумал.
> Колеблющаяся типизация. На самом деле, похоже, дятел владел английским, это "строго-типизированный"
> против "свободно-типизированный". Термина слабая типизация не существует как такового,
> ты его только что придумал.Вы прост 0 книг прочли на языке, на котором написано 100% материалов по CS.
О чём и речь. У этого слова есть 2 значения: хрупкий и немощный. Которое из них можно перевести как "слабый"? Вот это уж точно дебич какой-то придумал.
В английском ты разбираешься так же, как и в программировании...
https://translate.google.com/?sl=en&tl=ru&text=weak&op=trans...
Ну GT то конечно показатель. А как ты переведёшь weakly?
> и теперь антоним строгой типизации какой? - СлабаяЛасковая типизация :)
"Попустительская"
Ну в python например утиная.
> Ну в python например утиная.Утиность ортогональна силе. В python сильная динамическая.
Так и не понял, в чем проблема строгой типизации, кроме лени разрабов, других причин пока не увидел.
> Так и не понял, в чем проблема строгой типизации, кроме лени разрабов, других причин пока не увидел.Если бы строгая типизация была бы на уровне самого языка, то понятно, а вот делать вид что типизация и потом компилить в не типизированный язык, - это костыль, еще одна не принудитильная абстракция, которая в конечом результате попадает в браузеры как не типизированнйы код
Простыми словами - ананизм, подмена реального процесса фикцией
Я не против пользы типизации, но не проще ли тогда уже писать на настоящем языке, который от рождения типизирован и компилить в тот же WASM понимаемый браузерами, - и волки и овцы (типизация и скорость) целы и сыты вместо того чтоб овцам прикидываться волками
> компилить в тот же WASMВеб-приложения, активно взаимодействующие с DOM, будут тормозить в WASM-варианте. That's right, ты не ослышался: JavaScript работает существенно быстрее WASM, если требуется активно работать с DOM.
Как там сейчас не знаю, а пару лет назад читал, что да, васм, чтобы использовать DOM, пока еще дергает яваскрипт ибо своего механизма не имел. В таком случае конечно будет тормозить. Но там в планах было реализовать прямое обращение к DOM, без JS-прокси. Вот когда реализуют - тогда заживем. Но там много чего еще было в планах.
А там до сих пор все так же...
> ты не ослышался: JavaScript работает существенно быстрее WASM, если требуется
> активно работать с DOM.А зачем в веб-морде а.к.а ЮаЙ, активно работать?
Люди(способность человеческой реакции) способны фиксировать что-то быстрее чем 25 кадров в секунду ?
Там речь об оверхеде по полсекунды при обращении к DOM. Реально, даже кожаный мешок заметит
> Там речь об оверхеде по полсекунды при обращении к DOM. Реально, даже
> кожаный мешок заметитПо сравнению с нынешними даже банковскими сайтами, где все моргает, дергается по несколько секунд пока появится что-то - так пол секунды это просто ракета...
ВАСМ, не замена ЖС, и их все же можно скрестить, получив максимальную выгоду от обоих, как пример:
https://age-wasm.ey.r.appspot.com/
> Люди(способность человеческой реакции) способны фиксировать что-то быстрее чем 25 кадров в секунду ?Фиксировать и реагировать способны до 120 кадров точно. Выше хз, не проверял.
> Фиксировать и реагировать способны до 120 кадров точно. Выше хз, не проверял.Это вы про игрульки? так там вы видите больше строб-эффект...
Вообще это довольно конфюзная тема, не определившись, что все оперирют одинаковыми терминами и одинаково их понимают, то разговор об этом может уйти в очень далекие дебри.
Самый простой метод, - собрать мультивибратор с duty cycle 50% и подцепить к нему светодиод и начать накручивать частоту до тех пор пока переключения перестанут фиксироваться глазом-о-мозгом. Восприятие частоты обновления картинки глазом может быть очень высоким, но само видение, точнее восприятие мозгом - этом совсем другое. Именно поэтом в свое время даже запретили изпользовать эффект 25 кадра в рекламе, - т.к. на башку влиять можно "невидимо"
> Если бы строгая типизация была бы на уровне самого языка, то понятно, а вот делать вид что типизация и потом компилить в не типизированный язык, - это костыльПримерно ВСЕ современные языки это делают, включая С, С++, Расты, Хаскели и все прочие.
Какая разница во что оно там копилирует? Типы это разновидность документации кода, при грамотной реализации дающая кучу возможностей для автоматического анализа валидности и выявления ошибок.
Решение удивительное. Первый раз наверно вижу, когда большой проект с развитием переходит с типизированного обратно на динамический язык. Ломать не строить, как говорится. Это оказывается просто убрать все типы из кода, когда уже система отлажена, но вот в обратную сторону проставить типы это много времени работ.
Я понимаю использовать динамический язык, для небольших стартапов, где не выстрелило - выкинуть не жалко. В больших проектах в статически типизированных языках, ошибки найти сразу на этапе компиляции, что экономит много времени на отладку, и что невозможно на динамически типизированных языках.
> В больших проектах в статически типизированных языках...TypeScript - не язык, а прослойка между реальным языком и чуваком/чувихой, думающ(ий/ей) что они пишут на типизированном языке. Имитация. Анонизм.
Не, там есть позитив от типов, однозначно, но пока это не на уровне языка, а так, - в имитации, то сколько волка не корми, все равно как у ишака не вырастет. Вот когда ТайпСкрипт будет JIT-том в браузере/ноде, вот тогда его можно будет воспринимать как взрослого
> Если бы строгая типизация была бы на уровне самого языка, то понятно, а вот делать вид что типизация и потом компилить в не типизированный язык, - это костыль, еще одна не принудитильная абстракция, которая в конечом результате попадает в браузеры как не типизированнйы кодЭмм. Ну большинство языков компилятся в асм, который в конечом результате попадает на процессор как не типизированный код.
> Ну большинство языков компилятся в асм, который в конечом результате попадает на процессор как не типизированный код.Мы ехали, ехали и наконец приехали...
Копилится в основном не в асм, а в опкоды процессора, где вообще-то весь сыр-бор именно изза него, - процессора, где все привязанно к жестким типам.
Для справки:
https://cse.unl.edu/~goddard/Courses/CSCE351/IntelArchitectu...
Проблема в том, что смузи с сахарком вокруг типов оборачивается кучей тайпкастов и конверсий там, где их не надо. Это в лучшем случае. В худшем - необходимостью дублировать код под каждый тип, либо городить темплейты, но последнее не про жс.
так где не надо - там и не надо) если мы говорим про юзеринпут/парсеры/апи - надо, это понятно, а то в лучшем случае данные не зайдут, в худшем, если тип в бд не установлен, к примеру, может немаленькая такая часть системы отвалиться, если не вся сразу, и ищи потом кто-кудаа если мы говорим про внутреннюю логику, которая уже за этим барьером выше - там уже и не нужно, если кодить правильно
так какой правильный ответ?))
Правильный ответ - в заголовке новости.
Предлагаю вам залезть в их репу и почитать что на этот счёт пишет сам автор. Нужно быть всегда честными с самим собой тайпскрипт увеличивает сложность. А где сложность там и баги, вне зависимости от того есть там тайпскрипт или нет)
> Так и не понял, в чем проблема строгой типизации, кроме лени разрабов,
> других причин пока не увидел.Маловато опыта значит)
Представьте себе python код, который обрабатывает входной json десятком if. Т.е. там очень сильно что угодно может быть: строка, массив, объект, массив объектов, объект, набитый объектами, в которых могут быть массивы. А теперь представьте как я переписываю это на Go с сильной статической типизацией. Мне нужен тип под каждый частный случай, сможете посчитать сколько именно типов мне нужно?) Конечно благодаря композиции и хитрому анмаршалингу я могу свести кучу частных случаев к общим, но постоянно думаю о том, что лучше бы писал это на node.js 😄
p.s. оно так приходит с фронта, и это бизнес-логика, на данном этапе её не поменять
p.p.s. я знаю, что можно как быдло-кодеру всё бросить в вонючую нетипизировонную яму, но мне нужно работать с полями, так что отказ от нормальных типов лишь отсрочит боль, но в общем, её станет больше, оно того не стоит
Ну так надо сразу делать нормально, а не вываливать данные как попало, расчитывая что на той стороне как-нибудь разберутся.
> Ну так надо сразу делать нормально, а не вываливать данные как попало,
> расчитывая что на той стороне как-нибудь разберутся.Дык это сложно: нужно поддерживать совместимость. А так никто не знает, что завтра будет в ответе.
> Представьте себе python код, который обрабатывает входной json десятком if. Т.е. там очень сильно что угодно может быть: строка, массив, объект, массив объектов, объект, набитый объектами, в которых могут быть массивы.У нормальных АПИ есть схема ответа и из схемы можно сгенерить типы. В том же питоне популярен pedantic из-за возможности проверки.
> конечно благодаря композиции и хитрому анмаршалингу я могу свести кучу частных случаев к общим, но постоянно думаю о том, что лучше бы писал это на node.js
Просто тебе нужен не JSON, а protobuf или другой формат.
Абсолютно поддерживаю. Язык изначально слабо типизирован, и все эти костыли для студентов первого курса - костылями и останутся.В PHP отряды смузи вот тоже пытаются типизацию навесить, им сложно видите ли иначе, в зачатках разума логика не умещается. Всё это приводит только к раздуванию кода бессмыслицей и снижению производительности.
Все там хорошо с типами! Более того, прошли времена, когда все эти новомодные фреймворки могли что-то ускорить или улучшить, даже тот же jQuery уже не нужен, ванильный чистый JavaScript можно удобно и комфортно все что тебе надо и при том работает без тормозов, в отличии от ваших тубо.
Технология турбо поправде крутая, и очень отзывчивая. Вы не правы.
>Все там хорошо с типами!да непонятно вообще что за проблема с типами такая))) если нужно что-то конкретное для бд или продакшена какого - объявляй и чек/конверт на инпут вешай классом, делов-то. а не где неважно - там неважно. у них там, по ходу, нигде ничего такого нет - вот и топят.
>Более того, прошли времена, когда все эти новомодные фреймворки могли что-то ускорить или улучшить, даже тот же jQuery уже не нужен, ванильный чистый JavaScript можно удобно и комфортно все что тебе надо и при том работает без тормозов, в отличии от ваших тубо.
ну когда осваиваешь язык и приёмы на уровне выше группы разрабов фреймворка - тогда да, но раньше - не всегда. а если ты гуру от бога - можно чей и вообще своей язык накатать, что все ахнут)))
PHP вообще следовало бы остановиться на 4 версии по синтаксису, и допиливать только то, что под капотом для ускорения и латания безопасности. Сейчас пыха уже сложнее чем java, а популярность падает с каждым годом.
Вот это нужно в рамку и на стену повесить:> избавляет разработчиков от выкрутасов с типами,
> производимых для удовлетворения капризов компилятора
У автора этой формулировки явно припекает от любых попыток навести в коде порядок с типами.
> В качестве причины прекращения использования TypeScript упоминается то, что этот язык мешает автору при разработке и делает трудными вещи, которые должны быть простыми. Недовольство касается не только наличия дополнительной стадии компиляции TypeScript, но и того, что данный язык загрязняет код "гимнастикой с типами".
> Компания 37signals, которая курирует разработку проекта, полностью перешла на использование чистого JavaScript в клиентском коде и внутренних библиотеках. Использование чистого JavaScript не только значительно улучшает читаемость кода, но и избавляет разработчиков от выкрутасов с типами, производимых для удовлетворения капризов компилятора TypeScript.Люто поддерживаю. TypeScript нужен далеко не всегда. Лично наблюдал как в последние 5 лет использование TS становилось не то карго-культом, не то сектой.
В какие средние и большие проекты ты бы не стал брать тайпскрипт и почему?
так вроде же можно так же описать классы на жс и использовать их, в чём конкретно преимущество тс?я вот свой проект вылизал, вроде бы, на пыхе, смотрю теперь в сторону динамического обновления, подтягиваний и тп, но чёт ничего убедительного не нахожу в использовании подобного - на жс же можно всё сделать, через те же сокеты, библиотеками всякими для начала и тп - зачем всякие *скрипты, аяксы, джейквери и тп тащить?
видимо надоело ждать, пока вебпак соберёт
> При использовании Turbo логика работы приложения не размазывается по фронтэнду и бэкенду, а определяется только на сервере с использованием языка программирования, наиболее удобного для разработчика. Браузер же занимается только обработкой готового HTML.Упс. Э... Не понял ... В браузере не нужно будет включать этот дурацкий JS ? Возврат к началу WEBa.
Просто он автогонщик, а не программист.
Меня этот внезапный всплеск интереса к строгой типизации немного удивил. Вдруг его скакой-то стати стали тащить и в питон, и в php, и в JS, вынуждая разработчиков заниматься лишней рутиной. Всеми этими оптимизациями должен заниматься компилятор сам. В эпоху, когда вот-вот можно будет писать программы на естественном языке, эти шаги назад выглядят странно.
В строгой типизации нет ничего плохого, особенно там где она опциональна. Это в перспективе даёт возможность конвертации в что-нибудь типа Си и запуска на стиральной машине. Например в PHP типизация сделана очень грамотно и ты сам без каких либо проблем можешь решать использовать её или нет. Чего к сожалению не скажешь про JS, тайпскрипт там это сейчас культ, хотя и законченному идиоту понятно - это приводит к бойлерплейт коду, раздуванию проекта, куче @ts-error-ignore, красным подчёркиваниям потому что тип ещё не добавили т.к. апи новое и прочее и прочее. Ts - рак на планете и надо от него избавляться. кто поумнее - уже давно понял это. Браузеры не про это, они про чистый Js.
> Например в PHP типизация сделана очень грамотно и ты сам без каких либо проблем можешь решать использовать её или нет.+
> в PHP типизация сделана очень грамотноУгу. Особенно при отсутствии оверлоуда.
Прежде чем делать попытку в строгую типизацию - надо механику обеспечить.
Оверлоуд, темплейты. Короче сделать из пыха плюсы, но зачем, они уже есть.
А иначе это унылый костыль для недоглядов. К тому же производительность сажающий в хлам.
на плюсах сразу вебприложухи писать начинающим стартаперам?)
Интересно, а как работают автоматические рефакторинги/исправление для динамического javascript? Мне интересно. Если они и есть, то инструменту всё равно нужно выводить типы. И гораздо проще искать проблемы в коде, когда мы точно знаем что функция принимает. А так функция может принимать и строку, и число, и массив, и объект с неизвестными полями, какую информацию может извлечь инструмент из этого? Никакую.
Вообще то остановить прогу и глянуть какой тип это просто.И вообще строгая типизация это как раз для кода а не человнка, так код будет работать быстрее.
Он сразу выделит нужную память.
Для компилируемых языков верно.
С JIT всё сложно.
А в интерпретаторах и псевдокоде - сводится к дополнительной проверке типа в вызовах. В итоге код работает совершенно не быстрее.
> Вдруг его скакой-то стати стали тащить и в питонВ питоне нет и не тащат строгую типизацию. В Питоне АННОТАЦИИ, это совсем другое
Я в курсе, питону при исполнении кода они пoфиr, но суть та же, эта лишняя возня и зacиpaниe кода вдруг стало популярно и это стали тащить в проекты.
Моё почтение, у него стальные яйца. Тайпскрипт не даёт выигрыш в качестве кода. А вот штат разработчиков гарантированно увеличит
> Тайпскрипт не даёт выигрыш в качестве кода.Именно. У хорошего _внимательного_ разраба, который не пялится одним глазом в ютубчик, редко бывают детские ошибки с [object Object]. А если бывают, то мгновенно отлавливаются при тестировании.
Но нет - из-за 95% кривоглазов изволь нагромождать кода в несколько раз больше. А кривоглазы тем временем косячат другими способами.
Однажды обратил внимание как джуны делаю задачу. Берет функцию/компонент и методом научного тыка подбирает параметры. Благодаря js это сделать очень просто. Вот только на ревью это хорошо видно. Как котенку указав на ка..ашку через какое то время такая привычка пропадает. А вот на тайпскрипте будет красивая ка..ашка которую так просто не распознаешь.
Он дает выигрышь в зарплате.
За место одного правильного с большой зп и который может уйти заболеть. Можно нанять троих с зарплатой в 3 раза меньше и пугать их что одного скоро сократят и у нас очередь за забором.
Одного не заменить на троих, такой вот парадокс. А вот где 3 на одну лампочку там и появляется бюрократия где можно без нее
Увы в реальной жизни наоборот.
Читал давно историю, как девушке отказали в повышении ЗП, а после её ухода наняли троих на те же обязанности. Правда, это было не в айти, и должности её не знаю
Никогда не использовал турбо, но любое изменение с .ts на .js — это большое изменение, потому что теперь ни у кого нет возможности притворяться, что TypeScript — это что-то хорошее.
Типы должны быть в самом JS. Сделали директиву use strict — можно сделать и use typed. Сразу производительность подскочит, целый пласт обработок из интерпретатора можно будет выбросить.
Есть JSDoc, удобная штука. А TS имеет смысл возможно только в очень крупных проектах с тоннами кода...
Есть такой proposal https://github.com/tc39/proposal-type-annotationsПравда там вроде js просто игнорит типы, а проверка возлагается на отдельные утилиты (как typescript). Примерно как аннотации в питоне
По моему, лучше бы Dart взяли, это сейчас самый лаконичный язык для веба.
Его для веба вообще кто-то использует? Кроме как для flutter его нигде нет.
Ох уже эти пляски с фреймворками… Фреймворк на фреймворке сидит и фреймворком погоняет… Я вчера несколько часов потратил на поиск ошибки в системе, которую пилим на Vue. Проблема, как оказалось, в том, что у вьюшного reactive с Array-евским filter не было глубокого человеческого взаимопонимания. Простите за нытьё )
А как ты добился, что тебе нужна реактивность при использовании filter?
Еще один не смог ослилить типы. При этом стоит учесть, что в typescript достаточно гибок в этом плане.
Еще один плавает без типов.
Давно уже пора принять TS в качестве очередного стандарта ecmascript и внедрить в браузеры. Меньше будет оберток вокруг оберток, и если людям так уж хочется писать на скриптовых языках, так хоть пусть они будут типизированные.
Но наверное гугл с майкрософтом никак договориться не могут, у гугла же вроде свой язык какой-то был, dart?
Чем вам Java не зашла?
Просто пора уже реализовать нативное выполнение TS как в браузерах, так и на сервере, а не компилить в JS, и забыть JS как страшный сон.
Вокруг столько типизированных языков, зачем вы приперлись обсирать javascript?