Приложения в Интернете… это беспорядок, давайте будем честными.

Но чтобы понять почему, нам сначала нужно вернуться назад. Путь назад…

Возьми меня за руку, я собираюсь взять тебя в путешествие

Было время, когда Интернет был простым ...

Зеленый (мачо, чистый, # 00FF00) шрифт на темном громоздком мониторе. Некоторые сообщения чата IRC прокручиваются вверх. Необычная скорость Интернета 56 Кбит / с для богатых. Вы знаете, как обычно.

Однако это было примерно в 1993 году, когда у W3C родился ребенок, который навсегда все изменил. На самом деле, это было задолго до этого, в 1989 году, Тим Бернерс-Ли из ЦЕРНа первым предложил идею, и каким-то образом, четыре года спустя W3C забеременела (честно говоря, вы не хотите знать, как, давайте просто скажем, что они были в очень странных вещах). Как бы то ни было, они продолжали называть этого парня «языком гипертекстовой разметки». Но это было непросто, поэтому все крутые парни из гетто называли это «HTML».

Отличный ребенок, умел на все. Но на самом деле его основная игра заключалась в отображении данных на экране. Между прочим, данные семантически структурированы и могут очень легко связать какое-то конкретное слово с какой-то страницы с другой, совершенно другой страницей, посвященной этому конкретному слову. Один щелчок - и вы там. Горячая чертовски! Если мир когда-либо видел такое, это был сдвиг парадигмы прямо здесь. Особенно в то время, когда люди использовали энциклопедии на 500 страниц и 60 томов, чтобы узнать о чем-то.

Но ... честно говоря, те первые веб-страницы были уродливыми. Типа, действительно некрасиво. Мол, пожалуйста, замри-меня-и-держи-там до 1996 года некрасиво.

Возраст радуг

Ребята, это 1996 год, разморозитесь, волшебство творится. Каскадные таблицы стилей (или CSS, если вы из гетто) вошли в веб-стандарты, и с их помощью вы могли взять все данные HTML-страницы и сделать их чистыми.

Типа, настоящий чистый. Как много ...

Видите все эти планеты, цвета, звезды и все такое? Это великолепный CSS, ребята. На самом деле он все еще жив, безупречен и горд на spacejam.com, без шуток. :П

Так что CSS был крутым и все такое. Вы могли делать всевозможные визуальные элементы, стилизовать кнопки, перемещать объекты, делать страницу великолепной, анимированной, вызывающей приступы радуги цветов ... Но довольно скоро люди поняли, что чего-то не хватает (не больше припадков, припадков, где все отлично. ).

Веб-платформе не хватало чего-то неотъемлемого, чего не было у всех остальных в то время. Два его языка, HTML и CSS, на самом деле не предназначались для реального программирования. Они были просто языками разметки, своего рода метаязыками, предназначенными для легкого программирования, так что все сложное программирование выполняется несколькими умными людьми, которые создают браузеры, которые запускают эти языки разметки. В сети в конечном итоге отсутствовали переменные и if / else; действительно, это строительные блоки любого алгоритма. Вам понадобится как хранилище памяти, так и возможности для сравнения и ветвления, чтобы создать его. Без этих ингредиентов невозможно было бы построить какую-либо стоящую логику.

Входить…

JavaScript появился в сети в конце 1995 года. JavaScript был просто бомбой, да. С помощью JS вы впервые можете запрограммировать реальную логику на своих веб-сайтах. Вы нажмете кнопку, и все будет двигаться, менять цвет, исчезать, условно даже. Вы можете изменять HTML и CSS по запросу асинхронно. Черт, тогда почему бы не получить ленивые данные из сети и не подключать их к веб-сайту, когда они доступны, мы назовем это AJAX. Отлично, теперь мы можем добавлять кнопки повсюду, кнопки, которые делают все, что угодно, извлекают все виды данных, отображаемые на всевозможных графиках, в средствах массовой информации и в расширенном пользовательском интерфейсе. Давайте сделаем их похожими на одностраничное приложение, в котором вы можете делать все, к черту рабочий стол, кто все равно этим пользуется. У вас закончилась оперативная память, потому что ваш браузер снова забирает 4 ГБ? У нас есть RAM для вас, сэр, загрузите больше RAM. Вам нужны веб-работники, обслуживающие работники, видеоконференции в реальном времени, 3D-ускоренная графика, дополненная реальность, все здесь, сэр, вмешивайтесь. Просто используйте Javascript, и вы в нескольких строках от славы, денег и славы!

Но, как выясняется, каждый раз создавать все это с нуля было сложно… :(

О, я знаю, я знаю! Мы создадим инструмент автоматизации сборки (больше 3–4 из них), и мы создадим фреймворк внешнего интерфейса (примерно 10–15 из них, примерно половина из них - варианты реакции), и мы настроим пару глобальных пакетов. реестров и еще парочку менеджеров пакетов, и теперь вы можете javascriptly загрузить свой JavaScript в существующий JavaScript, чтобы запустить еще больше JavaScript! Это определенно не будет работать как дерьмо на всех машинах, перегружать всю оперативную память и пережевывать все батареи ... Нет, сэр, вмешивайтесь!

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

OK…

Дышим…

Давайте проанализируем, что здесь произошло, и самое главное, почему это произошло, хорошо?

Этот бум случился неспроста. Очевидно, на рынке постоянно растет спрос на сложную логику в Интернете. Очевидно, Интернет не успел приспособиться ко всему этому безумию. А Интернет - и его единственный родной язык программирования - JavaScript - остается единственной по-настоящему открытой платформой для разных устройств. Это не Android, это определенно не iOS, не Windows, macOS или черт возьми, даже не Linux (несмотря на то, что это самая бесплатная и доступная платформа из всех остальных).

Интернет - это одна из доминирующих платформ, и это хорошо, потому что Интернет - ничья, а это означает, что Интернет принадлежит всем.

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

JavaScript медленный и неоптимальный. Так будет всегда.

Но проблема с сетью все еще остается. И проблема, к сожалению, в его душе, а именно в JavaScript.

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

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

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

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

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

Причина проста. Возьмем, к примеру, эту функцию JavaScript:

function add (a, b) {
  return a + b;
}

Достаточно просто, правда?

«Боже, это проскользнет через процессор, как масло на сковороде!»

Держись, Гордон Рэмси ...

Это то, через что должна пройти популярная среда выполнения JavaScript V8 (та, которая используется в Chrome, Opera и других браузерах, а также в Node.js), чтобы положить масло на свою сковороду:

Причина этого осложнения проста: JavaScript не типизирован. В коде есть a + b, но как JavaScript должен знать, какой тип a и b будет каждый раз, когда вы вызываете функцию, чтобы он выполнял над ними соответствующее действие? Эти два могут быть числами, строками, логическими значениями, неопределенными, объектами, экземплярами классов (начиная с ES6) или любой комбинацией вышеперечисленного. JavaScript не знает, чего здесь ожидать, поэтому нет никакого способа подготовиться к его оптимальному запуску. И хотя блестящие инженеры, стоящие за этими движками, действительно делают все возможное, чтобы оптимизировать эту врожденную проблему, которая изначально заложена в такого рода языках, ни один нетипизированный язык никогда даже не приблизится к детерминизму времени выполнения, который может обеспечить типизация.

Фактически, статически типизированные скомпилированные языки идут еще дальше по пути оптимизации, потому что могут. Поскольку компилятор заранее знает, что вы объявили некоторую переменную c как имеющую тип number, для которой, например, требуется 4 байта памяти для хранения, а другая переменная d объявлена ​​как логическая, которой требуется всего 1 байт, она может затем пройти через весь ваш код. один раз во время компиляции (опережая время), вызвать какое-то черное инженерное вудо и выплюнуть исполняемый файл на другом конце с определенными адресами памяти, готовыми для процессора в крайнем случае. Это эффективность использования памяти, вычислений и мощности на оптимальном уровне, и это полностью отличается от того, как работают нетипизированные языки, такие как Javascript.

Здесь стоит уточнить, что не все скомпилированные языки ориентированы на аппаратно-дружественный машинный код (например, x86_64, который, вероятно, понимает ваш процессор). Это правда, что исполняемые файлы C и C ++, скомпилированные в машинный код, в значительной степени транслируют 1–1 во внутреннюю проводку вашего процессора. С другой стороны, Java и Typescript - нет. Они оба скомпилированы на некотором промежуточном языке. Затем совместимая среда выполнения может загрузить скомпилированный промежуточный исполняемый файл и выполнить окончательную интерпретацию на лету (часто с использованием оптимизированной техники JIT) на машинный язык, понятный вашему процессору.

В случае Java промежуточной целью компиляции является байт-код псевдосборки, который может выполняться на любой машине с помощью программы, называемой виртуальной машиной Java. В случае с Typescript целью компиляции является JavaScript, который может быть выполнен на любой машине с браузером. И таких машин довольно много, на большинстве из них предустановлен браузер. Еще несколько лет назад JavaScript также может выполняться на любой машине, на которой установлен Node.js, независимо от того, доступен ли браузер или нет, что является великолепным и полным сдвигом парадигмы.

На самом деле C ++ и Java уже можно экспериментально скомпилировать в совершенно новую и совершенно другую целевую платформу, о которой мы кратко упоминали ранее; промежуточный продукт под названием WebAssembly. Wasm - это новая цель низкоуровневой двоичной компиляции, которая загружается намного быстрее, чем JavaScript, и предназначена для присоединения к веб-платформе и включения в браузеры завтрашнего дня. Фактически все основные браузеры уже поддерживают его, и он работает в 10–50 раз быстрее, чем JS, в основном из-за наличия этих типизированных определений. Вы можете узнать об этом больше и просмотреть потрясающие демонстрации в Анонсирующей статье Mozilla.

Языки с динамической типизацией (JavaScript, Python, php) по сравнению с яблоками и яблоками почти всегда уступают в сложных производственных приложениях языкам со статической типизацией (Typescript, Java, C / C ++).

Нетипизированные интерпретируемые языки на самом деле оказываются хуже как по ремонтопригодности, так и по производительности. Работать с нетипизированным языком - все равно что зря просидеть ночь в баре: когда вы это делаете, это чистое удовольствие; вы чувствуете себя свободным, подвижным и сильным. Так будет до тех пор, пока вы не проснетесь на следующий день в ужасной головной боли, когда вам нужно убрать кучу собственной рвоты и столкнуться с смущающими фотографиями в Facebook того, что вы сделали прошлой ночью. Таким образом, вы можете думать о нетипизированных языках как о ссуде, которую вы берете как программист: возьмите его, будьте ответственны, и это может сработать для вас и получить больше удовольствия, чем в противном случае, но зайдите с этим слишком далеко, и вы закончите в уродливом месте. И поверьте мне, я знаю о проблемах с кредитами, я грек. Γεια σου μαμά!

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

Если компилятор кричит всякий раз, когда мы ошибаемся, это необязательно поможет написать лучший код, однако установка флага компилятора --strict Typescript, например, вместе с набором правил спуска TSLint может иметь большое значение для того, чтобы команда начала двигаться по более праведному пути Веб-разработка.

Так что, может быть, попробуем Typescript?

Наверное? Не знаю, ты выбираешь сам.

TypeScript, созданный Microsoft, уже вошел в список официальных языков Google, и мы также можем в будущем скомпилировать его прямо в WebAssembly вместо JavaScript для повышения производительности, что было в старом добром нетипизированном ванильном JS. просто не могу даже мечтать о приближении.

Все это убедительные индикаторы нынешних возможностей языка и его будущего.

Лично мне нравится Typescript по всем вышеупомянутым причинам, так что оно того стоит. У меня пока нет особого прироста производительности во время выполнения, поскольку я компилирую до JavaScript, обычно до ES6. Но это упрощает рефакторинг, я сначала получаю все последние функции ECMAScript (async / await), набор текста дает мне мощный редактор intellisense, а также упрощает чтение и поддержку моего кода для других (или для меня в будущем).

Собственно, именно по этим причинам Google уже более 10 лет кодирует то, что они назвали Clojure. Замыкание - это практически JavaScript с аннотированной типизацией в форме JSDoc. И да, он тоже скомпилирован на старый добрый JavaScript, и так было все эти 10 лет. Для них тоже не было повышения производительности во время выполнения, но повышения производительности и качества кода было достаточно, чтобы оправдать его сборку и использование. В конце концов они объединились с Microsoft и получили все необходимые функции в Typescript, так что в итоге они полностью перешли на это около месяца назад. Дело в том, что потребность в типизированном JavaScript существовала у тех, кто серьезно относился к своему коду, с очень долгого времени.

Подведение итогов

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

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

Я все еще люблю тебя, JavaScript. Если кто-то дочитал до этого места, я уверен, что он может подтвердить хотя бы это. Держись, детка. Подожди еще немного.

Если вы обнаружили, что это стоило потраченного времени, нажмите 👏 ниже, чтобы другие люди могли увидеть это здесь, на Medium.

Спасибо за внимание.
- maninak