JavaScript как явление



Сообщество nodejs безумно, и судя по тому что в 2016-2017 годах в различных рейтингах JavaScript брал первое место по популярности вытеснив оттуда с небольшим отрывом Java — безумие в последнее время действительно станосится массовым. Казалось бы — не хочешь не кушай, пиши на своём любимом Elixir / Erlang / Lisp / Haskell / любом другом языкое с хорошим дизайном и в ус не дуй, но в текущей ситуации к сожалению это правило перестаёт работать и приходится прилагать некоторые усилия чтобы его соблюдать.

В чём причина популярности такого реально хренового языка как JavaScript? В принципе в том же в чём и причина популярности Java, да и вообще почти всех явлений культуры и общества — в бабле. Когда такие гиганты как Facebook, Google, Microsoft и Twitter методично вливают многомиллионные потоки кровавых долларов в JavaScript инфраструктуру, пишут фреймворки, библиотеки, придумывают стандарты и архитектуры — становится действительно трудно это игнорировать. Настолько сильное вливание бабла вызывает бешеный хайп-драйвен-девелопмент. Работодатель хочет видеть у себя React, Redux, Relay, Realm, Flux, Babel, Webpack / Grunt / Brunch и ещё с десяток модных слов от наших любимых корпораций которых я даже не знаю. И ещё всё это приправлено сверху кучей плагинов для этих же технологий, всех сортов и расцветок из нашего любимого npm. Технологии от корпораций для того чтобы у нас были технологии от корпораций и минифицированный js-бандл весом 15Мб для простого SPA, о да.

В какой-то момент огромный спрос на разработку на действительно ужасном языке породил огромное множество порой довольно странных компиляторов в JavaScript из других, более приемлимых языков. Вполне логично, разработчики мучимые сильнейшим когнитивным диссонансом ( хочу денег, но не хочу JS ) как-то пытались ( и пытаются ) уменьшить боль от разработки на JavaScript. Лично я пробовал довольно много языков из этого списка, какое-то время писал на CoffeeScript подобных языках, наиболее удачный пример LiveScript — из коробки карринг, пайпы, отсутствие дурацких скобочек, точек с запятой, циклов и return-ов. Пробовал даже PureScript — пример компиляции Haskell кода ( с иммутабельностью, монадами и чудесной системой сильных типов ) в JavaScript. На деле же конечно все эти языки не являются коммерчески востребованными по очевидным причинам — нет миллионных вливаний от корпораций в развитие инфраструктуры. Если бы таковые были — зуб даю, все поголовно бы писали на Haskell и рассказывали бы друг другу за чашечкой смузи покручивая спиннер о новых монадах и аппликативных функторах от Facebook.

Казалось бы, меня как backend-девелопера это вообще не должно волновать — пусть будет npm мракобесие на фронтенде, у меня то тут порядочек, кошерное ламповое OTP прямо как в 1986. Но рано было расслабляться — они вырвали JS движок из браузера потащили эту субстанцию на backend, причём с абсолютно серьёзным выражением лица. Ведь одно дело писать на этом языке какой-нибудь SPA, и совсем другое дело какой-нибудь критически важный биллинг. Но JavaScript теперь на backend, отлично.

  • однопоточный рантайм ( в 2017 году!!! )
  • отсутствие единой системы / стандартов реализации модулей ( опять же, 2017 год на дворе )
  • отсутствие единых стандартов структуры проекта ( все творят как хотят, в исходниках бывает очень сложно разобраться )
  • слабые типы с неявными ( и порой довольно странными ) преобразованиями
  • отсутствие нормальных классов / ООП
  • отсутствие единого вменяемого и работающего статического анализатора кода ( добро пожаловать в чудесный мир глупейших ошибок типа undefined is not a function )
  • отсутствие вывода типов в самом языке или в каком-либо инструменте
  • этот чудесный контекст this ( что это значит this в этом месте кода — объект? функция? )
  • абсолютно дурацкая реализация pattern matching ( паттерн матчишь пустой список / объект — без проблем, извлекаешь оттуда undefined, ты же именно это имел ввиду, да? ) и здесь опять привет cannot read property foo of undefined
  • отсутствие единой технологии работы с асинхронным кодом — колбэки, примисы, фьючерсы, async ( если в проекте более одной зависимости из npm то гарантированно в коде появятся все из них вперемешку )
  • const ( который на самом деле НЕ const )
  • абсолютно безумный npm с пакетами качества «братишка я тебе покушать принёс» ( и даже вот с таким )

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

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

Подробнее
Реклама
Комментарии 686
  • +48
    Какая-то бессмысленная истерика.
    • –13
      Не истерика а набор фактов и вопрос «почему всё так?» к обсуждению
      • +15
        В чем факт ужасности return? В том, что не нравится лично вам, не иначе.
        • +1
          Чем плох return, я могу предположить. Когда у функции несколько точек выхода, это не очень надёжная конструкция. Или, вот, когда return выходит не из метода, а из малозаметной стрелочной функции внутри него, это может оказаться коварной неожиданностью.
          Но фигурные скобочки и точка с запятой… Тут я теряюсь.
          • +2
            Единственная проблема с return в JS — нельзя перенести возвращаемое на следующую строку (будет undefined если перенести).
            • +6
              Или, вот, когда return выходит не из метода, а из малозаметной стрелочной функции внутри него, это может оказаться коварной неожиданностью.

              return такого не умеет.

              • –12
                function foo() {
                    var f = () => {
                        return 42;
                    };
                    f();
                }
                
                console.log(foo()); // undefined
                • +11
                  Известно, что функция может возвращать значение только через return (а стрелочная может и без него),
                  и тут назревает логичный вопрос: Если в конце тела функции нету return, то в чем здесь проблема в языке или в том, кто даже основ языка не прочитал?
                  • +6

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

                    • –1

                      Ничего не ожидал. Я продемонстрировал что return умеет выходить из стрелочной функции.

                      • +9

                        Я изменил тот комментарий.


                        Было бы странно, если бы return выходил сразу из нескольких функций.

                        • –1

                          Да, это и правда было бы странно (хотя в Scala вроде как return так и работает). Но искать точку выхода из переусложненной функции эта странность не помогает :-)

                          • +1
                            А зачем писать переусложненные функции?
                            • –1

                              Я не знаю зачем их пишут. Но читать их мне периодически приходится.

                        • +1
                          Ну хотя бы правильный пример для начала надо было написать. Потому что из примера нихрена оно не демонстрирует. Точнее не так: пример был о том что «если хочешь вернуть значение из функции — используй return». Стрелочная функция, как видно из названия — функция. Демо return statement то зачем?
                          • 0

                            Это (пере)упрощенный пример переусложненного метода. Тот, кто хочет выяснить почему foo() возвращает undefined, смотрит внутрь, находит return… а return-то возвращает значение не из внешней функции, а из внутренней.


                            Вот более жизненный пример: https://github.com/jquery/jquery/blob/731c501155ef139f53029c0e58409b80f0af3a0c/src/ajax.js#L386


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

                      • 0

                        Вы ожидали, что console.log выдаст 42?

                        • –5
                          Ничего не ожидал. Я продемонстрировал что return умеет выходить из стрелочной функции.
                          • 0
                            Как бы return выходит из той функции, которойнаписан
                      • +4
                        function foo() {
                            var f = () => {
                                return 42;
                            };
                            return f();
                        }
                        
                        console.log(foo()); // 42
                        


                        Вы ожидайте результат функции, которую не возвращаете
                        • –3
                          Ничего не ожидал. Я продемонстрировал что return умеет выходить из стрелочной функции.
                          • 0
                            Так он же не вышел!
                            Ваша f() отыграла как надо, просто вы ничего не возвращаете из foo()
                            • 0

                              Почему не вышел-то? Он вышел из внутренней стрелочной функции, не затронув выполнение внешней.

                              • 0
                                Прошу прощения, опечатался, имел в виду именно что он вышел, сначала из f(), а потом из foo() (только в foo он ничего не вернул).
                                • 0

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

                      • +1

                        Я думаю, имелось в виду "можно перепутать return из малозаметной стрелочной функцией внутри метода с return из самого метода"

                      • +1
                        Я, может, не совсем понимаю что вы подразумеваете под надежность. Но известные мне компилеры других языков не скомпилят программу, пока в каждой точке выхода не будет return. Если функция, конечно, не void func() :-)
                        • +1
                          Есть множество языков, где есть return, но его можно не использовать (php кажется, один из таких, а еще Scala) и есть множество языков, где return отсутствует как таковой (если не ошибаюсь, к ним относится Python).
                          Во всех этих языках результат последнего действия будет возвращен как результат функции.
                          • +1
                            В python точно есть return
                            • +1

                              есть != обязателен к использованию

                              • 0

                                Но в Python он обязателен к использованию (кроме случая когда функция модифицирует переданные в неё аргументы, но не думаю что что-нибудь хоть сколько-нибудь сложное можно написать на таких конструкциях) в отличие от Ruby, где в отсутствие return функция вернёт значение, полученное при выполнение последней операции

                              • 0
                                спасибо, значит ошибся.
                              • +1

                                В Python функция без return вернет None.


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

                                • +1
                                  К ним Ruby относится :)
                                • +1
                                  А тут я перестал понимать, о чём речь. В Javascript никакой точки выхода без return быть не может, если это только не конец функции. Я имею в виду вот что: «модуль (в данном случае функция) должен иметь только одну точку входа и только одну точку выхода».
                                  • +1
                                    JS еще цветочки. А вот плюсы, они еще и объект за вас сконструируют, если вы return не напишете.
                                    • +2

                                      Это UB по стандарту C++

                                  • 0

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

                                    • 0
                                      Но некоторые конструкции упрощают эту задачу.
                                    • +5
                                      ли, вот, когда return выходит не из метода, а из малозаметной стрелочной функции внутри него, это может оказаться коварной неожиданностью.

                                      public class Foo {
                                          public int bar() throws Exception {
                                              Callable<Integer> f = () -> {
                                                  return 42;
                                              };
                                              f.call();
                                          }
                                      }

                                      Коварный, коварный JavaS… Оу, нет, просто Java.

                                      • 0
                                        Я и не говорил, что Javascript хуже (или лучше Java), я просто предположил, чем может не нравиться return.
                                        • 0

                                          Вы поддерживаете т.з. автора о том, что return — это раздражающая особенность js


                                          И это ещё я молчу про субъективный взгляд на раздражающие лично меня особенности типа мутабельности, фигурных скобочек, точек с запятой, return
                                          • +1
                                            Вовсе нет. Я высказываю предположение, что именно его может раздражать. Я не утверждаю, что return обязательно должен раздражать, мне это странно.
                                            • –4
                                              Это моё субъективное мнение, без очевидных объективных причин, я так и написал :)
                                              Касаемо меня — return делает код функции более запутанным, а ещё я постоянно его забываю писать. Потому что всю жизнь писал на Erlang, Elixir, Haskell и Lisp. И от забытых return — ов много проблем, потому что функция возвращает undefined без всяких предупреждений и программа потом падает в самом неожиданном месте по какой-нибудь совсем другой причине, отловить трудно. В общем получается много бессмысленной работы.
                                              • +2
                                                Для меня-то как раз естественно, что если мы ничего не указываем функции возвращать, она и возвращает неопределённость. Падения по трудноотлавливаемой причине происходят не от этого, а оттого, например, что типы сами по себе втихомолку приводятся друг к другу, что там, где программист подразумевает сложение, может произойти конкатенация, а деление на ноль даст не исключение, а вполне правомерный NaN — и да, сбой в этих случаях может произойти гораздо позже, и не всегда трейс поможет.
                                                • 0
                                                  Да, неявные преобразования усугубляют такой тип ошибки ( впрочем как и почти все типы ошибок ). Касаемо return, циклов и прочих statements — тут дело в парадигме. Видимо вы хорошо владеете императивными языками в которых есть эти statements, поэтому всё и привычно. Но в функциональных языках как правило этих statements нет, да и вообще количество statements минимально потому что всё является expression. JavaScript — не настоящий мульти-парадигменный язык как это утверждается, впрочем как и не настоящий ООП язык ( привет классы JS ). Вот например Scala является и настоящим мультипарадигменным языком и настоящим ООП языком — там можно ( и как говорят многие даже нужно ) писать без этих statements. А в JavaScript слова мультипарадигменность и ООП были добавлены только ради красного словца и зачастую вводят людей из ФП в заблуждение.
                                                  • +1
                                                    впрочем как и не настоящий ООП язык ( привет классы JS )

                                                    А я вот с вами не соглашусь. Нельзя сказать что JS не OOP язык потому что в нём нет классового наследования. Прототипное наследование вполне укладывается в парадигму OOP.
                                                  • +1
                                                    Деление на ноль в JS вернет Infinity ;-)
                                                    • 0
                                                      Верно — что тоже не сильно помогает. А вот Math.asin(2), например, NaN.
                                                  • 0
                                                    return делает код функции более запутанным

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

                                                    • +5
                                                      Касаемо меня — return делает код функции более запутанным, а ещё я постоянно его забываю писать. Потому что всю жизнь писал на Erlang, Elixir, Haskell и Lisp.

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

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

                                                        В императивных языках вполне можно жить с опциональным return (scala, ruby, rust, coffeescript) при достаточной гибкости языка.


                                                        В том же coffeescript оно полубесполезно (особо нет функциональных конструкций).


                                                        В ruby куда лучше, стандартная библиотека хорошо заточена под функциональщину в ограниченном масштабе и работа с Enumerable без использования each, map, reduce/inject, all?/any? выглядит странной и неестественной.


                                                        В scala return надо использовать хорошо понимая (как и большинство фич, язык с приличным порогом вхождения). Например, return из лямбды вытекает во внешнюю функцию (пример со stackoverflow):


                                                        def sum(ns: Int*): Int = ns.foldLeft(0)((n, m) => n + m) // inlined add
                                                        
                                                        scala> sum(33, 42, 99)
                                                        res2: Int = 174 // alright
                                                        
                                                        def sumR(ns: Int*): Int = ns.foldLeft(0)((n, m) => return n + m) // inlined addR
                                                        
                                                        scala> sumR(33, 42, 99)
                                                        res3: Int = 33 // um.

                                                        Но учитывая наличие pattern matching, того, что if является выражением (expression) и прочих радостей return в scala нужен не очень часто.


                                                        В rust всё более-менее прилично и return стоит использовать только при явном раннем выходе из функции. Но, в отличии от scala, я не припомню, чтобы он давал такие неочевидные побочные эффекты. С учетом наличия pattern matching, того, что почти всё выражение (expression) — return нужен не очень часто. В той же обработке ошибок он раньше был спрятан за макросом try!, а сейчас за его сокращением ?. В последней версии пошли ещё дальше и loop (бесконечный цикл; очевидно, без условия) тоже может являться выражением, если использовать break some_result.


                                                        Больше всего в таком плане раздражает java 1.8: return обязателен в функциях и "многострочных" лямбдах (т. е. вида (x) -> { return 42; }), но запрещён в однострочных лямбдах (вида (x) -> 42). Несмотря на то, что IDE умеют превращать однострочную лямбду в многострочную и наоборот (если она состоит из одного return statement, ессно), это несколько раздражает.

                                                      • 0
                                                        А как вообще функция должна понять, что ей возвращать?
                                                        В разных языках это может делаться по разному — где-то функции (или переменной с названием функции) присваивается конечное значение, где-то return, но по сути это те же яйца только в профиль.
                                                        • 0
                                                          Ваша проблема в том что вы зависли в парадигме «функция обязана возвращать что-то определенное», в JavaScript'e — не обязана (аргумент про «не изучил, но критикую»)
                                                          • 0
                                                            Ваша проблема в том что вы зависли в парадигме «функция обязана возвращать что-то определенное», в JavaScript'e — не обязана (аргумент про «не изучил, но критикую»)

                                                            Нюанс в том, что все функции всегда что-то возвращают, но это будет void (С++) или undefined в случае с js.
                                                            Некоторые языки программирования такие функции/Function именуют процедурами/Sub и/или предотвращают такие проблемы и вопросы с неоднозначностью поведения еще на этапе компиляции в отличие от «оно само сделает» в случае в JS.
                                                            • 0
                                                              Это лишь значит, что JS — недостаточно формально корректно спроектированный язык. Функции, которые ничего не возвращают, нельзя вызвать из некоторых математических соображений.

                                                              У void в C++ с этим есть тоже определённые проблемы (тип очевидно населён, но создать переменную этого типа нельзя), которые иногда даже в реальной жизни больно бьют во время всяких шаблонных выкрутасов.
                                                    • +2
                                                      Оу, нет, просто Java.

                                                      В java нельзя получить undefined из-за забытого return. Ваш код не скомпилируется:
                                                      Error:(41, 5) java: missing return statement

                                                  • 0
                                                    return не плох, он коварен. В том смысле, что он обязателен — функция не возвращает значение последнего выражения.
                                                    • +9
                                                      Так это не в return дело, а в том что девелопер привык писать на языке, который не использует return.
                                                      Если девелопер начинал обучение с более низкоуровневых языков Pascal/C/C++/C#/etc. то ему будет напротив непривычно, что return не используется.

                                                      return коварен в Scala, где он при определенных условиях может сделать больше, чем ожидается. Но в JS он ведет себя как в большинстве C-подобных языков.
                                                      • +2
                                                        Я вот писал на JS после многих лет C/C++ и даже Питона и никаких проблем с return и скобочками не испытывал вообще!
                                                      • +3
                                                        Что же такого коварного описано в документации для JS про return? Или точнее «не написано».
                                                    • +4
                                                      «почему всё так?»
                                                      js, как язык существует уже почти 20 лет (или больше?), но js, как полноценный язык, на котором можно писать больше, чем обработчик onclick, существует всего лет 5-7, ну а js, который уже имеет зачатки для больших проектов (ES2015) и того меньше, – ему всего 2 года.

                                                      Но язык и платформа невероятно быстро развиваются. И большим недостатком этого развития является то, что «каждый тянет одеяло на себя» (на фоне этого развития можно стать SuperStar! если успеешь сделать библиотеку, которой все будут пользоваться, такую как jQuery). И теперь давно минувшие «браузерные войны» превратились в «войны фреймворков».

                                                      К тому же стоит смотреть на историю развития: сначала Прототипное ООП продвигалось, как лучшее в мире, потом пришли Классы, которые невзлюбили те, что освоили прототипное, а теперь и вовсе хайп на стороне функционального js.
                                                      Ах, еще JSX появился, который позволяет писать на js внутри html пока пишешь на js, который тоже не все любят.

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

                                                      ps: А хайп девелопмент очень просто объяснить. Большинство JS девелоперов выросли на фронтендах, где все делается не так просто, как на бекенде, и любая новая библиотека призванная улучшить ситуацию воспринимается на ура.
                                                      • +2

                                                        Примечательно, что до примитивного JSX был чудесный E4X, который был стандартом, поддерживался Мозиллой, Флешом и Акробатом, и который… не взлетел.

                                                        • –1

                                                          В то время фронтэндщики еще не свыклись с идеей о необходимости компилировать свои проекты, а firefox — не единственный браузер.

                                                          • +1

                                                            Тем не менее, сейчас бы сдуть пыль со старичка, да внедрить, но индустрия как барышня "всё, поезд ушёл, ты был классный, но я к тебе больше не вернусь, буду мучиться с новым перспективным козлом". :-) Вот и мучаются люди с огрызком в виде JSX.

                                                            • 0

                                                              Ну, все же E4X заменой JSX назвать трудно. Обработчики событий через E4X не поставить, сложные объекты — не передать. Все-таки, JSX по сравнению с E4X — шаг вперед.

                                                              • +1

                                                                Шаг вперёд — два шага назад :-) Добавить в E4X возможность передавать в атрибутах сложные объекты было бы не так уж сложно.

                                                                • –1

                                                                  … и чем бы оно тогда от JSX отличалось? :-)

                                                                  • 0

                                                                    DOM на выходе с возможностью его произвольного процессинга (от от DOM API и E4X селекторов, до XSLT трансформаций). Нативной поддержкой без препроцессоров. Стандарт в конце концов.

                                                                    • 0

                                                                      Ну а тут — то же самое, только еще гибче (что угодно на выходе).

                                                                      • –2

                                                                        JSX на выходе даёт виртуальный дом. E4X — реальный. Преимуществ у первого перед вторым нет никаких.

                                                                        • +3

                                                                          JSX на выходе дает то, на что настроено

                                                        • +2
                                                          сначала Прототипное ООП продвигалось, как лучшее в мире, потом пришли Классы

                                                          так прототипное ООП никуда не делось – классы в JS это по сути синтаксический сахар, прототипный подход остался на месте

                                                      • +5
                                                        По моему всё по делу. Почти со всем согласен с автором, то что в 2017 году во сферы пытаются запихать однопоточный рантайм, это не нормально.

                                                        Я считаю это результат курса ан опопсение программирования. Бизнесу не хватает программистов и они прикладывают силы чтоб любой js junior мог пилить их бизнес задачи.
                                                        • +1

                                                          Бизнесу же в конце концов надо решить задачу. Задач много, а программистов мало. С их точки зрения лучше, когда "дешёвый" js-разработчик быстренько напишет на однопоточном ЯП решение без разруливания проблем с race condition, синхронизацией и т.п., чем это будет "правильно" пилить "дорогой" разработчик на той же Java. А затем на сервере или в кластере поднимут нужное количество инстансов приложения, и вот вам многопоточность.


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

                                                          • +1
                                                            Однопоточность не решает проблемы race condition. Вот один из самых известных исторических фактов по этому вопросу.
                                                            • 0

                                                              Только вот потом «сейчас и побыстрому» оборачивается проблемой «как это всё теперь поддерживать и допиливать».

                                                              • 0

                                                                Т.е. с самого старта проект превращается в легаси.

                                                                • 0

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

                                                                • +1
                                                                  Справедливости ради стоит отметить:
                                                                  1. Хороший JS разработчик стоит столько же, сколько и хороший Java разработчик, но введу того, что JS легче изучить, туда сейчас идет очень много людей. Из-за этого специалисты начинающего и среднего уровня стоят довольно дешево.
                                                                  2. JS не на много проще, чем Java. Вернее проще в одних моментах и на много сложнее в других. Java сложнее для старта, но в сотни! раз проще для поддержки проекта, если это не уродливый JavaEE, где куча XML.
                                                                  3. Многопоточность в Java используется не часто, по крайней мере для WEB. Да, сервера сами по себе многопоточны, но каждый HTTP запрос обрабатывается в одном потоке без взаимодействия с другими. Нужно еще постараться, чтобы выстрелить себе в ногу в этом месте.
                                                                  • 0
                                                                    Нужно еще постараться, чтобы выстрелить себе в ногу в этом месте.

                                                                    BTW, знавал людей, которые в таком окружении умудрились сделать подключение к БД синглтоном. А вы говорите...

                                                                    • 0
                                                                      Я встречал, как кто-то в потоке обработки HTTP запроса создавал тред-пул для выполнения довольно тривиальных действий.
                                                                      Девелопер действительно постарался, он сделал пул потоков, он хотел как лучше, но упустил из виду то, что придет 100 запросов и он создаст +200 потоков и системе станет очень плохо.

                                                                      Но это по большей части исключение из правил.
                                                                    • +1
                                                                      Вернее проще в одних моментах и на много сложнее в других. Java сложнее для старта, но в сотни! раз проще для поддержки проекта, если это не уродливый JavaEE, где куча XML.

                                                                      В современном Java EE xml'а куда меньше, чем было во времена EJB2.1. 11 лет прошло от появление EJB3.0, где уже вовсю используются аннотации.


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

                                                                      Вам кажется. Как только уверенный в себе разработчик начинает на каждый запрос порождать пул соединений к базе или делать что-то типа https://habrahabr.ru/post/334138/, то concurrency там в полный рост. Со всеми проблемами, происходящими от остутствия минимального понимания JMM.

                                                                • +13
                                                                  Ну я тоже долго плевался от JS пока не стал на нём писать серьёзные вещи.

                                                                  Как оказалось, что всё от чего я плевался либо не страшно, либо удачно засахарено в ES6/TS.

                                                                  Возможно, что просто в отделе подняли зарплату не автору, а фронтеру)
                                                                • +11
                                                                  Может быть я не очень хороший программист, но JS я люблю. Однако считаю синдромом мечтать о том, чтобы всё было на JS.
                                                                  • –3
                                                                    CodeViking
                                                                    Может быть я не очень хороший программист, но JS я люблю.
                                                                    Многие любят JS — И это нормально.

                                                                    Ненормально и странно, когда кто-то пишет — «Я люблю С++» или «Я без ума от PHP» или «Ничего нет лучше Python»

                                                                    У уж если кто напишет — "Я люблю SQL" — его в дурку сразу определят.

                                                                    Только про JavaScript вполне нормально сказать — "Я люблю JavaScript."

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

                                                                    Имхо, конечно, имхо. (С)

                                                                    • +5
                                                                      Почему ненормально? Я вот много лет писал на ЖС и сейчас пишу, мне нравится множество вещей на нем, но вот люблю C#, потому что мне нравятся эмоции, которые я испытываю, когда программирую на нем. Может вы ремесленник и относитесь к программированию исключительно как к монотонной скучной работе, но не все такие.
                                                                      Я вот сейчас еще на Go много пишу, но совсем его не люблю, потому что очень неудобный язык. Так что да, под решение задачи подходит и даже больше C#, но люблю я все-равно C#, к JS я нейтрален, а Go не люблю. Что тут не так?
                                                                      • –2
                                                                        но вот люблю C#, потому что мне нравятся эмоции, которые я испытываю, когда программирую на нем.


                                                                        Ну какие могут быть эмоции в этой Microsoft инкарнации Java? Какие? — Не шутите так. Время Java и С# (с эмоциями, с эмоциями) осталось в конце прошлого века.

                                                                  • +10
                                                                    Наболело.
                                                                    • +15
                                                                      Когда такие гиганты как Facebook, Google, Microsoft и Twitter методично вливают многомиллионные потоки кровавых долларов в JavaScript инфраструктуру


                                                                      А зачем же они это делают? Почему не вливают в кошерные языки?
                                                                      • –5
                                                                        Могу предположить что использование JS фреймворков от фейсбука внутри самого фейсбука выглядит не так уж и страшно — из за высокого уровня культуры разработки, 100% покрытие юнит-тестами от и до. То есть они пишут инструмент для себя. Также возможно дело в средней цене за единицу времени js разработки / низком пороге входа — дешевле взять js джуна которых много, при необходимости обучить написанию тестов и дать ему таск чтобы он писал тесты и облазил в дебаггере код вдоль и поперёк пока всё не заработает как надо чем искать Scala / Java / Erlang / Elixir / Haskell / какого-то ещё разработчика.
                                                                        • +3
                                                                          Могу предположить что использование JS фреймворков от фейсбука внутри самого фейсбука выглядит не так уж и страшно — из за высокого уровня культуры разработки, 100% покрытие юнит-тестами от и до.

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

                                                                          Вот это может быть более похоже на правду.
                                                                          • +9

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

                                                                            • 0

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

                                                                              • 0

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

                                                                                • 0

                                                                                  А я бы доверил, потому что знать, почему 0 == '0' для фронтэндера важнее, чем знать, почему для применения того, чтобы дети с float: left не вылетали из родителя родителю нужно какие-то бордеры невидимые делать или ещё хлеще, почему при opacity !== 1 прекращает свою работу z-index.


                                                                                  Просто приведения типов можно объяснить, даже this можно знать на что будет ссылаться, а вот почему z-index перестал работать вы никогда не объясните, или почему нужен position: relative там, где есть какие-нибудь вещи. Там это аксиомы, а у нас хотя бы можно как-то объяснить и предсказать поведение, хотя в некоторых очень узких местах даже в js нельзя понять какого чёрта с приведением творится.

                                                                                  • +1

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

                                                                                    • 0

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

                                                                                      • 0

                                                                                        Я говорю даже не о "красивостях" и анимациях. Даже простое знание селекторов и манипуляции с атрибутами могут избавить вас от огромного количества лишнего кода в JS и ненужной логики в компонентах. А это прямая зависимость с качеством кода и скоростью разработки. Остальное — также, так или иначе, позволяет оптимизировать рендер и делать многие задачи на более высоком уровне. Как следствие — CSS — становится органичной частью кода приложения, вы должны его полностью контролировать чтобы получать наиболее предсказуемый и качественный результат. А зная современные возможности веб-платформы верстать становится совсем не сложно и местами очень даже приятно. А использование какой-либо консистентной экосистемы UI-компонентов избавит вас от рутины. Но такой подход, конечно, более актуален в продуктовой разработке а не проектной (когда лендинги).

                                                                                        • 0

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

                                                                                          • 0

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

                                                                                            • 0

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

                                                                                              • +1
                                                                                                ответы на которые всё чаще сводятся «поставь родителю position: relative».


                                                                                                Как вы можете претендовать на фронтенд разработку? -_-
                                                                                                • 0

                                                                                                  Вот как-то вот так) Я же говорю, знакомый есть, который эти нелогичности объясняет как "ну вот так вот получилось, это нужно запомнить, чинится это вот так".

                                                                                                  • +1
                                                                                                    претендовать на фронтенд разработку

                                                                                                    Да запросто, если пишешь невизуальную часть фронтенда.

                                                                                              • 0
                                                                                                я сам по себе как js разработчик знать не должен


                                                                                                Если вы позиционируете себя исключительно как js-разработчика, то разумеется не должны. Однако, если же вы имеете смелость называть себя фронтенд-разработчиком, то как минимум обязаны.
                                                                                        • 0

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

                                                                                          • 0

                                                                                            Во общем — Вы правы. Но когда пишешь толстый клиент, лучше чтобы за багами z-index-ов следил отдельный человек.

                                                                                        • 0

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

                                                                                          • +3
                                                                                            Блин. Пойду убьюсь.

                                                                                            Я могу верстать, но очень средненько и очень медленно. Если из рук проф дизайнера/верстака выходит красивое приложение, а мне этого не дано…

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

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

                                                                                            А с тем что джуньоры на JS нафиг не нужны, а сеньоров рвут на лоскуты… знаком не понаслышке. На самом деле порог входа довольно таки дорогой. Только это не видно со стороны. Да, как автар статьи намекал, действительно из фронт-проекта сделать помойку легче лёгкого. Поэтому требуются очень люди с бэкграундом. Чтобы и подводные камни знали и по фен-шую работали.
                                                                                          • +3
                                                                                            Верстальщики, как и JS девелоперы, это же подмножество фронтедщиков или нет?
                                                                                            т.к. Фронтэнд — это все, что связано с клиентской частью приложения, с отображением.

                                                                                            но если в общем это уже зависит от того, какие требования к фронтендщику предьявляют в какой-то конкретной компании, в более крупных — разделяют на 2 должности, в более мелких — это один человек.
                                                                                            • 0
                                                                                              я уже так давно не видел верстальщиков, если честно.
                                                                                              обычно из того, что видел это дело распиливают между собой дизайнер и чувак, который что-то пилит на angular/react/vue etc.
                                                                                              я и сам не люблю, да и скажу честно, плохо довольно работаю с этими CSS и HTML… но как-то никому в голову не приходит верстальщика брать еще. серьезно, думал они «вымерли» уже :D
                                                                                              • 0

                                                                                                Они не вымерли, и не вымрут, пока не появятся бесплатные нормальные генераторы лендингов, а они именно с этими 2 качествами не появятся никогда.

                                                                                      • 0
                                                                                        У них есть ряд причин так делать, но забота о разработчиках и их нервах в этот ряд не входит.
                                                                                      • +5
                                                                                        Тащить на backend интерпретируемые языки, а еще и без типизации — маразм. Только компилируемые и со строгой, желательно именной, типизацией (Golang или Rust, конечно же).
                                                                                        На клиенте же всё наоборот — нужна полная кроссплатформенность, а теперь и кроссдевайсность. Современные SPA фреймворки позволяют один такой bundle запустить на любом устройстве с экраном.
                                                                                        Но не на backend, ни в коем случае.
                                                                                        Пишу этот коммент только для того, чтобы выудить умные противоположные мысли из комментов к нему, если они будут.
                                                                                        • +6
                                                                                          [Update]
                                                                                          В качестве JS только TypeScript.
                                                                                          • 0
                                                                                            Трудности и радости секса в невесомости сильно преувеличены (с) А. Кларк (или А. Азимов, в общем кто-то из них)

                                                                                            За три месяца работы на TS был только один случай, когда типизация могла бы сэкономить мне время на отладку (бага поймалась в редакторе). В остальном мне больше нравится ES6, чем TS. Но правда у меня школа Perl, который позволяет ещё больше чем JS и спрашивает потом больно, неожиданно и на продакшене, если где что прощёлкал.
                                                                                            • +3

                                                                                              Мы сейчас в процессе переезда нескольких библиотек на TS. Я уже сбился со счету сколько скрытых багов выявляется.

                                                                                          • +8
                                                                                            Говорят, что v8 компилирует js в нативный код, думаете врут?
                                                                                            • –10
                                                                                              Судя по бенчмаркам, скорее всего, врут.
                                                                                              • 0
                                                                                                А в конечном счете, все выполняется на вполне себе нативном ядре процессора с его микрокодом. Так что не врут.

                                                                                                Вопрос в другом, какие assumptions сделает компилятор, пока будет превращать JS в нативный код? Статическая типизация в этом смысле поможет избежать ложных assumptions и четче декларировать намерения. Но ее нет :-)
                                                                                              • 0
                                                                                                На клиенте же всё наоборот — нужна полная кроссплатформенность, а теперь и кроссдевайсность.

                                                                                                Вы с css не путаете?
                                                                                                Есть всего 3,5 браузерных js движков, и все они более менее поддерживают стандарты.
                                                                                                • –10
                                                                                                  Языки с типизацией — унылое старьё. ))))
                                                                                                  • +5
                                                                                                    Ага

                                                                                                    • 0
                                                                                                      Похоже, не только Вы не заметили, что я не разделял статически типизированные языки от динамически типизированных.
                                                                                                      • +3
                                                                                                        Ассемблер или брейнфак?
                                                                                                  • +1

                                                                                                    А чем плохи PHP, Python, Ruby?

                                                                                                    • –2
                                                                                                      На большом и мощном серваке иметь быстрые скомпиленные проги, а на дохленькой трубе обмазываться интерпретируемой динамикой или тратить скудные ресурсы на JIT не кажется ли вам странным?
                                                                                                      • 0

                                                                                                        Сервер — один, труб — много. Нагрузка несоизмерима. Тем более, что сейчас каждая труба может баллистику звездолёта рассчитывать в реальном времени.

                                                                                                        • +3
                                                                                                          сейчас каждая труба может баллистику звездолёта рассчитывать в реальном времени

                                                                                                          JS спешит на помощь избыткам мощности! (= Современные сайты жрут как не в себя и тормозят на десктопах, что уж о мобилках говорить.
                                                                                                      • 0
                                                                                                        Эм… На бэкенде «интерпретируемые языки, а еще и без типизации» чуть ли не царствуют. Весь bash/shell/cmd такой. На них не пишут бизнес-логику? Ок, тогда SQL — он тоже по факту скорее интерпретирумый, с типизацией у него «всё сложно». Кстати большинство движков SQL однопоточные (внутри запроса параллельность может быть, но следующий запрос начнется только после окончания предыдущего). Если про веб, то PHP по меркам индустрии джититься стал чуть ли не вчера. ABAP, не к ночи будет помянут, тоже, хм, элегантен, как паравоз.
                                                                                                        А ведь это языки на которых самое мясо бизнеса зачастую крутится. Тут скорее «Golang или Rust» пока в роли белых ворон.

                                                                                                        [Я сторонник типизированных языков, если что]
                                                                                                        • 0
                                                                                                          Если про веб, то PHP по меркам индустрии джититься стал чуть ли не вчера.

                                                                                                          Я что-то упустил, и в PHP впилили JIT? Вроде только в проекте, если речь про основную ветку.
                                                                                                      • +6
                                                                                                        Сразу вспомнилось Wat видео от Destroy All Software.
                                                                                                        • +6
                                                                                                          Боль автора полностью обоснована. В последнее время я несколько увлёкся написанием ботов с MS Botframework, используя nodejs. Пока не перешёл полностью на Typescript — написание приложения больше 1000 строк, было настоящим мучением. Очень советую автору присмотреться к Typescript, как к костылю, который частично облегчает жизнь.
                                                                                                          • 0
                                                                                                            Благодарю! В современном мире увы каждый разработчик соприкасается с JS хочет он того или нет — больше или меньше, но это явление есть. Порой когда обсуждаю с друзьями-разработчиками какую-нибудь современную технологию кажется что находишься в клубе анонимных алкоголиков — то есть все знают что такое JS, почему он плох, но по разным причинам каждый становится замешан в этой экосистеме, иногда так и кажется что кто-то скажет

                                                                                                            — Привет, меня зовут Олег, и я иногда пишу на JS. Нет, вы не подумайте в основном я Scala разработчик, но вот иногда приходится и в npm полазить и для grunt с webpack скрипты написать. Кстати, я не писал на JS уже 2 недели
                                                                                                            — Давайте похлопаем Олегу

                                                                                                            :)
                                                                                                            • 0
                                                                                                              меня зовут не Олег, я всеми силами пытался дистанцироваться от фронтенда, но несмотря на это мне уже приходилось писать на JS
                                                                                                            • +13
                                                                                                              Я бы не сказал, что Typescript костыль.
                                                                                                              • –1
                                                                                                                Хорошая вещь является костылём, если её предназначение — заставлять работать плохую вещь, когда её [почти] невозможно заменить.
                                                                                                                Если бы браузеры понимали Typescript, он бы не был костылём.
                                                                                                                • 0
                                                                                                                  Компилятор Typescript написан на… Typescript. Если я ничего не путаю, можно прикрутить компилятор к страничке и генерировать код в браузере на лету, но так никто не делает, потому что зачем.
                                                                                                                  • 0
                                                                                                                    А как прикрутить к страничке что-либо, написанное на Typescript?
                                                                                                                    • 0
                                                                                                                      Написан на typescript и скомпилирован в javascript
                                                                                                                      • +6
                                                                                                                        Что-то ребята на C++/C#/Java и тд тп всю жизнь компилируют и как-то не жалуются
                                                                                                                        • +1
                                                                                                                          Ребята компилируют в байткод, а то и в маш.коды, а не занимаются пустопорожними переливаниями между разными видами текстовых форматов.
                                                                                                                          • 0
                                                                                                                            Ну про машинный код я еще могу понять логику, это непосредственный формат для процессора. И то, сначала код переводится в ассемблер, а уже потом в машинный код, так то.
                                                                                                                            В чем же разница подачи байт кода java машины или передачи javascript кода браузеру (мог бы он принимать javascript байт код напрямую, так бы и делали) мне сложно уловить.
                                                                                                                            • 0
                                                                                                                              И то, сначала код переводится в ассемблер, а уже потом в машинный код

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

                                                                                                                              В чем же разница подачи байт кода java машины или передачи javascript кода браузеру

                                                                                                                              Про Java об заклад биться не буду, но идеи там во многом аналогичны .NET CLI. Название как бы намекает: банальный текст против некоторого удобного для выполнения бинарного представления. Выгода здесь в оптимизациях, которые может провернуть компилятор (уровня модуля), удобной раскладки метаданных (стандартизированный формат, Карл! Поэтому байткод — кроссплатформенный, а в браузеры в 2к17 до сих пор шлют текстовые файлы). Да и просто байткод — это бинарное представление объектно-ориентированного ассемблера, использующий API виртуальной машины, а не сырой исходник, который еще необходимо распарсить, переварить во внутреннее представление (для конкретного движка), а потом как-то его исполнить.