Альтернативы JavaScript. Часть 1


Оглавление (нажмите, чтобы открыть):

Favicon

Блог по web технологиям. Веб студия г. Воронеж. Создание и поддержка сайтов на заказ.

  • Главная
  • /
  • JavaScript
  • /
  • 5 node.js альтернатив взамен WordPress

5 node.js альтернатив взамен WordPress

Выпущенный в 2003 году, WordPress до сих пор остается королем CMS. Но с развитием Node.js, появилось много современных соперников, которые имеют поддержку тем, плагинов, просты в установке на вашем собственном сервере, а также поддерживаются крупными сообществами. Ниже 5 примеров, с которыми вы возможно захотите познакомиться.

KeystoneJS

KeystoneJS — это мощный CMS фреймворк, построенный на Express и MongoDB. Он позволяет легко создавать динамические проекты с хорошо структурированными роутами, шаблонами и моделями.

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

EnduroJS

Enduro.js предлагает легкий и быстрый способ построить ваш проект, имеет простой и красивый пользовательский интерфейс администратора и интегрированные инструменты, позволяющие построить на сервере что угодно. Он работает без базы данных, вместо этого полагаясь на систему простых файлов, которые могут быть открыты непосредственно в текстовом редакторе. Фрейворк прост в установке и может быть развернут через Git.

Проект предлагает ряд тем, которые вы можете использовать и настроить так, как вам нравится. Он поддерживает многоязычные сайты, упрощенные роуты и множество других функций. Имеется даже live reload работающий через browsersync, что позволяет Вам мгновенно видеть все изменения, которые вы делаете, непосредственно в вашем браузере.

Apostrophe

Apostrophe предлагает мощные фронтенд и бэкенд функции поиска, богатый текстовый редактор, высокую производительность и drag-and-drop редактирование прямо на странице. Он очень удобен, имеет подробную документацию и активное сообщество.

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

Ghost

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

Он использует фреймворк Ember для фронтенда, Handlebars для шаблонизации и стандартную базу данных MySQL. Страница GitHub проекта содержит более 20 удивительных репозиториев, предлагающих различные утилиты, такие как настройки Vagrant, тем и CLI.

Hexo — это простой и мощный блоговый фреймворк, в которой каждый пост пишется в формате Markdown и выводится на статическую страницу с соответствующим макетом и стилями.

Проект предлагает мощную систему с множеством плагинов, которые вы можете установить для того, чтобы расширить свою функциональность. Он также предлагает быстрый и простой способ развертывания проекта на страницах GitHub или Heroku с помощью одной команды. Более того, Hexo поддерживает большое разнообразие красивых тем и шаблонов, которые можно использовать для создания интересных и привлекательных проектов.

Альтернативы JavaScript

ActionScript 3 — для работы нужен Flash Player, который устанавливается на каждый браузер отдельно.

Flex — ActionScript-библиотека для создания RIA-приложений.

Java FX — Java-библиотека для создания RIA-приложений.

Dart — язык программирования, созданный Google, которая позиционируется как замена JavaScript.

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

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

Зачем браузерам JavaScript, если есть Python как альтернатива ?

Может уже настал тот самый момент когда пора отвернуться от этого javascript.
Всем же очевидно, что js это историческая ошибка.
Стоит ли клепать бесконечные костыли для js, если можно сконцентрироваться на более годном ЯП ?

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

Ломать уже наработанное ?

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

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

— в питоне пробелы, из-за них код весит дофига и не сжимается

А зачем передавать необработанный в байт-код исходник?

чтобы, в аду тебя бородатые черти не били мемуарами Столлмана.

Форум

Справочник

Поиск по форуму
Расширенный поиск
К странице.

Роль javascript в природе

Что такого в этом javascript, почему javascript, и что есть еще полезного кроме него?

Что такое javascript?

  • Javascript — скриптовый язык, предназначенный для создания интерактивных веб-страниц.
  • Javascript не требуется компилировать, он подключается к HTML-странице и работает «как есть».
  • Javascript — НЕ java, а совсем другой язык. Он похоже называется, но не более того. У javascript есть свой стандарт: ECMAScript, спецификация которого находится на сайте в разделе стандарт языка.
  • Кто-то говорит, что javascript похож на Python, кто-то говорит о схожести с языками Ruby, Self. Правда заключается в том, что javascript сам по себе. Это действительно особенный язык.

Что умеет javascript?

  • Изменять страницу, писать на ней текст, добавлять и удалять теги, менять стили элементов.
  • Реагировать на события: скрипт может ждать, когда что-нибудь случится (клик мыши, окончание загрузки страницы) и реагировать на это выполнением функции.
  • Выполнять запросы к серверу и загружать данные без перезагрузки страницы. Это иногда называют «AJAX».
  • Устанавливать и считывать cookie, валидировать данные, выводить сообщения и многое другое.

Уникальность javascript

Прелесть и соль Javascript заключаются всего в нескольких пунктах.

  • Полная интеграция с браузером
  • Простые вещи делаются просто
  • Поддерживается почти везде

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

Например, такие технологии как ActiveX, VBScript, XUL — поддерживаются не в каждом браузере (не кросс-браузерны). Такие технологии как Flash, Silverlight, Java — не полностью интегрированы с браузером, работают в своем окружении.

Поэтому Javascript — уникальная технология, и таковой останется. Сейчас она развивается, создается язык Javascript 2 и новый интерпретатор.

Другие технологии. Альтернативы javascript.

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

Java — по сравнению с javascript, java-applet’ы тяжелые, долго загружаются, но могут все. Они, как правило, используются там, где требуется почти-десктоп приложение. Очень сильно java’у потеснила технология Flash.

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

Flash

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

  • Мощные средства для создания сетевых соединений(сокеты)
  • Объекты для работы с мультимедиа: изображениями, аудио, видео
  • Внутреннее хранилище объектов, которые не посылаются на сервер при каждом запросе, как куки.
  • Удобные графические средства разработки для Flash

Ну и для баланса — недостатки, по сравнению с javascript.

  • Отдельный контейнер. Например, нельзя выделить участок текста, частично находящегося в контейнере Flash.
  • Плохо индексируется поисковиками. Поисковики ходят по HTML-ссылкам, но(пока?) не кликают по ссылкам внутри Flash-приложения.

Из Flash можно легко вызвать javascript. Наоборот — сложнее, но тоже возможно, поэтому целесообразно знать обе технологии и применять их вместе.


JavaFX, Silverlight, XUL, vbscript

Эти технологии призваны дополнять javascript в области коммуникации и построения интерфейсов.

Пока они все далеки по распространенности от javascript и flash.

  • JavaFX — «легкая» надстройка над Java, будет работать только с Java на компьютере клиента.
  • XUL — язык описания интерфейсов, удобен если писать планируете только под Mozilla. Также используется для написания десктоп-приложений.
  • Silverlight — конкурент Flash от Microsoft на основе .NET. Другими OS, кроме Windows, поддерживается слабо. Не имеет широкого распространения.
  • vbscript — попытка Microsoft сделать подобие javascript на основе Visual Basic. Не развивается, сильно уступает по возможностям, и, как следствие — практически не используется в современном веб-программировании.

Резюме

  • Что такое javascript.
  • В чем его преимущества.
  • Место javascript среди веб-технологий.

P.S. Пожалуйста, не нужно разводить holy wars в комментариях к этой статье. Пусть ваши комментарии будут полезны читателям.

На сколько я знаю, разработка JavaScript 2 (EcmaScript 4) приостанавливается. Вместо него будет более консервативный EcmaScript 5.

Да уж пусть сделают чего-нибудь а там увидим. Хоть EcmaScript 10, лишь бы уже был и главное работал в браузере

Silverlight — конкурент Flash от Microsoft на основе .NET. Другими OS, кроме Windows, поддерживается слабо.

Moonlight — кросплатформенная версия Silverlight на основе Mono. Но, согласен, она действительно мало распространена.

И по возможностям, насколько я слышал, очень так себе.

Хм, а я слышал, что Flash сильно уступает Silverlight, особенно последней его версии. Все таки работа над DirectX, на которую опирается Silverlight, дала о себе знать

Да, это действительно круто если Silverlight умеет работать с DirectX, но не нужно забывать о пользователях MacOS и Linux

Mono делается энтузиастами, со всеми вытекающими

Monolight не то что мало распространена, она еще и в возможностях даже не сравнима с Silverlight. Отстает эдак на 2 (две!!) майор версии

Пускай мелкософт засунут себе далеко все свои технологии которые привязаны к платформе и для нормальных систем из за них приходится придумывать костыли типа MONO которые тупят как Виндовс но всё таки работают

Можно подумать, что Linux никогда не тупит?! Тупит так же, а иногда и похлеще Windows.

А ты хотя бы раз устанавливал ку себя Linux, чтобы так говорить. Так высказываются люди, которые кроме как setup.exe, для них и за них всё делает Мелкософт, ну и развитие естественно на том же уровне.

В мини опере высвечивается окно, jаvаsсriрt аlеrt деактевируйте всплывающие окна, как это сделать?

Илья, у меня в Firefox’е при разрешении 1680*1050 идет наложение текста
Происходит это там, где написано «Уровень выше», и на это накладывается «Подключение и выполнение javascript »» Косяк в дизайне наверное

Я бы в плюсы Javascript добавил то, что этим языком не владеет никакая компания, что довольно редко встречается.

мелочь, а приятно все-таки

Говорят, что javascript похож на self.
а ещё на ActionScript, JScript, QActionScript — потому что все они суть реализация стандарта ecma-262, но только с различным функционалом.

>Говорят, что javascript похож на self.

Это потому, что они оба принадлежат к такой разновидности ООП, как прототипное программирование.

А в Lua прототипное? Собственно прототипов с наследованием там нет, просто объекты тоже являются хэш-таблицами.

Как-то брался за javascript, все так непонятно.
Но сейчас попробую, надеюсь, получится освоить.
Буду учить javascript на этом сайте.
Если кто-то знает какие или какой-нибудь хороший, толковый сайт по изучению javascript, пишите ссылки сюда

Самоучительб хоть и устаревшый но вроде понятный.Если скомбинировать эго с https://javascript.ru я думаю можно многому научится!

Прошу прощения за нубский вопрос, но где можно почитать про конструкцию вида
if (obj) . что за сравнение такое ? выполняется ли проверка на null или еще и на undefined ? В чем разница между приведенным выше и конструкцией if(obj != null) ?

JavaScript классный язык. Он даже во многом превосходит PHP. Во первых тем что он встроин в браузер и его не нужно скачивать отдельно. Ещё он более понятен и функционален.

Лично мне пхп намного проще. А в чем сложность то скачать и установить, лень-матушка.

Ну это кому как. php я легко вкурил, а js не могу понять как ни пытаюсь

О_о!
Как «приятно» читать такие комментарии.

Бил Гейц как всегда ворует чужие готовые продукты (javascript, Flash), перекодирует и продаёт под другим именем (vbscript, Silverlight).

JavaScript и VBScript вышли одновременно, более того, именно из-за Microsoft’овского языка сценариев JS вышел недоработанным.

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

Альтернативы для JavaScript

Javascript это практически вездесущий язык программирования. В некотором роде его можно сравнить с C на пике его популярности. На нем можно писать всё что угодно, начиная от красивых выпадающих менюшек, слайдеров на вашем сайте, заканчивая полноценнами приложениями для серверов, мобильных, для десктопа и даже для embedded систем типа arduinio.

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

Например, если вам хочется классического ООП, вместо прототипов, или вы хотите больше синтаксического сахара, посмотрите в сторону CoffeeScript. Если вам нужна строгая типизация вам могут понравиться Dart или TypeScript. К слову сказать, Dart работает нативно в Google Chrome и на некоторых тестах показывает 50% прирост производительности по сравнению с обычным javascript. Для любителей функциональго программирования подойдет ClojureScript или Roy. Вариантов масса, и вы не обязаны писать всё на чистом яваскрипте, даже если разрабатываете фронтенд под веб или работаете с node.js.

1. CoffeeScript

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

2. Dart

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

3. TypeScript

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

4. ClojureScript

ClojureScript — это расширение языка Clojure, с возможностью компиляции в Javascript. Напоминает Lisp.

5. Opal

Компилятор из Ruby в Javascript.

6. IcedCoffeeScript

IcedCoffeeScript это надстройка над CoffeeScript, упрощающая контроль за асинхронными операциями. Вместо колбеков вводятся два новых оператора: await и defer.

7. LiveScript

Ещё один форк от CoffeeScript. Добавляет поддержку функционального стиля программирования, а также вводит небольшие улучшения в текущую ООП-модель.

8. Kaffeine

Расширяет синтакс яваскрипта, не изобретая ещё один язык программирования. Код на Kaffeine строка к строке соответствует скомпилированому яваскрипт коду. Данная фича должна существенно упростить отладку приложения.

8. Roy

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

Ну и конечно, есть ещё один язык, самый главный в этой семье. Это, конечно же, сам Javascript. Как ни крути, а именно он будет выполнятся в браузере. Тем не менее, для использования в больших проектах стоить посмотреть в сторону Dart (поддерживаемый Google) или TypeScript (поддерживается Microsoft). CoffeeScript очень популярен в последнее время, а с помощью source maps работать с ним стало ещё проще. Если вы устали от яваскрипта или хотите попробовать чего-то новенького, милости просим.

PS. Обзор подготовлен с использованием каталога javascript-библиотек Jster.Net. Сейчас в нем уже 981 билиотека для фронтенд-разработки.

PS/2 Ещё больше альтернатив на сайте AltJS

Alternatives to JavaScript

At the moment, the only fully supported language, and the de-facto standard for DOM tree manipulation in the browser is JavaScript. It looks like it has deep design issues that make it a minefield of bugs and security holes for the novice.

Do you know of any existent or planned initiative to introduce a better (redesigned) language of any kind (not only javascript) for DOM tree manipulation and HTTP requests in next generation browsers? If yes, what is the roadmap for its integration into, say, Firefox, and if no, for what reasons (apart of interoperability) should be JavaScript the only supported language on the browser platform?

I already used jQuery and I also read «javascript: the good parts». Indeed the suggestions are good, but what I am not able to understand is: why only javascript? On the server-side (your-favourite-os platform), we can manipulate a DOM tree with every language, even fortran. Why does the client side (the browser platform) support only javascript?

18 Answers 18

The problem with javascript is not the language itself — it’s a perfectly good prototyped and dynamic language. If you come from an OO background there’s a bit of a learning curve, but it’s not the language’s fault.

Most people assume that Javascript is like Java because it has similar syntax and a similar name, but actually it’s a lot more like lisp. It’s actually pretty well suited to DOM manipulation.

The real problem is that it’s compiled by the browser, and that means it works in a very different way depending on the client.

Not only is the actual DOM different depending on the browser, but there’s a massive difference in performance and layout.

Edit following clarification in question

Suppose multiple interpreted languages were supported — you still have the same problems. The various browsers would still be buggy and have different DOMs.

Мастер Йода рекомендует:  Как заработать деньги школьнику интернет в помощь

In addition you would have to have an interpreter built into the browser or somehow installed as a plug in (that you could check for before you served up the page) for each language. It took ages to get Javascript consistent.

You can’t use compiled languages in the same way — then you’re introducing an executable that can’t easily be scrutinised for what it does. Lots of users would choose not to let it run.

OK, so what about some sort of sandbox for the compiled code? Sounds like Java Applets to me. Or ActionScript in Flash. Or C# in Silverlight.

What about some kind of IL standard? That has more potential. Develop in whatever language you want and then compile it to IL, which the browser then JITs.


Except, Javascript is kind of already that IL — just look at GWT. It lets you write programs in Java, but distribute them as HTML and JS.

Edit following further clarification in question

Javascript isn’t, or rather wasn’t, the only language supported by browsers: back in the Internet Explorer dark ages you could choose between Javascript or VBScript to run in IE. Technically IE didn’t even run Javascript — it ran JScript (mainly to avoid having to pay Sun for the word java, Oracle still own the name Javascript).

The problem was that VBScript was proprietary to Microsoft, but also that it just wasn’t very good. While Javascript was adding functionality and getting top rate debugging tools in other browsers (like FireBug) VBScript remained IE-only and pretty much un-debuggable (dev tools in IE4/5/6 were none existent). Meanwhile VBScript also expanded to become a pretty powerful scripting tool in the OS, but none of those features were available in the browser (and when they were they became massive security holes).

There are still some corporate internal applications out there that use VBScript (and some rely on those security holes), and they’re still running IE7 (they only stopped IE6 because MS finally killed it off).

Getting Javascript to it’s current state has been a nightmare and has taken 20 years. It still doesn’t have consistent support, with language features (specified in 1999) still missing from some browsers and lots of shims being required.

Adding an alternate language for interpreting in browsers faces two major problems:

Getting all the browser vendors to implement the new language standard — something they still haven’t managed for Javascript in 20 years.

A second language potentially dilutes the support you already have, allowing (for instance) IE to have second rate Javascript support but great VBScript (again). I really don’t want to be writing code in different languages for different browsers.

It should be noted that Javascript isn’t ‘finished’ — it’s still evolving to become better in new browsers. The latest version is years ahead of of the browsers’ implementations and they’re working on the next one.

8 JavaScript Alternatives for Web Developers to Consider

There are lots of programming languages to choose from, but there is at least one that is used by virtually everyone. When it comes to front-end development, hardly any programmer can do without JavaScript, which is a universal solution for web interfaces creation. Moreover, it is often treated as the only solution of this kind. However, there some alternatives to JavaScript that do their job rather well. In this article, we’ll briefly review those ones that are definitely worth a closer look.

JavaScript Overview

Before discussing alternative options, it is necessary to say a couple of words about JS and its key features that make it the most powerful tool for front-end web development. Broadly speaking, JavaScript is used for creation of all types of interactive elements of websites. In particular, it allows executing the following tasks:

  • creating all types of online interactive forms — registration forms, questionnaires and other forms that need to be filled by users;
  • tracking users’ actions on the site, such as scrolling, zooming, clicking buttons and so on;
  • accessing HTML-based component and working with them without the need of refreshing the page.

One of the key JS advantages is its full compatibility with most existing browsers. This language has a simple syntax and is easy to use for any purpose.

JavaScript Alternatives and Their Pros and Cons

Despite all the popularity and uniqueness of JavaScript, there are some decent alternative tools that can be used for certain tasks execution. Here are some of them.

This language is transcomplied into JS. What it does is improving readability of JavaScript and making the code simpler and shorter. CoffeeScript can also be used with Node.js. It is not a modification or a subgroup of JavaScript, though. But if you want to use it for coding, you need to know JavaScript anyway. Drawbacks of CoffeeScript include a need for compilation, a limited feature set and few specialists writing in it.

Dart is a Google’s product that offers a lot of opportunities for constructing well-structured apps. It is a new-gen high-performance language that gives pretty much flexibility to developers. Dart is regularly upgraded by Google, but if compared to JavaScript it still has fewer capabilities and a smaller community.

This programming language has been developed by Microsoft. Its primary function is enhancement of JavaScript capabilities, which it is backward compatible with. When compiled to JS, any app written in TypeScript can be viewed in most browsers. It is also compatible with Node.js. TypeScript supports classes and modules connection as well as static type-checking. The community of the language is smaller than that of JavaScript, and coding using this language it more time consuming.

ClojureScript is an implementation of Clojure programming language with a compilation into JavaScript. It emits JS code which is compatible with the compilation mode of the Google Closure compiler. It smoothly works in most browsers, is compatible with mobile platforms and Node, js. It is a simple and powerful programming tool, though not as popular as JavaScript.

It is one of object-oriented languages acting as a transcompiler to JavaScript from Ruby. As developers claim, Opal is developed to complement or completely replace other languages including JavaScript, Java, and C, C++, C#and Eifel. However, as of today, its popularity it low. And still, it is certainly worth mentioning.

Elm is a relatively new functional language used for graphic interface development. Despite its not very long history, it is now actively utilized by web-developers who work with JavaScript. It is easily compiled to JavaScript and offers much flexibility in front-end development. Elm is easy to use and feature a self-formatting code.

If you feel that capabilities of JavaScript are not sufficient for all your tasks completion, try Kaffeine — an effective tool, the main purpose of which is an extension of JavaScript syntax. Its code compiles JavaScript code and makes the process of debugging simpler.

Like many other languages, Roy is compiled to JavaScript. It has been developed as an experimental tool and to a large extent resembles JavaScript. Roy not only makes generation of code simpler, but also has some features of functional languages like pattern matching, whitespace significant syntax and others. Here again, the main problem is low popularity of the language.

Why is JavaScript Better?

As you see, today there are some real (though less popular) alternative to JavaScript. And still, you’ll hardly do without the latter. The reasons for it are not only above-mentioned JavaScript advantages, but also some independent facts:

  • all browsers support JavaScript;
  • JS scripts and plugins are used everywhere by everyone, even by regular users;
  • it has the richest feature set;
  • specialists who can code in JS languages are always in demand.

Finally, JavaScript is regularly upgrading, and new releases allow resolving more and more complicated tasks.

Альтернативы JavaScript

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

Знаете ли вы о какой-либо существующей или планируемой инициативе по внедрению лучшего (переработанного) языка любого вида (не только javascript) для обработки дерева DOM и HTTP-запросов в браузерах следующего поколения? Если да, то какова дорожная карта для ее интеграции, скажем, в Firefox, и если нет, то по каким причинам (помимо интероперабельности) должен быть JavaScript только поддерживаемый язык на платформе браузера?

Я уже использовал jQuery, и я также читал «javascript: хорошие части». Действительно, предложения хороши, но я не могу понять: почему только javascript? На стороне сервера (ваша-любимая-os-платформа) мы можем манипулировать деревом DOM с каждым языком, даже fortran. Почему клиентская сторона (платформа браузера) поддерживает только javascript?

Проблема с javascript — это не сам язык — это отличный прототип и динамический язык. Если вы работаете на фоне OO, есть немного кривой обучения, но это не ошибка языка.

Большинство людей считают, что Javascript похож на Java, потому что он имеет похожий синтаксис и аналогичное имя, но на самом деле это намного больше похоже на lisp. Это действительно очень хорошо подходит для манипуляций с DOM.

Реальная проблема заключается в том, что он скомпилирован браузером, а это означает, что он работает совсем по-другому, в зависимости от клиента.

В зависимости от браузера не только фактическая DOM, но и огромная разница в производительности и макете.

Изменить следующие пояснения

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

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

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

ОК, так что о какой-то песочнице для скомпилированного кода? Звучит как Java-апплеты для меня. Или ActionScript в Flash. Или С# в Silverlight.

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

Кроме того, Javascript — это уже уже тот ИЛ — просто посмотрите GWT. Он позволяет писать программы на Java, но распространять их как HTML и JS.

Изменить следующие последующие разъяснения

Javascript не является, или, вернее, не единственным, поддерживаемым браузерами: обратно в темные века Internet Explorer вы можете выбирать между Javascript или VBScript для запуска в IE. Технически IE даже не запускал Javascript — он выполнял JScript (в основном, чтобы избежать необходимости платить Sun за слово java, Oracle по-прежнему владеет имя Javascript).

Проблема заключалась в том, что VBScript был патентован для Microsoft, но также, что это было не очень хорошо. В то время как Javascript добавлял функциональные возможности и получал инструменты отладки высшего уровня в других браузерах (например, FireBug), VBScript оставался только для IE и в значительной степени не отлаживался (dev инструменты в IE4/5/6 не существовали). Тем временем VBScript также расширился, превратившись в довольно мощный скриптовый инструмент в ОС, но ни одна из этих функций не была доступна в браузере (и когда они стали серьезными дырами в безопасности).

Есть еще некоторые внутренние внутренние приложения, которые используют VBScript (и некоторые полагаются на эти дыры в безопасности), и они все еще работают с IE7 (они только остановили IE6, потому что MS окончательно отключили его).

Получение Javascript к текущему состоянию было кошмаром и заняло 20 лет. Он по-прежнему не имеет последовательной поддержки, с языковыми функциями (указанными в 1999 году), которые все еще отсутствуют в некоторых браузерах, и требуется большое количество прокладок.

Добавление альтернативного языка для интерпретации в браузерах сталкивается с двумя основными проблемами:

Получение всех поставщиков браузеров для внедрения нового языкового стандарта — то, что им еще не удалось для Javascript через 20 лет.

Второй язык потенциально разбавляет поддерживаемую вами поддержку, позволяя (например) IE иметь поддержку второго курса Javascript, но отличный VBScript (снова). Я действительно не хочу писать код на разных языках для разных браузеров.

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

Frontender Magazine

Часть 1: наследование через прототипы

Перед тем как мы начнем — позвольте представиться. Во время чтения вы, вероятно, будете задаваться вопросом «кто он такой и что о себе воображает».

Меня зовут Эрик Элиот, я автор книги «Programming JavaScript Applications» (O’Reilly), ведущий документального фильма «Programming Literacy» и создатель серии платных онлайн-курсов «Learn JavaScript with Eric Elliott».

Внес свой вклад в создание ПО для Adobe Systems, Zumba Fitness, The Wall Street Journal, ESPN, BBC, топ-артистов таких как Usher, Frank Ocean, Metallica, и многих других.

Однажды…

Я блуждал во тьме. Я был слеп — топтался на месте, натыкался на предметы и ломал их, приводил в беспорядок всё к чему прикасался.

В 90-х я программировал на C++, Delphi и Java, создавал 3D-плагины для программы которая позже стала называться Maya (используется большинством крупных киностудий для создания блокбастеров).

И тут случилось это: пришествие Интернета. Все начали создавать веб-сайты, и, после практики создания и поддержки пары интернет-журналов, друг убедил меня, что будущее Интернета за SaaS (тогда этого термина не было и в помине). В то время я об этом не догадывался, однако этот общий настрой стал потихоньку влиять на мое общее представление о программировании, потому что если вы хотите делать хороший SaaS продукт — приходится использовать JavaScript.

И как только я начал его использовать — я уже не мог остановится. Внезапно, всё стало проще. Программы, которые я создавал, стали более гибкими. Код смог дольше существовать без необходимости рефакторинга. Вначале я думал о JavaScript как скриптовом языке для взаимодействия элементов страницы — однако, когда я узнал о cookies и AJAX, изначальное представление о нём изменилось.

JavaScript предлагает то чего не хватает в других языках:

JavaScript является одним из наиболее важных языков программирования всех времен не просто из-за своей популярности, а потому что он популяризует две чрезвычайно важные для развития всей науки программирования парадигмы:

  • Наследование через прототипы (объекты не содержащие классов, делегирование прототипов более известное как OLOO — Objects Linking to Other Objects)
  • Функциональное программирование (с помощью лямбда-выражений и замыканий)

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

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

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

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

И если вы всё ещё находитесь в ней — пришло время перейти на новый уровень.

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

Вы работаете с липовым JavaScript, который существует только как надстройка над Java.

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

Мы разводим бардак


«Не понимающие что идут в темноте никогда не выйдут на свет».

Конструкторы нарушают принцип открытости/закрытости. Создаете игру на HTML5? Хотите изменить стандартное поведение и использовать пул объектов вместо инстанцирования новых копий, чтобы сборщик мусора не влиял на FPS? Вы либо поломаете логику приложения, либо запутаетесь с костылями при создании фабрики методов.

Если вы вернете произвольный объект из конструктора — это сломает ссылки на прототип, и ключевое слово this в конструкторе больше не будет ссылаться на только что созданный экземпляр объекта. Кроме того, «фабрика» получается менее гибкой, за счет того, что в ней не получится использовать this ; мы просто его выбрасываем.

А использовать конструкторы без строгого режима может быть просто опасно. Если вызывающий забывает использовать new , ваш код не использует строгий режим или не является ES6-классом [вздох], все что вы присваиваете через this будет засорять глобальное пространство имен. Не очень красиво, я считаю.

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

Мастер Йода рекомендует:  Как работает SSL на сайте

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

На самом деле, JavaScript вообще не нуждается в конструкторах, поскольку любая функция может вернуть новый объект. С помощью динамического расширения объектов, синтаксиса объектов и Object.create() у нас есть все что нужно. И наконец-то this ведет себя везде одинаково. Ура-ура!

Добро пожаловать на седьмой круг ада

«Чаще всего я не настолько печален насколько должен».

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

Если поведение конструкторов это кастрюля с водой, то классическое наследование это не огонь, а пламя из седьмого круга ада Данте.

Проблема гориллы и банана

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

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

Допустим, вы начинаете с двумя классами: Инструменты и Оружие. Вы уже облажались — у вас не получится создать игру «Cluedo» (прим. пер.: имеется ввиду, что от класса Оружие нельзя с легкостью получить инстансы Нож и Револьвер, необходимые для игры.)

Проблема сильной связанности

Связь между классом и его родителем является самой крепкой формой зависимости в объектно-ориентированном дизайне (ООД). Переиспользуемый модульный код, наоборот, имеет слабые связи.

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

Проблема необходимого дублирования

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

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

Каждый классический ООП-программист рано или поздно

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

В этом плане ключевое слово class , вероятно, самое вредное нововведение в JavaScript. Я безмерно уважаю блестящих и трудолюбивых людей, которые прилагали свои усилиях по стандартизации, но даже блестящие люди иногда делают неправильные вещи. К примеру, попробуйте в консоли браузера выполнить .1 + .2 . (прим. пер.: тут автор явно троллит — вряд ли это архитектурная ошибка языка). Однако, это не мешает мне считать, что Брендан Айк внес большой вклад в веб, языки программирования и развитие ИТ в целом.

P.S.: Не используете super если не получаете удовольствие от пошаговой отладки каждого слоя из множества абстракций наследований.

Возрождение

Эти проблемы множатся по мере роста приложения и, в конце концов, остается только переписать всё с нуля или полностью доломать — иногда это единственный способ сократить финансовые потери.

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

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

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

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

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

Шаг к свету

«Совершенство достигается не тогда, когда нечего больше добавить, а тогда когда больше нечего убавить».

Антуан де Сент-Экзюпери

Недавно, работая над библиотекой для демонстрации прототипного наследование для своей книги «Programming JavaScript Applications», я набрел на интересную идею: функция-фабрика, которая помогает создавать функции-фабрики, которые, в свою очередь, успешно наследуются и объединяются. Подобные фабрики я назвал «штампами», и библиотеку, соответственно, «Stampit». Она простая и очень маленькая. Я рассказывал о ней на конференции O’Reilly Fluent в 2013 году, и написал о статью в блоге.

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

Конечно, Stampit не является единственной альтернативой. Например, Дуглас Крокфорд совсем не использует new или this , предлагая вместо этого полностью функциональный подход к повторному использованию кода.

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

Еще одна хорошая альтернатива наследованию — использование модулей (я рекомендую npm + ES6 модули через Browserify или WebPack), или просто клонирование объектов через копирование их свойств ( Object.assign() , lodash.extend() и т.п.).

Механизм копирования это еще одна форма прототипного наследования под названием «наследование через объединение».

Даже если вы последуете совету Дугласа Крокфорда и перестанете использовать this , вы все еще можете использовать прототипы. Наследование через объединение возможно благодаря такому свойству JavaScript как динамическое расширение объекта: способности модифицировать экземпляр объекта после его создания.

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

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

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

Не имеет значения как это сделано, если сделано плохо.

Единственная важная вещь в разработке ПО — это то, что пользователи любят ваше ПО.

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

Одна из таких книг (вероятно, самая известная) «Паттерны проектирования» от GoF строится вокруг двух основополагающих принципов:

«Создавайте интерфейсы вместо реализации» (фокусируйтесь на том что делает ваш код вместо как он это делает) и «композиция предпочтительнее наследования».

Поскольку дочерние классы реализуют интерфейсы родительского — второй принцип вытекает из первого, но будет полезно обсудить его подробно.

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

Погуглите «new considered harmful», «inheritance considered harmful» и «super is a code smell». Вы найдете дюжину статей в авторитетных блогах наподобии Dr. Dobb’s Journal, написанных еще до изобретения JavaScript. Все они которых говорят одно и то же: new , сломанное классическое наследование и связывание потомок-родитель (в нашем случае через super ) это дорога в один конец.

Даже Джеймс Гослинг, создатель Java, признает что Java неправильно реализует объекты.

Хотите ближе к JavaScript? Дуглас Крокфорд сообщил что Object.create() был добавлен в синтаксис для того чтобы ему не пришлось использовать new .

Кайл Симпсон (автор, «You don’t know JS») написал захватывающую серию из трех постов под названием «JS Objects: Inherited a Mess».

Кайл противопоставляет прототипное наследование классическому через классы, утверждая что первое проще и удобнее. Он даже ввел термин OLOO (Objects Linked to Other Objects), чтобы прояснить различия между делегированием прототипа и наследованием через класс.

Хороший код — простой код.

«Упрощение это удаление очевидного и добавление смысла».

Итак, если вы выбросите конструкторы с классическим наследовании из JavaScript кода, все станет:

  • Проще (Легче читать и писать, исчезнут неправильные паттерны проектирования.)
  • Более гибко (Переключиться с создания новых экземпляров на легко утилизируемые пулы объектов? Без проблем!)
  • Мощнее и выразительнее (Наследовать от нескольких предков? Наследовать приватные методы? Как нефиг делать!)

Вариант получше

«Если вещь теоретически может быть опасной, и есть вариант получше — всегда используйте этот вариант».

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

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

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

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

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

Выберите правильный путь

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

П.С. Не пропустите продолжение статьи «Два столпа JavaScript. Часть 2: Функциональное программирование». Или «Как прекратить заниматься микроменеджментом».

TypeScript как будущее энтерпрайзного JavaScript. Часть 1

Не стану пересказывать тут историю появления JS, она прекрасно всем известна, и описывается одним словом — спешка. JavaScript задумывался и создавался в очень сжатые сроки. По словам создателя JS Brendan Eich, у них было лишь 10 дней на все. Microsoft наступал на пятки и, если бы они проиграли, то сейчас эта статья была бы частично посвящена VBScript (Visual Basic Script).

Статья разделена на две части. Первая часть описывает язык TypeScript — я попытаюсь разъяснить, каким образом множество новых концепций TS проецируются на JavaScript. Вторая часть будет посвящена процессу разработки и миграции существующего кода на TypeScript, а также планам развития языка.

Битва с ветряными мельницами


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

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

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

Рискую быть закиданным помидорами, так как покушаюсь на святое, но самый популярный пример — jQuery. Стоит хотя бы вспомнить возможные варианты главной функции-объекта jQuery. «Функция-объект» — чувствуете, как это звучит? Вы можете вызвать jQuery как функцию девятью (девятью, Карл!) различными способами — все зависит от аргументов. А еще, сама функция является объектом, в котором может быть неконтролируемое число методов и/или свойств.

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

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

В корпорациях вроде Google технические специалисты очень быстро столкнулись с тем, что с ростом размеров JavaScript приложения практически с геометрической или даже экспоненциальной скоростью растут затраты на поддержку и исправление ошибок. В ответ на эту проблему Google выпустил GWT — Google Web Toolkit. Это компилятор, набор инструментов и базовых классов для разработки веб-приложений на Java. Стало возможным с минимальными оговорками писать веб-приложения на строго типизированном языке программирования с использованием большинства его плюшек. В качестве результата вы получаете приложение, написанное на, фактически, машинном JavaScript. Этот код невозможно отлаживать отдельно от GWT, это просто лишено смысла. В декабре прошлого года, после более чем года молчания, проект выпустил бету новой версии (2.8.0).

Стоит также заметить, что GWT чаще рассматривают как единственную возможность для джавистов, не владеющих JS, писать развесистый front-end без отрыва от любимого языка для back-end’а.

Других же не устраивал только синтаксис JavaScript, и они разрабатывали свои варианты языка программирования, которые с разной степенью прозрачности транслируются в JavaScript. Тут список примеров возглавляет, конечно же, CoffeScript. Подборка всего, что так или иначе транслируется в JavaScript, опубликована на github в wiki проекта CoffeScript.

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

ES6 приходит к нам как набор дополнений к уже привычному стандарту ES5. Набор этих дополнений неточен, постоянно дополняется и переделывается в той или иной степени.

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

Это своего рода продолжение войны браузеров, но уже в более вялой форме. Вот только она по-прежнему приводит к условиям проверки браузера или даже его версии в нашем коде, всевозможным «полифилам» (polifill), которые мы вынуждены подключать к нашим проектам, если хотим использовать какую-то «вкусность» из ES6, например, Promise или setImmediate. Но это история про браузерный API, а не про сам язык JavaScript.

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

Проект Babel представляет из себя транспайлер из современного представления о правильном переводе ES6 или даже ES2015 в код, совместимый с ES5. То есть разработчик получает возможность писать на самой современной версии JavaScript и, в большинстве случаев, не беспокоиться о совместимости с браузерами, которые еще не включают поддержку ES6 в свои JS-движки (или не включают по умолчанию, так как все, что скрыто за специальными экспериментальными настройками, лучше считать выключенным и недоступным). Про проект и все его возможности вы можете прочитать на официальном сайте, а мы пойдем дальше.

Бардак и порядок

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

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

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

Мастер Йода рекомендует:  Как использовать функцию PHP Is_Numeric () PHP

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

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

Согласно второму закону термодинамики, энтропия всегда возрастает, но в наших силах хотя бы замедлить этот процесс.

TypeScript — надстройка вокруг ES6, ES2015

Пришло время перейти к главной теме. TypeScript — это язык программирования, который является супер-сетом вокруг ES6, ES2015. Разработан в Microsoft и теперь развивается в содружестве с коммьюнити. Даже Google приложил руку в виде AtScript, был поглощен одной из прошлых версий TypeScript. Спросите, если хотите, подробности у Google.

Что из себя представляет супер-сет? Это надстройка вокруг основного языка. Таким образом, любой работающий JavaScript-код автоматически является валидным TypeScript-кодом.

Что нового привносит TypeScript:
— Статическая типизация и выведение типов;
— Необязательные аргументы для функций и значения по умолчанию;
— public, private, protect для свойств и методов классов;
— Геттеры и сеттеры для свойств «без головной боли»;
— Декораторы для всего*;
— Интерфейсы и абстрактные классы;
— Generics;
— Компилирование в ES5 или даже в ES3 (с оговорками).

И в том числе плюшки ES6:
— Arrow Functions;
— Классы с единым стилем наследования;
— async/await из ES7;
— Итераторы и Генераторы*;
— Многострочные строки с шаблонизацией и тоже «без головной боли» с плюсами и кавычками;
— Управление зависимостями, в том числе и их динамическая загрузка.

* — (цель компиляции — не ниже ES5) экспериментальная поддержка, имплементация может измениться.

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

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

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

Предупреждения — главное оружие компилятора. Через предупреждения, которые он выдает в консоли, он сообщает вам о своих «сомнениях» относительно качества кода — «Вы указали, что эта переменная имеет тип Строка, но вот тут вы используете её как Число, вы уверены?» (это очень вольный пересказ сообщения компилятора). Если вы уверены, и ваш выбор конкретно такой логики осознан, то вы можете такую строчную переменную дополнить приведением типа к числу (или воспользоваться, например, parseInt() ), явно сообщая компилятору, что ситуация под контролем.

Весь генерируемый JS-код в результате работы компилятора может быть легко читаемым нормальным JS-кодом, сохранившим имена переменных, объектов и свойств, ваши комментарии в нужных местах — все то, что даст вам возможность легко сопоставить TypeScript-код с JavaScript-кодом для лучшего понимания языка.

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

Предупреждения и ошибки компиляции

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

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

Лишь в ближайшее время компилятор TypeScript научится использовать в своей работе JavaScript-код (то есть код в файлах .js) — это позволит расширить сферу его возможностей к анализу на jsDoc-комментарии, где часто можно встретить в том числе типы данных для переменных, аргументов и непосредственному выведению типов на основе кода.

Любой JavaScript — это валидный TypeScript. Так как это супер-сет вокруг JavaScript, это означает, что вы можете использовать все, что есть в JavaScript всех версий, и то, что привносит непосредственно TypeScript.

Статическая типизация и выведение типов

У вас есть базовый набор типов JavaScript с явными декларациями, плюс парочка дополнительных, вроде enum(множество) и tuple (тьюплы, схожие по концепции с таковыми в python).

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

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

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

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

Также TypeScript, как говорилось ранее, оставляет вам возможность использовать все богатства динамического языка и позволяет вводить особый тип данных any. Этот тип данных говорит компилятору буквально следующее: «В этой переменной может быть все что угодно».

Необязательные аргументы для функций и значения по умолчанию

Без предисловий, пример, который расскажет сразу все:

Кроме объявления типа или структуры (что по сути является типом, но без имени) аргумента, в F1 используется конструкция для функции с неограниченным количеством аргументов (при вызове). Фокус состоит в том, что в переменную otherParams будут помещены все прочие (после четвертого) аргументы, с которыми будет вызвана функция. Конечно, для этого будет сгенерированы несколько строк JS-кода, которые любезно отделят эти аргументы из arguments в массив.

F2 описывает случай, когда в аргументах функции есть необязательные элементы — ?. Это означает, что для этих параметров при вызове функции компилятор не будет напоминать в предупреждениях о несоответствии заголовка функции её вызову. Переменная c — мало того, что необязательная, так еще и описывает несколько вариантов своего типа. То есть эта переменная может быть универсальной по типу — компилятор проследит, чтобы только эти типы данных использовались при вызове функции с этим аргументом.

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

Как видите, все то, что раньше нам приходилось снова и снова повторять в своем JS коде, простейшие конструкции, в которые иногда все же закрадывались досадные опечатки, теперь можно не писать. Синтаксический сахар TS помогает сделать код понятней и наглядней.

Те из вас, кто знаком с языком Python, могут спросить, почему авторы не пошли дальше и не добавили передачу аргументов по имени, примерно вот так:

let x = F3(a = 1, c = 3);

Я, конечно же, выскажу только свое мнение, я даже не знаю, обсуждалась ли такая идея среди разработчиков языка. Но у этой идеи есть явная проблемная сторона — реализовать такой синтаксис возможно через оборачивание всех аргументов в объект. Но тогда такие функции будут потеряны для внешнего кода написанного на JS. Хотя, конечно, можно представить заглушку и на этот случай, но тогда генерируемый код станет существенно сложнее, да и будет сложнее сохранить прозрачность трансляции и увеличится риск коллизий в именах аргументов и полей в передаваемых структурах. Что если внешний JS код вызывает такую функцию и в первом аргументе передает объект в котором есть поля, чьи имена совпадают с именами аргументов функции? Вводить запрет на «первый сложный аргумент функции»? Это выглядит, как минимум, странно.

Public, private, protect для свойств и методов классов

Об этом пункте можно было бы рассказать в разделе «Без магии, или Контроль над ситуацией».

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

Геттеры и сеттеры для свойств «без головной боли»

Тут все просто — вы используете один синтаксис get name()<>, а TypeScript генерирует для вас способ определения таких свойств через стандартный Object.defineProperty. При этом вам доступен и вариант с вычисляемыми именами таких свойств.

Декораторы для всего (ES7)

Это экспериментальный функционал, доступный при включении опции —experimentalDecorators и при компиляции в JS версии не ниже ES5

Декораторы — это синтаксический сахар и паттерн одновременно.

В ранних версиях TS предлагалось использовать аннотации, но от этого отказались в пользу декораторов.

Аннотации — как это было (или могло быть)

Аннотации — это пометки на сущности. Выглядело это примерно вот так (в старых версиях TS и AtScript, откуда это и пришло):

А теперь JavaScript:

То есть к объекту прикреплялось дополнительное свойство __annotations или annotations, которые можно было использовать по своему усмотрению. Вы заметили это «__annotations или annotations»? В этом и скрывалась проблема, различные имплементации допускали разные варианты, что вводило путаницу. Проблема усугублялась еще больше, если существовал внешний код, который мог использовать эти свойства, но не знал, какой именно вариант нужно искать в объекте, если вообще знал, что нужно что-то искать, в итоге применение такого сгенерированного кода в модуле написанном на JS, обрастало условиями проверок вида аннотирования, что не способствовало качеству кода.

Декораторы

Декораторы в свою очередь «декорируют» объект, оборачивают собой сущность и, если нужно, подменяют её.

Суть проще продемонстрировать на простом примере. Представим класс, который предоставляет доступ к некой админке и кратко выглядит вот так:

Декораторы в этом примере описывают уровни доступа текущего пользователя к конкретным методам класса:
— Метод login доступен гостю, иначе перенаправить на страницу home;
— Метод fetch доступен только авторизованному пользователю;
— Возможность вызвать конец света методом destroyUniverse дана только авторизованному пользователю с правами рут-пользователя.

Такой стиль класса и использования декораторов должен вызвать чувство дежавю как минимум у питонистов и джавистов. Они привыкли к такому подходу.

Долго не задерживаясь, давайте посмотрим на имплементацию декоратора guest:

Итак, функция декоратора должна вернуть функцию, которая будет вызвана для объекта декорирования при создании объекта.

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

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

Возможность ответить на вопрос «Как применять декораторы в реальной практике и зачем они вам нужны?» я оставлю вам. Эта концепция имеет очень мощную основу и может существенно повлиять на архитектуру вашего приложения.

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

Интерфейсы и абстрактные классы

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

Приведу сразу объемный пример с комментариями, где я постарался использовать почти все:

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

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

Зачем это нужно? Ну, например, вы можете описать интерфейс требуемого колбека. Если вам в функцию попытаются передать функцию с другим интерфейсом, компилятор предупредит об этом.

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

Generics

Непростой функционал, хоть в базовом случае и работает очень просто. Пример из документации:

Как и в случае с интерфейсами, лучше прочесть главу в документации для полного понимания. Если очень кратко: компилятор подменяет T в декларации класса на number и перезапускает анализ, будто у класса там везде number. Вот и все. Опять же, до JavaScript-кода вся эта магия (как же я старался избегать этого слова) не доходит, все проверяется/сверяется/выводится до трансляции в JS-код.

Компилирование в ES5 или даже в ES3 (с оговорками)

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

Оговорки касаются экспериментальных конструкций вроде декораторов и того, что просто невозможно описать в конкретной версии EcmaScript. Например, ни декораторы, ни set/get для полей класса нельзя описать в стандарте ES3 — просто в этом стандарте нет нужных вызовов в API примитива Object.

Выбор цели компиляции, гарантии, что будут доступны в качестве цели и будущие версии EcmaScript, — это делает TypeScript чуть ли не серебряной пулей. Вы уже можете использовать все то, что придумано нового в синтаксисе JavaScript, использовать проверку типов, декларации интерфейсов, абстрактные классы, декораторы и т.д. И в момент, когда «бизнес решит», что браузеры клиентов уже готовы для ES6 или ES7, вы просто переключите компилятор на другую цель, и генерируемый код обретет новые конструкции, избавится от каких-то подпорок для обратной совместимости. Код потенциально даже может стать быстрее, так как вместо явных обходных путей будет использовать нативное API движка JS.

ES6 в TypeScript

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

Выводы

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

Внесите порядок и структуру в ваш код и . (тут допишите свой вариант рекламного лозунга).

Конечно, компилятор не может защитить вас от архитектурных ошибок. Но может предупредить о возможных несоответствиях между задуманным (интерфейсом) и реализацией (классом, функцией, структурой). Типизация переменных и аргументов поможет быть уверенным, что вы правильно прочитали интерфейс и применяете сущности правильно, а не руководствуетесь лишь своим внутренним чутьем. Декораторы могут существенно повлиять на сам подход к оформлению классов и архитектуры в целом. Шаблоны классов (generics), абстрактные классы, помогут не допустить потерю контроля над архитектурой приложения. Ну и весь прочий синтаксический сахар облегчает жизнь и делает код более выразительным.

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

Добавить комментарий