Рациональный взгляд на ваш путь разработчика впереди

Введение

Это моя мысленная карта JavaScript, TypeScript и будущих языков современной сети.

Не задуман как пламенная война, вдохновленная Thunderdome, менталитет «Мой папа может побить твоего отца», приходите с вилами и факелом или поделитесь в диалоге, пока вы размышляете о своем собственном путешествии вперед.

Дао программирования

Почти все в технологиях горько-сладко — это инь и янь жизни. Нет какой-то единой технологии, которую бы я полностью любил.

Для каждой технологии я обнаруживаю схожие закономерности: во-первых, волнение от попыток попробовать что-то новое. Это объятие частей, которые вы хотите исследовать, не обращая внимания на проблемы. Затем срабатывает правило 80/20, когда вы заходите в повороты.

Вы неизбежно найдете хорошие и плохие стороны — затем взвесьте их на своих личных весах, чтобы оценить свое мнение.

Мои желания ненасытны — от языков до операционных систем, баз данных, облачных сервисов, программного обеспечения… нет ничего идеального. Даже найти идеальное приложение для заметок или задач кажется невозможным, что странно, поскольку приложения для задач стали Hello, World компьютерных наук.

Страсть программиста

Лично я люблю людей, которые увлечены тем, что они делают, и принимают их самовыражение. Независимо от того, за или против, отношение отражает качество интервальных значений и обязательств.

При определении технологических дорожных карт трудно игнорировать сильные полярные мнения. Фактор «любви» или «ненависти» может быть убедительным, но не полностью репрезентативным для коллектива.

Иногда шокирует одиночный шум, вызывающий рефлекторную реакцию: «Ой, подождите, может быть, я ошибаюсь».

Если вы задаете вопросы, а не высказываете разрозненные мнения, вы все делаете правильно.

Иконы технологий

Когда говорят лидеры и новаторы, их усиленные голоса звучат громко, например, мнение Линуса Торвальдса о C++.

Не буду врать — во мне есть немного Линуса Торвальдса. Бывают случаи, когда четкие, прямые реализации приводят к быстрому успеху. В других случаях я ловил себя на том, что увлекаюсь особенностями языка. Вопрос о том, было ли это пустой тратой времени, спорный.

Этот аргумент Линуса можно применять и использовать с разных точек зрения:

Это становится еще более ужасным из-за того, что многие нестандартные программисты используют его до такой степени, что с его помощью гораздо проще генерировать полную и абсолютную чушь.

…даже если бы выбор C состоял в том, чтобы *ничего* не делать, но отпугивать программистов C++, это само по себе было бы серьезной причиной для использования C

C++ приводит к очень плохому выбору дизайна. Вы неизменно начинаете использовать «хорошие» библиотечные функции языка, такие как STL и Boost, и другую полную и полнейшую чушь, которая может «помогать» вам программировать, но вызывает:

- бесконечное количество боли, когда они не работают (и любой, кто говорит мне, что STL и особенно Boost стабильны и переносимы, настолько полны чуши, что это даже не смешно)

- неэффективные абстрактные модели программирования, когда два года спустя вы замечаете, что какая-то абстракция была не очень эффективной, но теперь весь ваш код зависит от всех хороших объектных моделей вокруг него, и вы не можете исправить это, не переписав свое приложение.

Существует множество технических шокирующих спортсменов, запугивающих кликбейт.

Происхождение языков

Почти все технологии, и особенно языки, начинаются с малого и имеют четкую цель. Они часто исходят из научных кругов; или, конкретные корпоративные потребности.

На самом деле удивительно, как много технологий проистекает из видения одного человека.

  • C: Деннис Ричи
  • C++: Бьерн Страуструп
  • Ява: Джеймс Гослинг
  • Python: Гвидо ван Россум
  • Руби: Юкихиро Мацумото
  • R: Роберт Джентльмен и Росс Ихака
  • Ржавчина: Грейдон Хоар
  • PHP: Расмус Лердорф
  • Перл: Ларри Уолл
  • Лисп: Джон Маккарти
  • Паскаль: Никлаус Вирт
  • JavaScript: Брендан Эйх

В концепции есть прекрасная элегантность — простота и цель.

По мере того, как растет внедрение, больший спрос и расширение сталкиваются с ограничениями и обратной совместимостью.

Это давление тормозит, тормозит инновации, останавливает или создает трещины, которые разветвляют пути. Недавним примером этого является заявление Гвидо ван Россума о том, что Python 4.0 может никогда не появиться; хотя, скорее, родится заново как нечто иное.

С другой стороны, это давление может привести к более качественной спецификации за счет стандартов и сотрудничества с сообществом.

Мое путешествие

Лично мой путь начинается с создания кросс-платформенных настольных приложений на C и C++; затем переходим к мобильной и веб-разработке.

Честно говоря, сначала я не мог серьезно относиться к JavaScript. Казалось, что-то вроде того, что можно было бы использовать для включения кода <blink />. Он был ограничен — оболочка или подмножество языка, работающие на экспоненциально медленных скоростях.

Его динамичный характер беспокоил меня, как и его цепь-прототип.

Даже в веб-разработке это, казалось, вызывало конфликт между декларативной семантической структурой html, несвязанным стилем css и программным соблюдением мнений чистого JavaScript.

Казалось ироничным, что цепочки инструментов вращались вокруг этапов компиляции/сборки того, что на самом деле было интерпретируемым кодом.

В свое время я видел, как многие технологии увядали и умирали.

Путешествие JavaScript

Кажется, первая проблема с JavaScript заключается в том, что его текущее использование никогда не предполагалось; и не смогли адаптироваться с течением времени.

Решения вращаются вокруг более мощных движков, интерпретаторов, IDE и наборов инструментов. Хотя язык, безусловно, развивается, кажется, что что-то осталось от желаний сообщества.

Во-вторых, его доминирование неуклонно — помимо требований Интернета, его кросс-платформенные возможности и открытые стандарты делают его предпочтительным решением.

Apple будет продвигать Swift/Metal, Microsoft будет продвигать .NET/DirectX, Google хочет, чтобы браузер был операционной системой, а Linux, как правило, остается позади.

Даже внутри «приложений» часто бывают просто оболочки веб-решений… и это имеет смысл. Существует богатый и надежный уровень представления пользовательского интерфейса с универсально стандартизированным интерфейсом.

Бэкэнды на основе узлов создают экосистемы JavaScript с полным стеком, которые становятся более доминирующими за счет устранения архитектур плагинов на разных языках.

Путешествие плагина

Не будем забывать, что эра плагинов действительно была ужасной, но, как я указывал выше, она позволяла использовать альтернативные языковые стратегии.

Java-апплеты позволили разработчикам Java встраивать внешний интерфейс в веб-страницы, которые изначально могли взаимодействовать с внутренними серверами, выполняющими код Java.

Аналогичным образом Microsoft Silverlight предоставила разработчикам полные комплексные стеки C# и общий код.

Объекты Microsoft ActiveX расширяют возможности чрезвычайно высокой производительности, такие как средства просмотра 3D-моделей, конференции и решения для совместной работы (хотя и только для Windows) с C++.

Хотя трудно представить, Macromedia (Adobe) Flash была королем для видео с плагином Flash Player и потоковыми внутренними службами ColdFusion и медиасерверов. В то время все, что вы смотрели на YouTube, было Flash. Затем появился Стив Джобс, убивший конкурентов в видеопрезентации, для просмотра которой в прямом эфире требовался плагин QuickTime.

Это были темные, туманные, проприетарные и потенциально вредоносные дни управления плагинами и уязвимостей безопасности, которые в конечном итоге превратились в кошмары вампиров, высасывающих батарею.

Но дело здесь в том, что устранение альтернативных языков в экосистеме браузера привело к сквозным разветвлениям — волновому эффекту для всех технологических стеков.

Я уверен, что появилась бы и безголовая платформа Node, но, возможно, ее обострили из-за необходимости переноса сущностей VO/DTO между слоями JavaScript.

По мере трансформации серверных систем меняются и соответствующие системы, такие как динамические базы данных документов и облачные системы на базе лямбда-выражений.

Путь TypeScript

Для меня TypeScript кажется тем, чем сообщество разработчиков хотело бы видеть JavaScript.

Если бы ECMAScript развивался по-другому, TypeScript может и не быть.

Или TypeScript может стать бесполезным, если он будет поддерживать стандарты ECMAScript, охватывающие его языковые конструкции.

Возможно, это временная мера — идеальный полифилл.

Между ними существует дихотомия — то, что JavaScript — это динамический язык, кажется вечным конфликтом. На самом деле я думаю об этом больше как об основе среды выполнения, которая поддерживает динамические возможности, но может придерживаться более строгой типизации во время компиляции за счет использования наборов инструментов.

Одна вещь, которую я глубоко уважаю в TypeScript, — это признание того, что он есть, может и не будет делать.

Сахар

Некоторые из этих рассуждений кажутся синтаксическим сахаром — вещи, которые на самом деле эквивалентны. Пространства имен в сравнении с модулями, или общедоступные/частные модификаторы доступа в сравнении с экспортом, или хэш-имена полей частного экземпляра JavaScript (#).

Даже аннотации JSDoc выполняют аналогичную проверку типов.

Еще одна жаркая дискуссия — это классы или объектно-ориентированное программирование против функционального программирования, в которых часто указывается аргумент, что в JavaScript нет классов. Это правда, поскольку это язык, основанный на прототипах.

Часть паттерна классов в JavaScript является синтаксическим сахаром для псевдоклассических паттернов наследования, но я нахожу этот аспект интересным, поскольку он применим к тому, как в конечном итоге выполняется код. Это не обязательно преобразования кода, но они могут быть реализованы непосредственно в прототипе, хотя Руководства по стилю Airbnb считают это плохой практикой.

Транспиляция

Эта косвенность является основным фактором во многих дискуссиях.

Все проблемы в информатике могут быть решены на другом уровне косвенности.
– Дэвид Уилер

Языки более высокого уровня сильно абстрагируются — даже JavaScript проходит несколько этапов:

  • Сборка (Webpack/Babel) для слияния кода
  • Модули:
    - CJS: CommonJS
    - AMD: определение асинхронного модуля
    - UMD: определение универсального модуля
    - ESM: модули ES
  • Полифиллы
  • Минификация
  • Исходные карты
  • JIT: своевременная компиляция
  • VM: Внутреннее устройство виртуальной машины, например V8 Engine.

Нет никакого сравнения с такими языками, как C, где вы почти в одном шаге от ассемблера. Даже внутри C и C++ есть этап генерации кода перед компилятором, на котором происходят оптимизации и перезаписи.

Одна вещь, которую я всегда считал крутой, — это возможность обойти компилятор, когда это необходимо для вставки встроенной сборки:

uint64_t msr;

asm volatile ( "rdtsc\n\t"
               "shl $32, %%rdx\n\t"
               "or %%rdx, %0"
               : "=a" (msr)
               : 
               : "rdx");

printf("msr: %llx\n", msr);

Должны ли вы это сделать? Конечно нет, но есть конкретные случаи, когда это может иметь смысл. Я видел экспоненциальное увеличение производительности, когда узкие места были изолированы, а оптимизированная сборка внедрялась. Но дело в том, что у вас есть на это право.

Поскольку TypeScript основан на JavaScript, существует аналогичная возможность, позволяющая разрешать Any или просто игнорировать директивы @ts-ignore. Но при этом создается впечатление, что вы обходите цель использования TypeScript.

Хотя вы можете полагаться на исходные карты, JavaScript ближе к истине.

Открытие инспектора браузера и вставка кода JavaScript в консоль может стать большой победой.

Трудно принять компоненты, которые испаряются после компиляции. Интерфейсы, например. Они настолько эффективны в C#, но исчезают во время выполнения в TypeScript, поскольку JavaScript не имеет представления об этих конструкциях. Они не могут быть напечатаны проверено или преобразованы таким же образом, прибегая к утиному печатанию.

Учитывая это, у меня есть оговорки, что транспиляция является окончательным решением. Возможно, это становится более спорным в промежуточных формах, таких как виртуальные машины низкого уровня (LLVM).

Инклюзивность

В то время как TypeScript обеспечивает совместимость с пакетами на основе JavaScript через DefinitelyTyped, он кажется немного тупым и бессвязным.

Вывод TypeScript:

  • Объявления TypeScript, или d.ts, файлы, используемые в проектах TypeScript.
  • JavaScript, используемый в проектах JavaScript и выполняемый в браузере

Конечно, вывод JavaScript, ну… остается JavaScript и не может волшебным образом облегчить типы TypeScript.

Что мне не нравится в этом, так это кажущееся давление, направленное на содействие обоим сообществам. Мои модули JavaScript должны включать TypeScript, что, на мой взгляд, кажется отсталым.

Есть также ресурсы сообщества, такие как плагины Babel. Я не всегда чувствую, что TypeScript поддерживает открытость, которая исторически Microsoft часто представляет уникальные способы ведения бизнеса. По правде говоря, это может быть хорошо, но я ощущаю контроль над направлением.

У Microsoft была интересная стратегия: MSIL, или Microsoft Intermediate Language. Это позволило разработчикам разных языков сотрудничать вместе, используя свои собственные языки. C#, F# или даже VB могут использовать одни и те же библиотеки через метаданные в сборке, в конечном итоге работая вместе и вызывая одни и те же API на соответствующих языках.

Собственность и управление

Как упоминалось ранее в разделе Происхождение языков этой статьи, владение или власть через организации по сравнению с частным бизнесом может быть благословением или проклятием.

Можно утверждать, что более эффективное управление открытыми стандартами через ECMA является конкурентоспособным и приспособленным к множеству учреждений.

Или можно возразить, что действия, направленные на ускорение, четкая направленность и видение контролируются одной бизнес-структурой, такой как Microsoft. Это был бы более сильный аргумент, если бы TypeScript не приходилось полагаться на JavaScript.

В любом случае, откровенно говоря, оба могут потерпеть неудачу.

Microsoft, один из первых пионеров, существует уже некоторое время и является легкой мишенью, когда указывает на устаревшие технологии, от которых они отказались. Несмотря на то, что Майкрософт прекратила поддержку нескольких сотен вещей, некоторые из них наносят больший ущерб, чем другие, например, прекращение поддержки игровой платформы XNA.

В то время как Microsoft стремится оставаться обратно совместимым, почти шокирует то, как они спотыкаются и терпят неудачу даже с явными выигрышными преимуществами. Их технологические пути колеблются из-за нерешительности, когда они находят опору.

Тем не менее, Microsoft также добилась больших успехов в области открытого исходного кода с такими вещами, как компилятор Roslyn, использующий кроссплатформенность .NET.

Но все платформы имеют ограничения, они используют проприетарные API для усиления контроля. У Apple полное дерьмо, она быстро меняет целые системы, не обращая внимания на разработчиков — Carbon на Cocoa, Objective-C на Swift. Linux часто калечится лицензионными соглашениями, терроризируется собственной красотой.

Справедливо утверждать, что TypeScript с большей вероятностью растворится, чем JavaScript, тем более что его доминирование теперь влияет на стандарты ECMA. Он может действительно стать спорным, поместив себя в стандарт.

Хотя я действительно считаю маловероятным, что JavaScript исчезнет, ​​не верьте, что в технологиях есть что-то вечное.

И хотя я не ожидаю, что Microsoft обанкротится, гиганты все же рухнут — помните, Apple была на грани банкротства в 1997 году, почти рухнула. Теперь одна из самых дорогих компаний в мире. Но если бы это случилось с Microsoft, я уверен, что фонд принял бы и возглавил TypeScript.

Церемония

Некоторые утверждают, что шаблоны, настройка и командная работа являются движущими силами в пользу или против TypeScript. Иногда достаточно просто включить компьютер и найти мощную мышь, не говоря уже о концентрации и вдохновении, чтобы задействовать ее с максимальным потенциалом.

Почти все решения требуют некоторой настройки и шаблонов, которые часто создаются автоматически или доступны в виде шаблонов. Даже один HTML-файл имеет некоторую степень шаблонности, и те, кто часто создает в этом пространстве, могут копировать и вставлять любой уровень сложности.

Конечно, я признаю элегантность таких простых вещей, как CodePens. Но это может быстро измениться, когда вам придется выбирать между тысячью строковыми файлами или созданием шаблонов загрузки нескольких файлов. Когда вы обнаружите, что у вас возникают противоречия между тем, чтобы делать что-то правильно, или сохранением шаблона, это признак того, что что-то может быть неправильным.

Будь то личная или командная работа, никто никогда не должен использовать ярлыки. Всегда делайте все правильно. Церемония гордости — вы никогда не должны выбирать работу низкого качества, кроме как в случае крайней необходимости, такой как маркетинговое агентство с превышением бюджета и просроченной доставкой на живом съезде. Это только в таких ситуациях, когда работа не может быть улучшена задним числом позже.

Компетенция

Вот где чувства задевают, и они действительно не должны.

Было время, когда компьютерное программирование было сложным, дорогим и требовало огромных технических способностей. Стоимость доступа к компьютерам и средам разработки была угнетающей — для многих это было хлопаньем дверей, и это сдерживало поле.

В то время как некоторые могли бы оценить те дни, современное общество имеет большой спрос на технический рост и, следовательно, на разработчиков.

JavaScript очень привлекателен для новых программистов. Его использование бесплатно, и многие наборы инструментов совершенно бесплатны. IDE, такие как Visual Studio Code, бесплатны, а онлайн-ресурсы, такие как CodePen или CodeSandbox, предлагают впечатляющие возможности прямо в браузере.

Лично я не считаю JavaScript второстепенной областью — существуют невероятные возможности, движущие современным обществом, с чрезвычайно полезным опытом для конечных пользователей, переносимым на любую платформу или устройство.

Когда технология предлагает расширенный набор возможностей, легко занять позицию превосходства. И когда эти способности недооцениваются, легко принизить их непонимание.

Между JavaScript и TypeScript существует явное единство, в котором оба языка выигрывают от схожих шаблонов проектирования.

Важно отделить мнение от возможностей — почему, когда в разговорах обсуждаются следует и может. Это дорога с двусторонним движением.

Поймите, для кого это: Вы, разработчик.

Вы и ваша команда являетесь бенефициарами обсуждения. Эти действия предназначены только для вас в вашей разработке и лишь косвенно влияют на конечного пользователя.

Никогда не останавливайтесь в своем личном путешествии — дорога простирается перед вами навсегда, маня вас дальше. Вы всегда будете негативно относиться к своему прошлому, как и должно быть. Это означает, что вы продвинулись вперед, приобрели новые навыки и компетенции.

предпочтение

Я не люблю бананы. Иногда они в порядке, например, когда вы больны. Они на вкус такие же, как когда их вырвало обратно. На самом деле, однажды я нашел варенье из бананового творога, которое было восхитительным, но оно было снято с производства из-за отсутствия интереса.

Это нормально, что-то нравится или не нравится, и вам не нужно оправдывать свое личное мнение. Вы можете любить зеленый цвет, жить в городе или носить шляпу.

Имеет смысл только то, что конкретный язык или его аспекты будут привлекательными. То же самое в цепочках инструментов и целых технологических экосистемах. В идеале вы можете окружить себя своими увлечениями.

Иногда мы жертвуем, чтобы иметь то, что хотим. Вернемся к началу этой истории — взвешиванию хорошего и плохого на весах. Не существует единственной идеальной вещи. Если бы он был, все бы его использовали.

Несмотря на предпочтения, помните, что все в жизни можно измерить.

Знайте, что вы получаете и теряете с каждой сделкой.

Ваше путешествие

Если вы похожи на меня, вам нужен простой ответ: «Сделай это».

Кажется, что эти полярные мнения облегчают жизнь, но на самом деле полярные крайности — легкая мишень. Сила часто находится посередине.

Вот четыре ответа, которые я считаю правильными:

Стоит ли вам использовать TypeScript?

Да, это невероятно круто и мощно. Существуют гарантированные преимущества проверки во время компиляции, и они измеримы. Это не решит всех проблем и, как и все, может создать новые. Это стоит объятий. Даже в худшем случае, если он устареет, перенос обратно на JavaScript не будет таким монументальным, как некоторые предполагают; и, скорее всего, вы перенесете что-то новое.

Следует ли вам использовать JavaScript?

Да, это также невероятно круто и мощно. Возможно, вы отказываетесь от потенциальной выгоды, но ваша чистота по отношению к виртуальной машине и элегантность простоты понятны и уважаемы. ECMAScript будет развиваться, а значит, и ваша кодовая база.

Стоит ли использовать оба варианта?

Да, выберите правильный инструмент для работы, но только если вы уверены, что два приведенных выше ответа действительно «да». Никогда не занимайте позицию упрощения или унижения чего-либо, применяя меньше, когда вы недооцениваете.

Не следует ли использовать ни то, ни другое?

Да — и по двум причинам, обе волнующие. Вот где я сейчас нахожусь.

Во-первых, я думаю, что единственный путь к тому, чтобы сделать браузер эквивалентным операционной системе, лежит через WebAssembly — машинный/ассемблерный/байтовый код.

Я знаю, что это широко обсуждается, но этот путь может привести к огромному успеху.

WebAssembly обеспечивает невероятную производительность, расширенные возможности, запутывает проприетарный код и воссоединяет языки программирования.

Представьте себе, что программисты со всех языков вносят свой вклад в Интернет — от Cs до Java, от Python до Go или даже TypeScript — как первоклассные граждане.

Представьте, какими были бы операционные системы, если бы они ограничивались только одним языком. В определенном смысле это так, но существует богатая и разнообразная экосистема технологий, выходящая за рамки стандартных поощрений.

Во-вторых, осознайте, что ваш потенциал может быть в другом месте.

Если вы читаете это, ненавидите TypeScript и классы, возможно, в вас есть немного Линуса Торвальдса. Возможно, ваш путь лежит к C или функциональному программированию на Haskell, Erlang, Elixir или F#. Может быть, ваша настоящая страсть ждет.

Если вы читаете это и думаете: Мне не хватает TypeScript, возможно, ваш путь — это C# с использованием таких технологий, как Unity, для иммерсивного опыта. Усовершенствованные конструкции языков, таких как C#, могут быть очень удобными. Возможно, ваша настоящая страсть существует в совершенно новых возможностях.

Заключение

Я никогда не забуду свой первый вопрос на профессиональном собеседовании: «Как вы относитесь к переменам?»

Технологии плывут по зыбучим пескам, воплощая непостоянство жизни. Даже работа каменотеса разрушается от ветров, все в конечном счете теряется в медленной тепловой смерти Вселенной.

Чтобы преуспеть в технологиях, требуется определенный тип личности. У меня была своя доля моментов Питера Гиббонса, когда я думал о том, чтобы принести свой обед в палитру. Но меня волнует прогресс, безграничное стремление решить любую проблему — даже такую, что в конце времен мы находим дверь в другую вселенную, когда наша заканчивается.

Возможно, программисты на языке COBOL смеются последними, хорошо оплачиваемые в вечном пузыре стареющих финансовых и ядерных систем.

Если бы я высказал свое мнение, я бы связал JavaScript с C — фундаментом под песком, его основные возможности стабильны и легко переносимы, хотя в конечном итоге он может не стать наиболее широко используемым языком в будущем.