image

«Существует только два вида языков: те, на которые жалуются и те, которыми никто не пользуется», — Бьёрн Страуструп, создатель C++

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

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

Но действительно ли это так?

Как мы оказались в такой ситуации?


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

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

JavaScript сегодня в буквальном смысле повсюду и является самым используемым языком программирования в мире.

Так почему же некоторые разработчики всё равно требуют его заменить?

Познай свой язык


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

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

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

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

Не ломайте веб


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

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

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

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

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

Другой язык — не решение


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

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

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

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

С чистого листа?


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

Меня не перестаёт впечатлять TypeScript, добавивший к JavaScript статическую типизацию, и PureScript, который по сути является Haskell в браузере, позволяющим писать полностью работоспособный код в парадигме функционального программирования.

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

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

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

Выбор за вами.

Комментарии (204)


  1. vasyapivo
    27.11.2019 12:40
    +3

    стоит ли оно того

    Стоит, JS — язык написанный не для того, чтобы мы сейчас на нём писали огромные SPA. JS это куча хаков и обратной совместимости. Потому новый язык нужен хотя бы, чтобы убрать проблемы с приведением типов или прототипное наследование, которое создаёт проблем больше чем решает. JS не должен был быть индустриальным стандартом для вёба, то что он им стал — это роковое стечение обстоятельств.
    Людям нужны не языки ради языков, скорость и эффетивность разработки. Потому люди не просто ругают C++ и пишут на нём. Они ругают C++ и уходят на Go чтобы легче и быстрее решать свои проблемы.
    По мне, так строгая типизация для больших приложений просто необходима, нам нужны элементы нормального ООП с инкапсуляцией и наследованием. Нужен синтаксический сахар и большая стандартная библиотека. По-факту, нам нужен Kotlin для web, и думаю, скоро его допилят.


    1. 0xd34df00d
      27.11.2019 18:21
      +2

      Потому люди не просто ругают C++ и пишут на нём. Они ругают C++ и уходят на Go чтобы легче и быстрее решать свои проблемы.

      Не все. Не во всех задачах можно просто взять и уйти на go/rust/haskell, увы.


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


      1. endymion
        27.11.2019 19:04

        решать свои проблемы

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


    1. zim32
      27.11.2019 22:33
      +1

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


      1. nsinreal
        28.11.2019 00:49
        +1

        У тайпскрипта в корне лежат те же проблемы, что и у джаваскрипта, потому что он старается быть максимально "джаваскриптом с типамии".


      1. tonad
        28.11.2019 12:15
        +1

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


        Что бы браузер перестал потреблять ресурсы как ААА игры?


        1. JustDont
          28.11.2019 12:33

          А вы готовы на то, чтоб сайты писались столько же времени, сколько и ААА игры?


          1. Neikist
            28.11.2019 12:46

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


            1. JustDont
              28.11.2019 13:00
              -1

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

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

              Единственное, что выдерживает сравнение по скорости на простых случаях, это Delphi. Но более масштабные или сложные случаи в вебе всё равно масштабируются куда быстрее.

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


              1. Neikist
                28.11.2019 13:44

                Флаттер говорит вам что можно было сделать и нормально. И разрабатывать быстро интерфейсы, и разрабатывать быстрые интерфейсы.


                1. JustDont
                  28.11.2019 13:49

                  И разрабатывать быстро интерфейсы

                  Как только гугльаппс (или что-то отдаленно сравнимое по сложности) будут написаны на флаттере — я вам прям сразу же поверю.
                  Я видел этот ваш флаттер, и идеологически это шаг вот прямо в те времена, когда swing был модным и очень молодёжным. Как эпически выразился один товарищ в комментах к другой статье — «флаттер предлагает революционный подход в виде императивного написания интерфейсов». А мужики-то и не знали, что единственный способ закодить интерфейс в конце 90-х хипстеры из 2020 будут называть «революционным».

                  и разрабатывать быстрые интерфейсы

                  У меня и в браузере ничего мягко говоря не тормозит.


                  1. Neikist
                    28.11.2019 14:46

                    Эмм… Что это за статья такая странная? Вообще флаттер как раз декларативный подход предлагает. В этом плане он у реакта многое слизал насколько знаю.


                    1. JustDont
                      28.11.2019 15:27
                      +1

                      Где? Даже титульный пример на flutter.dev написан на жуткой смеси функциональщины с попытками изобрести свой собственный html с блекджеком и танцами.
                      Это, разумеется, не тот императивный подход, который был в 90-е, но и совсем не декларативщина.

                      В этом плане он у реакта многое слизал насколько знаю.

                      А с каких пор реакт декларативен? «Есть шаблончики» != «декларативен». Шаблончики конечно декларативны, сами по себе если. А вот декларативно ли оно будет всё в целом — зависит от того, сколько можно и сколько нельзя сделать одними шаблонами.


                      1. Neikist
                        28.11.2019 15:30

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


                    1. vintage
                      28.11.2019 19:44

                      Почему вы считаете Реакт сколь-нибудь декларативным?


                      1. Neikist
                        28.11.2019 21:47

                        Про реакт я без понятия, я его в глаза ни разу не видел. Я считаю декларативным флаттер, и он многое взял у реакта.
                        И да, во флаттере в ui можно применять циклы, условия и прочее, но дерево виджетов строится на основе состояния, которое меняется только строго определенным образом. Мне этого хватает чтобы флаттер считать декларативным UI фреймворком. То что состояние может и меняется кучей разных способов — это уже другое.


                        1. vintage
                          29.11.2019 07:26

                          1. Neikist
                            29.11.2019 08:24

                            Я просто разделяю декларативное программирование и декларативное описание UI. Сам дарт императивный, но описание UI на флаттере считаю декларативным.


                            1. vintage
                              29.11.2019 09:48

                              Я может не на тот флаттер смотрю, но где тут декларативность?


                              import 'package:flutter/material.dart';
                              
                              void main() async {
                                final numbers = FibonacciNumbers();
                              
                                runApp(
                                  MaterialApp(
                                    debugShowCheckedModeBanner: false,
                                    home: Scaffold(
                                      appBar: AppBar(
                                        title: Text('Fibonacci List'),
                                      ),
                                      body: FibonacciListView(numbers),
                                    ),
                                  ),
                                );
                              }
                              
                              class FibonacciNumbers {
                                final cache = {0: BigInt.from(1), 1: BigInt.from(1)};
                              
                                BigInt get(int i) {
                                  if (!cache.containsKey(i)) {
                                    cache[i] = get(i - 1) + get(i - 2);
                                  }
                                  return cache[i];
                                }
                              }
                              
                              class FibonacciListView extends StatelessWidget {
                                final FibonacciNumbers numbers;
                              
                                FibonacciListView(this.numbers);
                              
                                @override
                                Widget build(BuildContext context) {
                                  return ListView.builder(
                                    itemBuilder: (context, i) {
                                      return ListTile(
                                        title: Text('${numbers.get(i)}'),
                                        onTap: () {
                                          final snack = SnackBar(
                                            content: Text('${numbers.get(i)} is '
                                                '#$i in the Fibonacci sequence!'),
                                          );
                                          Scaffold.of(context).showSnackBar(snack);
                                        },
                                      );
                                    },
                                  );
                                }
                              }


                              1. Neikist
                                29.11.2019 09:53

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


                                1. vintage
                                  29.11.2019 10:08

                                  Вы похоже выдаёте желаемое за действительное. Посмотрите ещё раз код внимательно.


          1. tonad
            28.11.2019 13:15

            Это быстрее чем сейчас? Конечно готов…


      1. zim32
        29.11.2019 15:07

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


    1. codemafia
      28.11.2019 07:55

      Потому люди не просто ругают C++ и пишут на нём. Они ругают C++ и уходят на Go чтобы легче и быстрее решать свои проблемы.

      И начинают ругать Go за проблемы работы с памятью и т.п.


    1. SerVB
      28.11.2019 13:05

      Kotlin/JS стабилен давно, ждать не надо) Использовать приятно.


  1. lanseg
    27.11.2019 13:05
    +1

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


    1. igor-sheludko
      27.11.2019 20:56
      +2

      Уместно говорить что JS — это плохо, поработав с ним несколько лет. Просто «мне не по душе» — довольно слабая аргументация.
      Простой пример для бэкенда. Вы получаете данные от веб-апи другого сервиса. На том же c# вам нужно описать структуры, в которые вы будете парсить Json. А если ответ сервиса поменяется (после апдейта) — у вас все посыпется. На node и js такие задачи отыгрываются с меньшей болью за счёт проверок нужных элементов формата. Динамическая типизация — это не всегда плохо, иногда это полезно. А ещё есть TypeScript.


      1. piton_nsk
        27.11.2019 21:06

        На том же c# вам нужно описать структуры, в которые вы будете парсить Json. А если ответ сервиса поменяется (после апдейта) — у вас все посыпется.

        Может я до конца не понял мысль, но поечму все должно посыпаться?


        1. igor-sheludko
          28.11.2019 00:19
          -1

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


          1. Guitariz
            28.11.2019 09:23

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


            1. piton_nsk
              28.11.2019 12:38

              Вопрос, должно ли приложение падать, когда на бек приходят неконсистентные данные

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


          1. piton_nsk
            28.11.2019 12:52

            Преимущества могут быть только в более коротком и постом коде на JS.

            Парсинг 3 варианта json
            var user = JsonConvert.DeserializeObject<User>("{ Name:'Test', Age:10}");
            user = JsonConvert.DeserializeObject<User>("{ Age:10}");
            user = JsonConvert.DeserializeObject<User>("{ Name:'Test', Age:10, NewProperty:5}");
            


      1. kasthack_phoenix
        27.11.2019 21:29
        +4

        А если ответ сервиса поменяется (после апдейта) — у вас все посыпется

        Что по вашему должно произойти при правильной реализации? Вернуться где-нибудь NAN, если вместо числа пришла строка?


        1. norguhtar
          28.11.2019 05:57

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


      1. doctorw
        27.11.2019 22:59
        +3

        А если ответ сервиса поменяется (после апдейта) — у вас все посыпется.

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


        1. igor-sheludko
          28.11.2019 00:22
          -1

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


      1. MooNDeaR
        27.11.2019 23:29
        +2

        Я что-то не понял почему "посыпется" — это плохо? Лучше, чтобы произошло "что-то", но не знаю что?


      1. viirtus
        27.11.2019 23:51

        Видимо, вы никогда не писали бэкенд на языках со статической типизацией.
        Требующие динамики штуки делаются точно так же с использованием map/hash-table/итд.
        Там, где это не нужно (99.9% случаев), статические контракты делают код читаемым и легко поддерживаемым, а апи — версионируемым и надёжным.


        1. igor-sheludko
          28.11.2019 00:11

          Плохой пример, неточный, согласен.


      1. 0xd34df00d
        28.11.2019 02:49

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

        Не понял этот аргумент.


        Конкретно на C# я не писал, а вот на ещё более строго типизированном хаскеле я таки писал и пишу. Если речь о нужных элементах, то я просто в своём представлении жсон-структуры описываю лишь нужные мне элементы, и наличие/типы остальных меня не волнуют. Если речь о типах элементов, то я пишу Either и тому подобные вещи и явно обрабатываю все возможные варианты типов, которые я поддерживаю.


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


        1. igor-sheludko
          28.11.2019 08:55

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


          1. 0xd34df00d
            28.11.2019 23:28

            Все можно решить, но, пожалуй, с большим объемом кода

            Да не сказал бы. Я просто пишу


            data MyRecord = MyRecord
              { name :: String
              , age :: Int
              , address :: ...
              } deriving (Generic, FromJSON)

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


            К слову об обработке… Если у меня есть файл со 100500 строками жсона, и мне надо их распарсить с возможностью обработки этих самых ошибок, то у меня будет очень тупой код типа такого:


            parseFile filename = do
              contents <- readFile filename
              case sequence eitherDecode' $ lines contents of
                   Left err -> putStrLn [i|Unable to parse JSON: #{err}|]
                   Right records -> ... тут делаем что-то с записями ...

            И, например, если записей действительно 100500, и надо подсчитать какую-то статистику по ним, то такой код будет работать за O(1) по памяти, что тоже приятно.


            А как у вас там с этим?


          1. Crandel
            01.12.2019 13:54
            -1

            Все можно решить, но, пожалуй, с большим объемом кода и большим временем, затраченным на такую ситуацию (описание структур и обработка ошибок)

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


            Scott Wlaschin - Talk Session: Domain Modeling Made Functional


      1. vintage
        28.11.2019 19:46

        На том же C# вам ничего не мешает пользоваться динамической типизацией там, где она вам нужна. А не как в ноде — никогда не знаешь что прилетит в функцию.


  1. mr_tron
    27.11.2019 13:37
    +4

    Другие языки тоже столкнутся с такими проблемами?

     Это прост красиво
    null == 0
    false
    null < 0
    false
    null <= 0
    true
    
    Самое очевидное приведение типов.
    [] + []
    ""
    [] + {}
    "[object Object]"
    {} + []
    0
    {} + {}
    NaN
    
    А это числа, которые сортируются как строки
    [1,0, 4, 13, 9, 3].sort()
    Array(6) [ 0, 1, 13, 3, 4, 9 ]
    
    переполняются как инты
    1 << 31
    -2147483648
    1 << 32
    1
    
    и теряют точность как эммм... флоаты?
    
    103209823048320840000 + 1
    103209823048320840000
    103209823048320840000 + 20000
    103209823048320860000
    


    1. gearbox
      27.11.2019 14:00
      +1

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

      Поведение sort описано в документации, то что в js нет интов (не было, теперь есть но их надо объявлять явно) — должно быть известно с первых дней программирования на этом языке (ну или переходите на язык на котором можно писать не читая документации)
      Со всем остальным — если вы пишете нормальный код и используете нормальные пакеты — вы просто не должны сталкиваться. Я за четыре года не столкнулся ни с чем не только из вышеперечисленного но и из гораздо более полных и обширных плачей Ярославны по этому поводу.


      1. Free_ze
        27.11.2019 14:14
        +1

        что именно вы пишете что втыкаетесь в эти проблемы?

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

        Внимание, наброс: секрет ли, что фронт-енд сейчас — самая долгая в разработке и стабилизации часть типичного веб-приложения? Это объяснимо, но не последней причиной этому — дизайн JS.


        1. JustDont
          27.11.2019 15:29

          секрет ли, что фронт-енд сейчас — самая долгая в разработке и стабилизации часть типичного веб-приложения?

          Што?

          Словом «самая» — вы сравниваете что с чем, конкретно? Фронт с остальной частью? А объем функционала вы во внимание не хотите принять? Если не хотите — так я вам сразу скажу, что фронтэнд гугла был самым простым и легким в стабилизации. А если хотите — тогда переформулируйте ваше утверждение так, чтоб оно не было бредом.

          А еще вы можете попробовать сравнить веб фронт-энд с написанием, скажем, аналогичного фронтэнда на С++. Давайте посмотрим, что там будет быстрее разрабатываться и стабилизироваться?


          1. Free_ze
            27.11.2019 15:44
            -1

            Словом «самая» — вы сравниваете что с чем, конкретно? Фронт с остальной частью?

            Именно.

            А объем функционала вы во внимание не хотите принять?

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

            Я отталкиваюсь от своего опыта — среднего уровня (по сложности) фронт и относительно ёмкую бизнес-логику, что пилят фуллстеки. Да, среднестатистические разработчики. Фронт статистически генерирует больше багов. Можно сказать, что мы криворукие, но ведь тогда всё было плохо равномерно, почему у доброго десятка команд одинаковые проблемы?

            вы можете попробовать сравнить веб фронт-энд с написанием, скажем, аналогичного фронтэнда на С++

            Достойный оппонент, да) Как насчет C#? И не хотелось бы сейчас баттлить React vs Blazor, фреймворки оставим за скобками.

            Я согласен с тем, что поехавшая верстка, кроссбраузерность — это проблемы не про JS. Но куча всякого в стиле: «Сервер прислал не то, что ожидали и понеслась...» — этого сплошь и рядом.


            1. JustDont
              27.11.2019 15:56
              +2

              Как насчет C#?

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

              Но куча всякого в стиле: «Сервер прислал не то, что ожидали и понеслась...»

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


              1. Free_ze
                27.11.2019 16:12

                Веб всё равно окажется быстрее с запасом.

                Вы отождествляете браузерные API с JS и фреймворки с языками, не надо так.
                Прототипы — да, быстрее. Но поддерживать имеющуюся объемную кодобазу, если оценивать разработку фич «брутто» (с тестированием и стабилизацией), то выходит уже не так прекрасно.

                пусть страница падает себе, юзеры переживут

                ОК, но наши юзеры, например, не будут в восторге от такого поворота, вот на отладку хитрых кейсов всё время и уходит.

                там ответы сервера очень даже так проверяют, и не падают.

                Руками проверяют, тонной тестов и ручного тестирования. Это дорого. Но делать нечего, пока только JS/TS.


                1. JustDont
                  27.11.2019 16:33

                  Вы отождествляете браузерные API с JS и фреймворки с языками, не надо так.

                  А вы, когда упомянули C# — вы конечно же имели в виду, что вы хотите на нём посоревноваться с JS только языком, не привлекая стандартные библиотеки? Точно-точно это имели в виду?

                  ОК, но наши юзеры, например, не будут в восторге от такого поворота, вот на отладку хитрых кейсов всё время и уходит.

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

                  А потом у них в итоге JS плохой, ага. Про танцора и яйца в этой теме уже, кажется, поминали.


                  1. Free_ze
                    27.11.2019 16:38

                    Точно-точно это имели в виду?

                    Почему вы считаете, что могло быть иначе?) Глупо было бы отлицать то, что JS правит веб-фронтом на данный момент. Но это не делает лучше язык лучше.

                    Нормальные люди выбирают транспортный слой со строгой типизацией.

                    Вот бы сейчас проблемы платформы инфраструктурными прокладками решать) Это точно удешевит процесс разработки?


                    1. JustDont
                      27.11.2019 16:45

                      Почему вы считаете, что могло быть иначе?)

                      Потому что в этом контексте меряться бессмысленно: на C# вы просто не напишете фронтэнд на «голом языке», и на JS тоже. Некоторый объем сторонних библиотек или браузерного API вам будет необходим в любом случае.

                      Вот бы сейчас проблемы платформы инфраструктурными прокладками решать)

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

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


                      1. Free_ze
                        27.11.2019 17:34

                        на C# вы просто не напишете фронтэнд на «голом языке», и на JS тоже.

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

                        как вы собрались это решать без создания привязки типов, которая ваше «непредсказуемое» всегда будет превращать в предсказуемое что для фронта, что для бэка?

                        Никак, можно только снижать вероятность факапов теми или иными средствами.

                        Это определенно удешевляет процесс разработки, ага.

                        Да, для нас это наиболее дешевый вариант, наименьшее из зол.
                        Язык/платформа, безопасная к типам в рантайме, решила бы эту проблему бесплатно.


                        1. JustDont
                          27.11.2019 17:48
                          +2

                          Достаточно писать логику

                          Так и пишите. Или для JS вы скажете, что вам для написания логики типичного условного фронтэнда надо складывать массивы с объектами, а в JS это странно работает?


                          1. Free_ze
                            27.11.2019 17:53
                            -2

                            С моего объяснения причин «складывания массивов с объектами» диалог и начался.


                            1. JustDont
                              27.11.2019 17:57
                              +2

                              Ваше «объяснение» никак не привязано к собственно JS.


                              1. Free_ze
                                27.11.2019 18:04
                                -3

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


                                1. 0xd34df00d
                                  27.11.2019 18:23
                                  +3

                                  А зачем их контролировать в рантайме в том случае, когда у вас есть достаточно сильный тайпчекер в компилтайме?


                                  1. Free_ze
                                    27.11.2019 18:36
                                    -2

                                    У JS его нет ни в каком тайме)

                                    С TS уже неплохо, но тогда размывается граница между проектами (допустим, фронту модельки генеряться полагаясь на другой проект).
                                    Формализации взаимодействия с третьей стороной это помогает на уровне: «Будем полагать, что этот компонент подчиняется этому контракту». Если ожидания не оправдались — все пойдет JS-сценарию.


                                    1. 0xd34df00d
                                      27.11.2019 19:45

                                      В рантайме таки есть, просто там ещё есть преобразования.


                                      Типов нигде нет в том случае, если вы пишете на С с void*.


                          1. dakuan
                            27.11.2019 19:07

                            Или для JS вы скажете, что вам для написания логики типичного условного фронтэнда надо складывать массивы с объектами, а в JS это странно работает?


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


                            1. JustDont
                              27.11.2019 23:36

                              Пишите в TS, где это дальше компилятора не уйдет. Problem solved.


      1. mr_tron
        27.11.2019 15:02

        Ну вот первое это из моего опыта. Словил багу, где с сервера в json приходил null вместо числа.
        Сортировка может и описана в документации, но это поведение неожиданное, тоесть надо действительно сесть и прочитать сперва документацию от корки до корки, чтобы узнать подробности про вот такое поведение. В более предсказуемом языке глубоко документацию надо читать чтобы узнать о фичах, а не о подводных камнях. Чувствуете разницу?

        И что кстати значит, что в js нет интов? А что же тогда переполняется? Типичный int.


        1. JustDont
          27.11.2019 15:33

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

          Примеры «более предсказуемых языков» не назовете? Вместе посмеемся.

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


          1. fougasse
            27.11.2019 16:59
            +1

            Ниразу не ходил в исходник C++, Java, Kotlin, C#, python.
            Даже не понимаю, что вы понимаете под исходником языка — компилятор?
            Или реализация сравнения null или сложения находится где-то в другом месте?


            1. JustDont
              27.11.2019 17:09
              +2

              Даже не понимаю, что вы понимаете под исходником языка — компилятор?

              В нормальных языках компилятор языка написан на самом языке, так что да.
              Но моя фраза про «исходный код» была о том, что не всегда ответы на интересное поведение языка можно найти в документации. Иногда документации об этом попросту нет — и тогда кому-нибудь (не обязательно вам) приходится смотреть в исходный код, да.


              1. fougasse
                27.11.2019 17:27
                -2

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

                Референс от Mozilla:

                Addition (+)
                The addition operator produces the sum of numeric operands or string concatenation.

                Syntax
                Operator: x + y

                Examples
                // Number + Number -> addition
                1 + 2 // 3

                Куда мне нужно смотреть в компиляторе для случая
                103209823048320840000 + 1 == 103209823048320840000


                1. JustDont
                  27.11.2019 17:49
                  +1

                  Сфигали вы смотрите на сложение, а не на типы?


                  1. fougasse
                    27.11.2019 20:43
                    -1

                    Ну, ок, смотрю я на тип — дабл.
                    Я реально не понимаю, почему, если литерал явно больше максимального значения — это вообще "работает". Я в спеке нашел только количество значений у типа. Про ситуацию с переполнением — там, вроде, ничего нет.
                    Хотя, справедливости ради, могли бы и, вообще, в строку неявно конвертировать и конкатенацию делать — ещё более дикое поведение.
                    Почему игнорируются последние разряды, а не первые?


                    1. JustDont
                      27.11.2019 23:40
                      +2

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

                      Нет, не дабл.
                      > The JavaScript Number type is double-precision 64-bit binary format IEEE 754 value.
                      А уж если б вы открыли спецификацию IEEE754, или в крайнем случае прошли бы по ссылке на википедию, которая все основы разжёвывает, вы бы там нашли и описание поведения при переполнении.


        1. gearbox
          27.11.2019 17:31
          +3

          >Словил багу, где с сервера в json приходил null вместо числа.
          Это типичное нарушение правил гигиены. Информация пришедшая из-за пределов периметра должна валидироваться, это от языка не зависит. Если не уверены что проверили все и везде — есть unknown в typescript для контроля периметра, если хочется по феншую. Но проверять придется.

          >но это поведение неожиданное
          Неожиданно пользоваться функцией не зная ее сигнатуры. sort принимает на входе функцию сравнения. Это необязательный параметр, но это параметр. Если вы открыли доку что бы посмотреть сигнатуру функции — вы это увидели. Дальше простая цепочка — если есть параметр и его можно не указывать — значит есть поведение по умолчанию. Какое? Ответ видим в том же абзаце где описывается этот параметр. Ситуация описанная Вами может возникнуть только при программировании наугад.

          >В более предсказуемом языке глубоко документацию надо читать чтобы узнать о фичах, а не о подводных камнях. Чувствуете разницу?
          Нет, не чувствую. Берем язык x и используем функцию y. О наличии функции y в языке x мы как узнали? common knowledge?

          >И что кстати значит, что в js нет интов?
          обычные числа в js — float, инты надо задавать явно — либо в массивах (intXArray) либо Bigint. Переполнение возникает потому что Вы применяете bitwise операцию к float, она естественно делается с приведением типа а приводится к 32 разрядному инту, результат внезапно приводится обратно к float. То есть воткнувшийся в эту ситуацию не понимает как хранятся числа в js — это я уже упомянул, знать надо. Все остальное — следствие. Попытка применить битовую операцию к float у любого вменяемого программиста вызовет вопрос — как оно будет сделано.


          1. Neikist
            27.11.2019 18:02
            -1

            О наличии функции y в языке x мы как узнали? common knowledge?

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


            1. gearbox
              27.11.2019 18:10
              +2

              тогда не понимаю в чем проблема? Нет IDE для js или Вы не умеете ей пользоваться? Или она не подсказывает сигнатуры? С тем же сортом — как его можно использовать зная только название? Как он отсортирует — по возрастанию или по убыванию? Что вернет — новый отсортированный массив или отсортирует тот на котором вызван? Есть какое то общепрограммистское соглашение по сигнатурам функций сортировок которого все придерживаются а js цинично и с особой жестокостью нарушает?


              1. Neikist
                27.11.2019 19:05

                Вот не поверите, сколько пишу на котлине — в документацию или сорцы используемого кода лезть приходилось только за совсем неочевидным (в случае если редактирую уже сущестувующий код). IDE сразу подсказывает может ли функция вернуть null или нет (а так же ругнется компилятор), функция не может вернуть значения разных типов. Int это 5 и 0, а float это 5f или 5.0f. И просто так инт с флоатом не сложить, компилятор сразу ругнется вместе с IDE.
                IDE для языка со слабой динамической типизацией будет гораздо хуже в этих отношениях.
                Что касается sort — на обычном списке или коллекции его вызвать нельзя (интерфейс не имеет методов для изменения), сначала необходимо преобразовать в изменяемую коллекцию (правда иммутабельности полноценной тоже нет для списков, но это отдельный разговор), а потом отсортировать именно ее. На обычном списке IDE подсказывает только sorted, которая список изменить не может (напомню, интерфейс не имеет методов для изменения) а только возвращает новый, отсортированный список.
                Ну и ни разу не видел sort который бы сортировал не по возрастанию. А как отсортировать по возрастанию цифры понятно — Int, Float и прочие реализуют интерфейс Comparable.


      1. fougasse
        27.11.2019 16:56

        Я с вами согласен, но как проблема со сложением зависит он того есть в JS тип int или нет?

        103209823048320840000 + 1 = 103209823048320840000
        103209823048320840000 + 20000 =103209823048320860000

        где-то в документации можно найти что-то, что поможет так не «встрять»?


        1. gearbox
          27.11.2019 17:32

          Это поведение float. Странно что вы этого не видите по первой строке.

          >где-то в документации можно найти что-то, что поможет так не «встрять»?
          Number_type


          1. fougasse
            27.11.2019 20:47
            -3

            Упоминания про overflow в спеке нет.
            Упоминания про литералы вне диапазона — """
            Beyond this range, integers in JavaScript are not safe anymore and will be a double-precision floating point approximation of the value.
            """


            Что такое not-safe?
            Как-то много вопросов из спеки для такой простой проблемы как число, не так ли?


          1. AlexBin
            28.11.2019 18:17

            Это поведение float.

            Это поведение float в JS.

            Правильное поведение при переполнении чего либо выбросить ошибку переполнения.

            При сложении [] + {} правильное поведение — это выбросить ошибку.

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

            И т. д.

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

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

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


            1. staticlab
              28.11.2019 18:28

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

              А частичное отключение автопилота при повороте штурвала на Airbus A310 как вам? Это тривиальная вещи или нет? Нужно ли об этом было инструктировать пилотов рейса SU593 об этом?


              1. AlexBin
                28.11.2019 19:21

                А частичное отключение автопилота при повороте штурвала на Airbus A310 как вам?

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

                Извините, не могу ответить.


              1. AlexBin
                28.11.2019 19:47
                +1

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

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

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

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


            1. gearbox
              28.11.2019 22:21
              +1

              Это поведение float в IEEE 754. Ну или покажите мне язык где бросает эксепшин на это: 103209823048320840000 + 1?


              1. Neikist
                28.11.2019 23:21
                -1

                Котлин ругнется на этапе компиляции если попытаетесь такой литерал использовать, что значение выходит за границы диапазона. Да подозреваю многие языки ругнутся. А Float такое позволит, да. Но для этого придется записать 103209823048320840000f + 1f, т.е. явно задекларировать что этот литерал значение с плавающей точкой.


              1. AlexBin
                28.11.2019 23:52
                -1

                Это поведение float в IEEE 754.

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

                Ну или покажите мне язык где бросает эксепшин на это: 103209823048320840000 + 1?

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

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

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


      1. tcapb1
        28.11.2019 11:11

        Всё равно вам придётся держать в голове и то, что числа сортируются как строки, и то что целые числа по умолчанию не int, а float. А также множество всяких других нелогичностей JS. Т.е. мы изначально при разработке должны учитывать больше, чем программисты на других, более грамотно спроектированных языках.

        Если не будете держать в голове — получите кучу головной боли, когда приложение перестанет работать как задумано. Например, в массиве изначально были числа от 1 до 5, и всё сортировалось как надо, а потом туда добавились числа 10, 11 и т.д. Сортировка сбилась. Или у вас есть автоинкремент, который изначально работает как надо, а потом, когда он доходит до больших чисел — упираемся в точность float. Приятной отладки.

        JS конечно не один такой. В других языках тоже есть много странного легаси, вещей, которые надо учитывать. Можно вспомнить PHP с прыгающими параметрами needle и haystack в функциях, багом с порядком аргументов в тернарном операторе, который тянулся до PHP 7.4 (да и теперь по сути была лишь обрезана функциональность). И да, любой, даже самый прекрасный язык со временем обрастает легаси и неинтуитивным поведением (всё сразу спроектировать идеально видимо просто невозможно, а потом для обратной совместимости приходится тянуть хвосты).

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


        1. vintage
          28.11.2019 20:01

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


    1. 0xf0a00
      27.11.2019 14:03

      Вам же пишут:

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

      Это не инструмент убогий, это вы дурак и невежда и не поняли божественный JS.


      1. vlreshet
        27.11.2019 14:05
        -1

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


        1. Angmarets
          27.11.2019 14:21
          +2

          При должном усердии я могу есть суп вилкой. Однако если мне в ресторане подадут к супу вилку — я буду ныть.


          1. vlreshet
            27.11.2019 15:08

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


            1. Free_ze
              27.11.2019 15:22
              +1

              image


              1. vlreshet
                27.11.2019 15:48
                +2

                Это забавно, но не более. В этой картинке не ломается обратная совместимость, в случае установки круглых колёс. А вот заменить главный язык в браузере — это совсем другое. Скажите бизнесу что вам не нравится писать на JS, и надо всю кодовую базу за последние 20 лет выкинуть)


                1. Free_ze
                  27.11.2019 16:03

                  Можно добавить режимы совместимости (JS не привыкать после strict mode) или параллельно готовить альтернативу со слоем совместимости (WASM).

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


                  1. vlreshet
                    27.11.2019 16:26
                    +3

                    jQuery вышел в 2006-ом году. На нём до сих пор дохренилеард сайтов (да тот же хабр имеет его на фронте). Тысячи плагинов, скриптов, и т.д. Такие ли 5 лет живёт JS код?


                    1. Free_ze
                      27.11.2019 16:34
                      +1

                      jQuery вышел в 2006-ом году.

                      ОК, jQuery и еще пара сотен проектов могут не входить в указанное мной «подавляющие большинство».

                      да тот же хабр имеет его на фронте

                      Сколько редизайнов было на хабре за время его существования?

                      Тысячи плагинов, скриптов, и т.д.

                      … и ни одного нормального WYSIWYG-редактора))


                      1. JustDont
                        27.11.2019 16:38
                        +1

                        … и ни одного нормального WYSIWYG-редактора))

                        В оффлайне (с гораздо более долгой историей) дай-то бог один нормальный найдётся (и это не ворд). А вы от веба что-то хотите.


                      1. justboris
                        28.11.2019 00:54

                        ОК, jQuery и еще пара сотен проектов могут не входить в указанное мной «подавляющие большинство».

                        На всякий случай замечу, что согласно исследованию больше 80% сайтов все ещё используют jQuery. При этом в вакансиях от разработчиков сейчас требуют в основном другие фреймворки. То есть разрабатывающиеся сейчас проекты не совпадают с тем, что мы видим в свободном интернете.


                        Чем это еще объяснить кроме как не большим количеством легаси сайтов?


                        1. Free_ze
                          28.11.2019 11:56

                          Чем это еще объяснить кроме как не большим количеством легаси сайтов?

                          Многие продолжают использовать jQ, потому что их всё в ней устраивает, например.

                          При этом в вакансиях от разработчиков сейчас требуют в основном другие фреймворки.

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


                          1. justboris
                            28.11.2019 11:58

                            Хорошо, а как это согласуется с вашим "подавляющее число проектов на JS живет меньше 5 лет в первозданном виде"?


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


                            1. Free_ze
                              28.11.2019 12:44

                              А если допустить вероятность, что большинство (кому ехать, а не шашечки) продолжает использовать даже в новых проектах то, что они хорошо знают — jQuery?

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

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

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


                1. fougasse
                  27.11.2019 17:01

                  Вполне получается сказать бизнесу, что не нравится писать на Java и быстрее будет на Котлине, например.
                  Никто никакую базу не выкидывает, если нормально подойти к процессу миграции.
                  Или Java недостаточно популярна?


            1. ivanuzzo
              27.11.2019 20:39
              +4

              в Китае к супу выдают ложку, правда, немного не такую, как у европейцев.
              Вот такую выдадут:
              image
              Ваш пример некорректен.


            1. gatoazul
              27.11.2019 21:05

              Согласен с вашим ответом по сути, но в Китае суп все-таки пьют, а не едят палочками. По крайней мере «есть суп» на китайский переводится как «пить суп».


        1. 0xf0a00
          27.11.2019 15:24

          Мой сарказм вы приняли за чистую монету как я погляжу.

          Пока одни ноют что на нём писать невозможно

          Плохому танцору… дальше сами знаете. Таким людям дай идеальный язык все равно найдут проблему.
          другие на нём огромные SPA выстраивают, и сложнейшие бекенды на ноде

          Не аргумент ни разу. Оно так потому что JS обезьянок много, они готовы работать за еду, одну и туже обезьянку можно послать писать и фронт и бэк, а если у обезьянки недосточно мозгов ее всегда можно заменить потому что за воротами очередь. Отсюда колоссальная экономия на разработчиках в ущерб качеству продукта. Но у нас не век когда писали хорошо и грамотно, у нас век «эффективного менеджмента» когда отказоусточивость подменили аргументом «зато быстро поднимается», когда многопоточность заменили «да просто n инстансов запустим на проде», когда удобный отзывчивый UI с низким потреблением ресурсов заменили на объевшегося грибами выпускника художественного и пару JS обезьянок по 300$ с той же художки которым в лапки дали электрон.
          Но самая большая проблема всего этого в том что JS обезъянки мнят себя не ясно чем, считают что круче JS ничего нет и не будет, категорически отказываются переучиваться или учить еще какой то язык с аргументным аргументом «я же могу сделать это на JS». Можешь, но выйдет лютейшее гов… А все от того что образования профильного у них как правило нету и понятия об области применения инструмента как правило тоже. Я ведь тоже могу написать бэк на C++ или Delphi, но пишу то на Java.


          1. igor-sheludko
            28.11.2019 09:25

            Я тоже многому удивляюсь, но:
            1) JS — не первый и не единственный язык про который можно сказать так, как вы высказались. До js-обезьянок были php, python, ruby и прочие обезьянки, которые осваивали эти языки потому что они простые и шли кодить на них. Ещё 15 лет назад молодое дарование убеждало меня, что преподавать С++ в ВУЗе нужно прекратить и заменить его на python.
            2) Так уж повернулась история и мы имеем то, что имеем. Даже MS не смогла особо ничего лучше придумать для веба, чем создать TS. При том что до этого они вполне удачно создали C# для кроссплатформенной разработки. Я все же думаю, что там не обезьянки такие решения принимают.
            3) В одном языке для фронта и бэка для небольших проектов много плюсов. А так как есть тенденция к микросервисам, то с точки зрения управления разработкой больших проблем не возникает. Разные части бэкенда большого проекта могут быть реализованы на наиболее подходящих языках.


    1. vlreshet
      27.11.2019 14:03

      Самое очевидное приведение типов.
      [] + []
      ""
      [] + {}
      "[object Object]"
      {} + []
      0
      {} + {}
      NaN
      О, обожаю этот аргумент. Вопрос: часто вам приходится объект с массивом складывать?

      и теряют точность как эммм... флоаты?

      103209823048320840000 + 1
      103209823048320840000
      Ну, как минимум, тот же PHP страдает той же проблемой
      php > var_dump(103209823048320840000 === (103209823048320840000 + 1));
      bool(true)
      И куча других языков тоже.


      1. worldmind
        27.11.2019 15:53
        +1

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


        1. vlreshet
          27.11.2019 16:27

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


          1. worldmind
            27.11.2019 16:32

            1. murzilka
              28.11.2019 10:40

              А когда часики дотикают все, кто использует второй питон, превратятся в тыкву?


              1. worldmind
                28.11.2019 10:42

                Именно так, не секунда в секунду, но в скором времени, когда найдут какой-нибудь секурити баг который никто не станет фиксить.


            1. staticlab
              28.11.2019 19:11

              Статья как раз в тему: https://habr.com/ru/company/1cloud/blog/477944/


        1. gearbox
          27.11.2019 17:47

          >но они сигнализируют о том какого качества было проектирование языка
          А я и не говорю о том что язык прекрасен. Я говорю о том что эти ляпы не мешают жить если вы пишете на js так как вы пишите на нормальном языке. То есть ляпы есть но они не вынуждают вас их использовать. В этом и заключается мой вопрос — покажите мне ситуацию к которой вас подталкивает дизайн js в которой потребуются знания этих ляпов. Что касается хаскела — как хаскелист любитель/начинающий дилетант с удовольствием послушаю историй успешных хаскелистов овладевших языком не зная что там под капотом. Можно привести пример эффективной сортировки написанной на хаскеле без глубокого знания ситуации под капотом :) (для тех кто не в теме оставлю тут)


          1. worldmind
            27.11.2019 17:53
            +1

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


            1. gearbox
              27.11.2019 18:06
              +1

              Ляпы не надо учить. Если писать на js нормальный код с нормальными практиками — вы просто в них не будете втыкаться. 90% ляпов — неявное приведение типов. Странно слышать от апологетов статичной типизации что они страдают от того как они заложились на то что js будет приводить типы так как они рассчитывали. Апологет статичной типизации никак не рассчитывает, он либо приводит явно либо проверяет. Проблемы с js как правило у народа пришедшего с таких же динамичных языков, просто там приведение работает по другому и при этом они знают КАК.
              Не закладывайтесь на приведение. Используйте === и явные преобразования типов.


          1. zagayevskiy
            27.11.2019 19:01
            +2

            Как насчёт функции, в которую приходит параметр, который иногда boolean, а иногда — лямбда? Это реальный случай, вот так сделали, какие-то люди, которые уже уволились. Это — норма?
            Или вот я сейчас придумал — два параметра, на выходе — сумма. И нечаянно(порефакторили не так, а подсказать инструменты не могут) передали туда массив и объект, а на выходе — пустая строка. Это, что ли, норма?


            1. gearbox
              28.11.2019 19:39

              >Как насчёт функции, в которую приходит параметр, который иногда boolean, а иногда — лямбда?
              Никак. Там ведь стоит на входе if typeof bla bla, верно?


              1. zagayevskiy
                28.11.2019 19:48

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


                1. gearbox
                  28.11.2019 21:33
                  +3

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

                  >То есть каждую мельчайшую функцию надо проверить на тему того, что она там себе обрабатывает? Вот уж нафиг.
                  У Вас на входе функции — union, конечно будете проверять. Расскажите мне как вы обойдетесь без проверки на nil в go или тот же nothing в maybe? Это ведь не дизайн языка, это дизайн функции, и такому дизайнеру в любом языке оторвут руки предварительно поломав пальцы.
                  Не хотите выхватить сюрпризов в рантайме — используйте инструменты — eslint и typescript. В общем если хотите жить нормально — возможности есть. Для плача Ярославны поводы — тоже. Тут как бы сам себе выбирает что больше по душе.


                  1. 0xd34df00d
                    28.11.2019 23:32

                    Расскажите мне как вы обойдетесь без проверки на nil в go или тот же nothing в maybe?

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


                    1. gearbox
                      29.11.2019 14:18

                      >Я просто не буду проверять на nothing в maybe, если я не могу это адекватно обработать на этом уровне.
                      Да это понятно, я к тому что в любом случае эта обработка где то должна существовать. Я js c хаскелем и не пытаюсь сравнить :)

                      >а тайпчекер уже гарантирует, что кто-то это да проверит.
                      Так и в js можно притянуть typescript, там вполне себе приличный тайпчекер, просто речь изначально о js — я поэтому особо статичную типизацию в тред не несу. А так то есть вполне себе убойный аргумент — typescript и фронт с бэком на нем в одном наборе типов. Но это уже реально совсем другая история.


        1. 0xd34df00d
          27.11.2019 18:30

          не говоря уже про хаскел

          У меня до сих пор бугурт от совершенно корявой иерархии тайпклассов нумериков в стандартной prelude (и у кучи других людей тоже). Впрочем, со сравнением хотя бы проблем нет:


          Prelude> 103209823048320840000 == (103209823048320840000 + 1)
          False


          1. worldmind
            27.11.2019 18:33

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


          1. gearbox
            28.11.2019 22:13

            :)

            Prelude> 103209823048320840000.0 == 103209823048320840000.0 + 1.0
            True
            


            1. 0xd34df00d
              28.11.2019 23:21

              Ну так это IEEE754, что от него ждать. Вот если взять Data.Ratio...


              Prelude> :m + Data.Ratio
              Prelude Data.Ratio> 103209823048320840000.0 == 103209823048320840000.0 + (1.0 :: Ratio Int)
              False


      1. fougasse
        27.11.2019 17:04
        -1

        Оправдание — так себе.
        Почему +10000 не работает, а +15000 — уже «нормально»(ожидаемо) складывается?


    1. Aingis
      27.11.2019 18:59
      +1

      Самое очевидное приведение типов.
      [] + []
      ""
      [] + {}
      "[object Object]"
      {} + []
      0
      {} + {}
      NaN

      Вы правда с этим столкнулись в коде или привели копипасту для плюсов? Приведение типов работает консистентно и как ожидается:
      console.log([] + [])
      ""
      console.log([] + {})
      "[object Object]"
      console.log({} + [])
      "[object Object]"
      console.log({} + {})
      "[object Object][object Object]"
      


      1. Mingun
        27.11.2019 19:04
        -2

        А теперь уберите неизвестно зачем вами вставленный console.log() и удивитесь :)


        1. staticlab
          27.11.2019 19:13
          +2

          А когда такой код может встретиться вне контекста выражения и зачем он может быть нужен?


          1. Mingun
            27.11.2019 19:37
            +4

            Выше уже объяснили: суть не в том, нужен или не нужен в каком-либо там контексте, а в том, какого… это вообще работает. А вы так огульно заменили инструкцию выражением и, типа, теперь всё нормально, проблемы как бы и нет. «Язык-то отличный, это вы дурак». А это, кстати, ещё один вопрос, почему в разных контекстах получаются разные результаты.


            1. staticlab
              27.11.2019 19:49

              А вы так огульно заменили инструкцию выражением

              Не я :)


              И в теории, если некоторый статический язык поддерживает перегруженный унарный оператор + для массивов, то в контексте выражения {} + [] приведёт к ошибке типов, а в контексте инструкций — к валидной операции +[], если только символ + не будет иметь в этом контексте особого смысла (как в Obj-C).


          1. ivanuzzo
            27.11.2019 20:46

            для создания бэкдоров и эксплоитов?


            1. staticlab
              28.11.2019 11:41
              +1

              Можете привести пример?


              1. ivanuzzo
                29.11.2019 16:46

                смотря для чего вам это нужно.


                1. AlexBin
                  29.11.2019 17:01

                  смотря для чего вам это нужно.

                  Видимо, если вы не найдете пример, оппонент сделает вывод, что такого примера нет.


                  1. ivanuzzo
                    29.11.2019 17:49
                    -1

                    даже не знаю, как я это переживу.


                1. staticlab
                  30.11.2019 12:01
                  +1

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


                  1. ivanuzzo
                    30.11.2019 13:02
                    -1

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


                    1. justboris
                      30.11.2019 15:37

                      Про обфускацию понятно, но это же не единственный вариант её реализации. От наличия или отсутствия этой конкретной фичи ситуация с эксплойтами не меняется. Закроют эту возможность – останутся другие: http://www.jsfuck.com


                      1. ivanuzzo
                        30.11.2019 17:33

                        это вы к чему?


    1. igor-sheludko
      27.11.2019 21:00

      Ну так автор же про то, что нужно просто привыкнуть. Это непривычно, после другого языка. Кто много пишет на js, уже не удивляется :)


      1. Guitariz
        28.11.2019 09:30

        нужно просто привыкнуть

        Отличный пример для велосипеда Гаррисона из Южного парка


    1. polar11beer
      28.11.2019 11:58
      +1

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

      Скажем, в C++ нежелательно бросать исключение в конструкторе объекта, иначе можно получить утечку памяти. Тоже не очевидный момент, его просто нужно знать.


  1. maxzh83
    27.11.2019 14:03

    На данный момент я бы порекомендовал вам изучать TypeScript

    Зачем? Если в заголовке такое:
    JavaScript не нужно ничем заменять


    1. JustDont
      27.11.2019 15:36

      Затем, что TS не заменяет JS, и TS и JS не относятся друг к другу как непересекающиеся множества.


      1. maxzh83
        27.11.2019 15:50
        -1

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


        1. JustDont
          27.11.2019 15:59
          +1

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


          1. maxzh83
            27.11.2019 16:04
            -1

            Ну тогда Java и JavaScript это одно и тоже, чего там


            1. JustDont
              27.11.2019 16:34
              +2

              Сову-то пожалейте.


  1. rudinandrey
    27.11.2019 15:31

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


    1. JustDont
      27.11.2019 15:37

      Если вам с помощью простой вещи нужно будет делать большие сложные вещи — вы в итоге изобретете и свою собственную убогую строгую типизацию, и многое другое.


      1. nbytes
        28.11.2019 03:05
        +1

        Ну да, например PropTypes в React.


      1. rudinandrey
        28.11.2019 11:19

        ушел с C# и ASP.NET со строгой типизацией на PHP+JS чтобы ее не было.


    1. nbytes
      28.11.2019 02:52

      Почему же усложняющих, есть один крупный проект на TS и если бы без него, я даже боюсь представить, во что бы это вылилось, у нас 95% ошибок отлавливается при компиляции и если не дай бог бэк сломал контракты, при обновлении моделей из сваггера сразу все видно, параллельно другой командой ведётся проект поменьше но на JS, и столько сколько они дебежат это ужас, все ошибки только в рантайме. И дело тут не в архитектуре проектов, а именно в том, что одни «усложнили» себе жизнь типизацией, а другие «облегчили» используя обычный JS без типов.


  1. softaria
    27.11.2019 17:33
    +1

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


    1. staticlab
      27.11.2019 18:13
      +1

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


      1. softaria
        27.11.2019 18:17

        API к DOM, думаю, вопрос времени. А вот языки, скорее всего, появятся какие-то новые. Ну или это будут диалекты существующих. Тащить рантайм точно никто не станет.


        1. none7
          27.11.2019 21:15
          +1

          Очень далёкого времени. В настоящий момент даже планов таких нет и возможно не будет. Разработчики стандарта не видят проблемы в существовании оберток на JavaScript. Ведь WebAssembly существует для числодробилок и импорта существующего кода на Си. А если приходится часто обращаться к JavaScript коду, то это управляющий код и должен писаться на JavaScript.


          1. softaria
            27.11.2019 21:21
            -1

            и импорта существующего кода на Си.


            github.com/appcypher/awesome-wasm-langs


            1. none7
              27.11.2019 21:35

              А гугл в своё время писал клиентскую часть Gmail на Java. Значит ли это, что JavaScript существует для эмуляции Java? Это конечно возможно, но оптимальным решением это определённо не будет.


              1. softaria
                27.11.2019 21:38

                А при чем здесь гугл и его webtookit?
                WASM позиционируется вот так: WebAssembly (abbreviated Wasm) is a binary instruction format for a stack-based virtual machine. Wasm is designed as a portable target for compilation of high-level languages like C/C++/Rust, enabling deployment on the web for client and server applications.

                Никакой привязки именно к си здесь нет.


                1. none7
                  27.11.2019 21:52
                  +1

                  А при чем здесь гугл и его webtookit?

                  Притом, что тоже низкопроизводительный велосипед как и все реализации компиляторов из Вашего списка. FAQ: Mostly HTML/CSS/JavaScript app with a few high-performance WebAssembly modules (e.g., graphing, simulation, image/sound/video processing, visualization, animation, compression, etc., examples which we can already see in asm.js today) allowing developers to reuse popular WebAssembly libraries just like JavaScript libraries today.
                  И какие могут быть высокопроизводительные библиотеки на чём то кроме C/C++/Rust?


          1. Neikist
            27.11.2019 21:28
            -1

            Ну например бридж в реакт нейтиве к нативу реально проблема. Почему обратное должно быть неверно?

            то это управляющий код и должен писаться на JavaScript

            В этом и проблема.


    1. igor-sheludko
      27.11.2019 21:13

      Проблемы нет. Старые фичи есть для совместимости, а новые фичи делают работу удобнее. Просто нужно стараться использовать новые фичи.


  1. staticlab
    27.11.2019 17:54
    +4

    А как бы выглядело развитие веба со статически типизированным языком, который не позволяет делать полифиллы? Кажется, IE затормозил бы тогда развитие экосистемы ещё сильнее.


    1. Free_ze
      27.11.2019 18:12
      -1

      По-человечески — наследованием и внедрением зависимостей. Без манкипатчинга.
      Или по гадкому пути — через обертки, на манер jQ.


      1. staticlab
        27.11.2019 18:24

        То есть разработчики альтернативного браузера должны были бы сделать класс Array2 extends Array, чтобы добавить в него новый метод flatMap()?


        Понял, что описал не тот случай. Однако не могу придумать варианта, как использовать в коде метод из новой версии API, сохранив обратную совместимость, например в Java. Разве что использовать для новых методов какие-то внешние библиотеки со статическими методами, как Apache Collections (т.е. вызывать, например, Arrays.flatMap(array, ...) вместо array.flatMap(...)).


        1. Free_ze
          27.11.2019 19:11

          Я понял вашу мысль. Да, просто DI здесь не поможет.
          Можно было бы положиться, например, на методы-расширения из C#, но это тоже будет своего рода манкипатчинг. Но типобезопасно.


          1. staticlab
            27.11.2019 19:18

            Если в новой версии рантайма в расширяемом классе появится метод с такой же сигнатурой, произойдёт ошибка?


            Да, просто DI здесь не поможет.

            Кстати, возможно, и мог бы помочь, но только если бы DI был на уровне платформы и работал прозрачно абсолютно для всех классов, включая внешние библиотеки. Правда здесь тогда были бы возможны злоупотребления, как в Ruby (где авторы Rails сильно расширили стандартные методы, отчего многие новые библиотеки стали привязаны к ActiveSupport).


  1. Karl_Marx
    27.11.2019 21:01
    +1

    Не согласен с автором оригинала. Если веб-стандарты ограничивают разработчика использованием только одного языка, каким бы он ни был хорошим или плохим, это означает, что веб уже сломан. Таких ограничений нет нигде, хочешь писать для серверов на Linux — вот тебе куча языков на любой вкус, включая тот же JavaScript, собираешься писать под Windows — пожалуйста, на Android — вот тебе C++, Java, Kotlin.

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


    1. JustDont
      27.11.2019 23:50
      +3

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

      Вы всегда можете написать свой браузер. Или вообще отдавать через http-запрос скомпилированный бинарник для выполнения на клиентской машине уже чего угодно и как угодно. Дерзайте. Мир ждёт новых покорителей веба.


      1. Karl_Marx
        28.11.2019 01:34
        +2

        Проблема в том, что это не будет поддерживаться никем, кроме написавшего, а W3C не предоставляет стандартов для того, чтобы я, Mozilla, Google, Apple или Facebook занимались подобными вещами и эти вещи были бы одинаково безопасны и совместимы друг с другом. Понимаете, о чем речь? По сути, WebAssembly это первая попытка сделать нечто подобное, и то, она была с трудом продавлена корпорациями в то время как престарелые бюрократы сидели, плевали в потолок и годами игнорировали тот факт, что современный веб уже давно не про документы и анимированные баннеры, а про веб приложения.


        1. JustDont
          28.11.2019 09:29

          W3C не предоставляет стандартов

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

          По сути, WebAssembly это первая попытка сделать нечто подобное

          Мне кажется, вы не вполне понимаете, зачем добавили wasm. Подсказка: нет, не для того, чтоб любимый C можно было сразу в веб компилировать. Языки и wasm вообще не причём, так, не более, чем любопытный дополнительный эффект, от которого у многих зачем-то повышенное слюноотделение случилось.


    1. vanxant
      28.11.2019 01:17
      +3

      Если веб-стандарты ограничивают разработчика использованием только одного языка

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


  1. Vlad800
    28.11.2019 03:18

    Наличие легаси — это весомый аргумент, но не непреодолимый.


  1. vladkorotnev
    28.11.2019 04:01

    новые возможности никогда не должны «ломать» уже существующие веб-сайты.

    То-то у меня развалилась самодельная браузерка, использующая кучу видео и звука в том числе на заставке, из-за того, что в один день стало нельзя их использовать не по вызову пользователя (клик или пр.)


    1. codemafia
      28.11.2019 08:08

      Вообще то можно


  1. Clasen01
    28.11.2019 04:45

    Когда читаю статьи про Rust, то в комментариях тоже постоянно натыкаюсь на локальные противостояния «C++ лучше Rust», «С++ не нужен, Rust всему голова». /sarcasm:on Ребята, а как же «каждой задаче свой инструмент? Мы же все здесь профессионалы, к чему ругань? /sarcasm:off :)


    1. slonopotamus
      28.11.2019 10:17

      каждой задаче свой инструмент

      Ну во-первых, множество языков позиционируют себя как general-purpose programming language.


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


    1. TargetSan
      28.11.2019 21:54

      Ну вот я например сегодня продолбался с unicode command line parameters потому что винда не умеет юникод как однобайтовую кодировку без 1000 приседаний, а комитет на кодировки положил с прибором, к примеру депрекейтнув wstring_convert и не предоставив альтернативу. И таких косяков родом из времён чуть ли не мейнфреймов навалом. И фиксить тх никто не желает с мантрой "Святая Совместимость!!11одинодин".
      Накипело.


  1. ttas
    28.11.2019 09:09

    В ES5 появился 'use strict'. Разве нельзя использовать что-то подобное для указания версии без обратной совместимости? Разве не лукавит автор, сообщая, что возможно только добавление?


    1. JustDont
      28.11.2019 09:35

      Да, разработчики браузеров так и горят желанием добавить еще один движок рядом с имеющимися, на этот раз для выполнения некоего «next-gen JS».


    1. justboris
      28.11.2019 11:01

      В теории можно, Google пробовал добавить нативную поддержку Dart в браузеры. Но что-то пошло не так, и проект отменился. Было бы здорово, если бы кто-то в теме рассказал бы, в чем там были причины


      1. Neikist
        28.11.2019 11:08

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


      1. JustDont
        28.11.2019 11:20
        +1

        В том, что никому не впёрлось работать на хотелки гугла. Это в первую очередь. Во вторую — всё те же самые вопросы, которые поднимаются при попытке добавить любой «некст-ген» движок:
        1) Кому это нужно?
        2) Как это будет совместимо с имеющимся вебом?
        3) Какие это решает проблемы, которые не могут быть решены менее трудоёмкими (читай: менее дорогими для разработчиков браузеров) способами?


    1. vanxant
      28.11.2019 11:54

      … а зачем? Основные баги дизайна и ранних имплементаций как раз use strict и пофиксил.
      Современный JS на самом деле классный. Для своей конкретной ниши по крайней мере.
      Кому не хватает статической типизации в компайл тайме — для них есть тупоскрипт.
      Ноют в основном люди из «махрового ынтырпрайза», которые привыкли для каждой кнопки делать свой класс с геттерами и сеттерами и с одной строчкой полезного кода. JS позволяет просто написать эту одну строчку и пойти дальше.


  1. i360u
    28.11.2019 09:43

    В экосистеме javaScript существует достаточно средств для того, чтобы «не стрелять себе в ногу», это и статический анализ с аннотацией типов, и проверки типов в рантайме. Современный синтаксис позволяет писать красивый и эффективный код. Современные средства разработки позволяют делать это с необходимым удобством. Этого вполне достаточно для полноценной промышленной разработки, даже БЕЗ использования TypeScript транспайла. JavaScript это поразительно гибкий, выразительный и мощный язык. Но нужно понимать, что JS- это, в первую очередь, СКРИПТОВОЙ язык, предназначенный для исполнения в весьма специфичной среде, и естественно, он имеет ряд отличий от системных языков и ряда прикладных. А любители прострелить себе колено найдут возможность для этого на абсолютно ЛЮБОМ языке, я гарантирую.


    1. Free_ze
      28.11.2019 12:16

      Современный синтаксис позволяет писать красивый и эффективный код.

      Эффективный по каким критериям? Создается впечатление, что речь про производительность.


      1. i360u
        28.11.2019 12:31

        Эффективный в решении бизнес-задач. И по производительности в том числе.


  1. 7abbix
    28.11.2019 10:20
    -1

    Javascript нужно вообще отменить и даже запретить.
    Потому что настолько корявый нечитабельный, вырвиглазный синтаксис, как у JavaScript, не только не воспринимается на чтение, в отличие от нормальных языков типа C#, Java (только по синтаксису), но и способствует размножению огромного количества багов.


    1. staticlab
      28.11.2019 11:47
      +1

      Javascript нужно вообще отменить и даже запретить.

      Вас в Госдуме покусали?


      1. 7abbix
        28.11.2019 12:16
        -2

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


        1. staticlab
          28.11.2019 12:51

          синтаксис которого не интерпретируется мозгом без специального глубокого анализа, поэтому легко остаются незамеченными баги

          В этом отношении джаваскрипту далеко до C++, в котором намного больше неочевидных нюансов поведения кода, 19 способов инициализации переменных, undefined behavior — то, что подстерегает программиста на каждом шагу, а авторы PVSStudio зарабатывают деньги на инструменте, находящем ошибки в коде, в котором мозг никаких проблем не замечает. И при этом именно на нём пишутся браузеры. Давайте его запретим, потому что кому-то он по этим причинам не нравится.


          1. 7abbix
            28.11.2019 13:37

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


            1. JustDont
              28.11.2019 13:49

              Так что там, запрещаем уже С++?


              1. 7abbix
                28.11.2019 16:16
                -1

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


                1. staticlab
                  28.11.2019 17:36

                  Но я не хочу об этом знать.

                  Я извиняюсь, конечно, но...


                  1. 7abbix
                    28.11.2019 21:52

                    В некоторых случаях без этих языков никуда.
                    Но это не отменяет их косяков.


  1. FanatPHP
    28.11.2019 10:34

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


  1. potan
    28.11.2019 13:08

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


    1. Aingis
      29.11.2019 16:56


  1. taujavarob
    28.11.2019 21:55
    -1

    JavaScript навсегда! (С)