Tired of outsourcing? Get hired at a top product startup from Silicon Valley 🚀
×Закрыть

JavaScript не лучший кандидат для входа в IT?

Доброго времени суток! Хотел бы услышать мнение опытных людей, решил начать свой путь в мир айти с фронт-энд разработки. Дойдя до js столкнулся с высказываниями людей, о том что сам язык плох для начинающих и вообще способен скушать любой говно-код (что не есть гуд для нубов). Многие советуют начать со строгих языков. Да вот теперь паника. Буду благодарен за совет, если начать с JavaScript то все будет плохо? и вообще, JavaScript как первый язык хорош или нет?

LinkedIn

Лучшие комментарии пропустить

На строгих языках тоже можно наговнокодить. Для того чтобы не запутаться есть паттерны и принципы программирования. Я бы не рекомендовал конечно рваться в более строгий typescript не поняв javascript. Лучше начать с азов и двигаться в сторону современных популярных SPA фреймворков таких как React, Vue, Angular. Советую воспользоваться анализаторами типа ESLint для того чтобы твой код был единообразным.

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

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

г**нокодить можно на чем угодно и как угодно. Бери и делай

IT в принципе не лучший кандидат для входа. Это только кажется что тут всё охуенно, выучился и ОК. Только всё новое пишется быстрее, чем ты можешь его выучить. А 50% времени тебе придётся тратить на образование ВСЕГДА.

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

Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Нет, лучше начать с Бейсика, или Паскаля. Потом С, С++, C#. Затем, когда будешь сравнительно хорошо знать вышеперечисленные языки, можно уже смотреть на каком действительно хочешь кодить.

It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration.

Edsger W. Dijkstra

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

Dijkstra был за Haskell как первый язык для студентов: chrisdone.com/...​sts/dijkstra-haskell-java

Знаете, на своем опыте вам скажу, лучше заказывать фронт-энд разработки, чем их делать.
А тут уже додумывайте ;)

Вы имели в виду верстку, полагаю?

сначала прочитал топик «JavaScript не лучший кандидат в президенты»

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

Вставлю свои 5 копеек.

JS — это как глина, из кода модно слепить все что угодно, как из глины или пластилина, для работы с ним не нужно вообще никаких навыков чтобы получить НЕЧТО, но это нечто не всегда выглядит репрезентативно и иногда напоминает совсем другую субстацию.
C#/Java это уже как детский конструктор из металла, есть жесткие формы и для того чтобы что-то спроектировать нужно сперва в минимальной форме продумать конструкцию.
С/C++(не говоря уже про assembler на котором уже никто не пишет) это как солидный metalworks, для того чтобы на нем что-то сделать нужно как знание материалов, так и инструментов, без этого не только ничего не получится, но может пострадать самомнение пользователя инструментов.

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

С да.
Асм же нынче нафиг не упал. Когда будешь изучать С, тогда и придется где-то и к асму прикоснуться.
С++ уже постольку поскольку. Есть куча языков, где ООП и получше и удобнее сделан.
Так что С++, Java, C# - уже не сильно большая разница (разница между ними в деталях).
Но перед ними сильно желательно научиться хорошо программировать на С.

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

А сильно в современном js ооп отличается от явы, например?

JS это скорее не ООП, а Prototype programming с полным отсутствием типизации, Java это как раз классический ООП, разве что без ручного управления памятью.

class Name extends Name2 {
.....
}

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

assembler на котором уже никто не пишет

нуда, все оптимизации святой дух пишет

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

нет. любая работа с изображениями (или просто большими обьемами данных)

Ну расскажите как мне код на .NET который полностью управляемый и занимается распознаванием изображений Barcodes/OCR оптимизировать на ассемблере. Да оптимизировать проход по памяти или сам порядок операций можно чтобы было как можно меньше сбросов кеша, ну а дальше?

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

Понимаете я написал 50% кода этого движка и знаю на чем оно и как работает. Причем оптимизированный C# работает всего в 3 раза медленнее чем тот же код на С++, с максимальной степенью оптимизации gcc, что нивелируется возможностью многопоточности с балансировкой нагрузки (нечто вроде Erlang многопоточности где идет динамическая загрузка рабочими объектами, дерево выполнения). Так что если вам нужно поднять скорость управляемого кода по работе с изображениями на порядок или больше, то могу проконсультировать.
downloads.aspose.com/barcode/net

Причем оптимизированный C# работает всего в 3 раза медленнее чем тот же код на С++

facepalm

Я тестировал основные алгоритмы (давно), скорость на С++ получается где-то в 3 раза быстрее (релизная версия и там и там). Так что вполне приемлемо, учтивая что получаем унифицированный код, работающий от серверов, десктопа до Android(портируется автоматически на Java) или iOS(Xamarin). Одна универсальная библиотека на все существующие платформы.

где-то в 3 раза

Ничего себе в 3 раза — это жуть как много. А можешь мне подкатить баксов за 200 проц на 15 ггц, ну хоть на 12.

Ну люди же пишут на JavaScript хотя падение производительности достигает иногда 100 и более раз (если браузер не содержит jit-компилятора JS) по сравнению с кодом на том же релизном C++. Но его активно используют.

По сути скорость можно было бы сделать не отличимой от С++ (и даже выше) за счет внедрения OpenCL в критические участки кода, но было отвергнуто руководством, так как усложняет портируемость между платформами.

Так что если вопрос портируемости не стоит крайне жестко, то на C# + OpenCL можно писать любое высоко-нагруженное приложение по работе с мультимедийными данными. Разница между С++ и C# кодом будет в рамках погрешности.

проц на 15 ггц, ну хоть на 12.

Реально любая видяха та же RTX2080 превосходит проц в более чем сотню раз(1000 раз в fp16) в векторно-матричных операциях.

Причем тут OpenCL?

Реально любая видяха та же RTX2080 превосходит проц в более чем сотню раз(1000 раз в fp16) в векторно-матричных операциях.

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

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

А если у тебя что-то итерационное, то тут с написанием под GPU и начинаются танцы с бубнами.

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

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

но все же время нативных компиляторов уже прошло.

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

Фишка OpenCL что можно один и тот же движок одновременно использовать для работы и с CPU и GPU, причем оптимизация кода за счет упрощения конструкций может быть выше чем на С++. Ну и особенности того, что к примеру буфер памяти для CPU ну нужно копировать он передаётся по ссылке, так что сложение двух матриц будет быстрее на устройстве CPU.

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

Так что есть оптимизация кода на уровне code monkey (там важен компилятор), а есть на уровне архитектуры проекта (там компилятор не важен). Только уровень того, кто мыслит архитектурой повыше 23-летних сеньоров.

И здесь ты в рекламных сказках.

Ну и особенности того, что к примеру буфер памяти для CPU ну нужно копировать он передаётся по ссылке

Это не совсем так. Так пока только на Джетсонах и подобном.

О чем вы вообще оба? С++ для математики, JS для io операций. Если мне в ноде нужна будет тяжелая математика, я подключу к ней модуль на С++, если это сайт портала с меньше 50к уников в день — вообще без разницы на чем оно написано, главное на чем удобнее а не что быстрее, пользователь не заметит разницы между долями секунды.

JS для io операций

боже, ну где же вы все беретесь?!?!

причем оптимизация кода за счет упрощения конструкций может быть выше чем на С++

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

Что вам мешает тяжелый код запускать на OpenCL на CPU? В данном случае C# остается как хостовым приложением ну и на нем можно реализовать легкие алгоритмы которые уже обрабатывают готовые результаты. За счет оптимизации кода OpenCL, где компилятор OpenCL чаще всего разрабатывается производителем CPU мы модем получить на 50-100% ускорение даже с С++.

В результат получаем портируемый код, так как C#/Java отлично портируются, как и функции OpenCL(в виде текста или промежуточного кода в OpenCL 2.1). Хост C#/Java + OpenCL как вычислитель.

Ну и оптимизация кода не даёт такого результата как оптимизация алгоритма. Если у нас есть уже проработанный алгоритм, который годами работает и работал, то оптимизация кода может дать выигрыш. Если же алгоритмы новые или экспериментальные, то замена алгоритма может дать ускорение в 100-200 раз. К примеру если сравнить DFT и FFT (я в качестве примера) то модуль преобразования фурье на C# реализующий преобразование по FFT алгоритму кардинально будет быстрее любой оптимизации DFT алгоритма на C++ и даже на assembler.

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

50-100% часто можно достичь лёгкой векторизацией

Это нужно все равно руками оптимизировать код, здесь же код под процессор оптимизирует производитель процессора, просто перекомпилируя исходники или промежуточный код OpenCL. Так что без затрат вы получаете 100% оптимизацию под ВСЕ существующие платформы. Универсальный код, написанный однажды, работает максимально эффективно ВСЕГДА.

Так что без затрат вы получаете 100% оптимизацию под ВСЕ существующие платформы. Универсальный код, написанный однажды, работает максимально эффективно ВСЕГДА

ты в деда мороза тоже веришь?

Что вам мешает тяжелый код запускать на OpenCL на CPU?

не всякий код распараллеливается для гпу

так как C#/Java отлично портируются

с++ тоже отлично портируется

модуль преобразования фурье на C# реализующий преобразование по FFT алгоритму кардинально будет быстрее любой оптимизации DFT алгоритма на C++ и даже на assembler.

оптимизированные алгоритм на плюсах будет быстрее такого же оптимизированного алгоритма на шарпе

так как C#/Java отлично портируются

с++ тоже отлично портируется

В сравнении с 2 выше, вообще идеальная портируемость.

оптимизированные алгоритм на плюсах будет быстрее такого же оптимизированного алгоритма на шарпе

Конечно будет, это если вы делаете клон уже известного приложения. Если разработка связана с исследованиями, то разработка на C# во первых в разы быстрее чем на C++, а замена алгоритма позволяет просто нивелировать для пользователя разницу в скорости. Чаще всего замена N^2 на NlogN или NlogN на O(N) позволяет не парится про оптимизацию. Итерационные лучше заменить на независимые по управлению и данным, даже если они медленнее (но с той же алгоритмической сложностью), это тоже даст прирост за счет числа ядер, которые не используются большей частью ПО на С++.

разработка на C# во первых в разы быстрее чем на C++,

нет

По сути скорость можно было бы сделать не отличимой от С++ (и даже выше) за счет внедрения OpenCL в критические участки кода

а что, если....С++ с OpenCL?

Разница будет только за счет выделения памяти, в C# память выделяется сразу инициализированная 0-лями (safe code) в то же время в С++ можно получить грязную память. Так что разница будет в процентов 5-10, что в рамках статистической погрешности.

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

Давайте так, в таком вот коде вы утверждаете что в С++ элементы массива гарантированно всегда будут инициализированы? Правильно?
C++
int *pia = new int[1000000];

В то же время я утверждаю, что в данном коде на C# все элементы массива будут гарантированно инициализированы базовым значением
C#
int[] pia = new int[1000000];

Правильно?

неправильно
1. это не всегда нужно
2. это легко сделать, если это нужно

Как на C# получить выделенную не инициализированную память без unsafe, с которой можно работать из C# (не просто IntPtr)?

меня не интересуют извращения в сишарпе

С++. вызывай calloc и будет она у тебя инициализирована нулями.
Но эти нули там часто нафиг не нужны.

А вообще для скорости доступа к памяти важнее выделить ее выровненной. Что там у C# с выравниванием?

А вообще для скорости доступа к памяти важнее выделить ее выровненной. Что там у C# с выравниванием?

У C# хорошо не только с выравниванием (автоматически выравнивается по 32 или 64 в зависимости от режима), но и с дефрагментацией памяти, где сборщик способен дефрагментировать уже выделенные блоки и обновить ссылки объектов (любая память в C# - это объект). Правда дефрагментация работает только для объектов меньше 80 кб (там несколько пулов памяти).

С++ с OpenCL

И никакой разницы, если opencl на CPU, причем еще и не нужно гемороиться с opencl. Ну а если есть еще и GPU, то лучше куду (а там С), меньше гемора в сравнении с opencl.
Но для получениz большого количества проблем и борьбы с ними ваш выбор AMD и opencl.

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

Меня просто насмешил выбор С++ или opencl (C там) на CPU.
Внезавно проц обнаружил скрытые резервы и ускорился.
Opencl на CPU поддержали только с одной целью, если у тебя есть код для opencl, то его не нужно переписывать под другую систему команд, а просто запустить и ни для чего более.

А C# помирает. И причина проста — мелкомягкие. Они не сделали сразу кроссплатформенность для него. А по сути это аналог java от мелкомягких и ничего более. Но жабу -то сразу делали кроссплатформенной.

С++

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

JS как язык вообще НЕ хорош)

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

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

Ну да,

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

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

тогда не пишем JS-разработчик, а ангуляр/реакт/етц

Ну скажите мне, что вернет

"AAPL.US".match(/(.+)(\.US)$/g);

А что если так

"AAPL.US".match(/(.+)(\.US)$/);

И что же делать если нужно получить то что во втором случае, но для первой регулярки?

В консоль, google и MDN не смотреть, тыжсиньор.

регулярка не является чем-то уникальным для js

фреймворк-макака — это как без спринга на джаве hello world не родить, например

Понятно, сэр теоретик.

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

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

двое из пяти кандидатов могут назвать

а они с какими погонами были?

Та великое разнообраие от джунов до помидоров. Джуны с опытом 2-3 года обычно лучше справляются, чем типа-синьоры с 8+

Джуны с опытом 2-3 года обычно лучше справляются

джуны с 3 мя годами? Это уже спелый помидор в половине вакансий нынче :D
Ну в принципе логично, не конкретно в этом случае, ибо это действительно юзаеться, но джун недавно только заучил наизусть шпоры, олдфагу же надо вспоминать поведение из опыта, или его вывести по логической цепочке, типа вопросов с баянной серии, так или иначе касающийся valueOf и toString

Это уже спелый помидор в половине вакансий нынче :D

Я в Европе сижу, тут с наших 5летних синьоров орут потихоньку.

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

Да, у меня не такая богатая фантазия

да если бы фантазия )) это я на хабре список для собеса круизных фронт-помидоров посмотрел и в конце его немного прифигел гг :)

Ну часть про BT/bfs/dfs — это как бы достаточно просто, если не сказать тривиально. Что касается доп. хотелок я бы поступил проще: признался честно что я не помню о чем речь, после чего нарисовал бы на доске простенькое BT и попросил интервьюера для каждой из «хотелок» написать желаемый порядок обхода. Если бы он написал — было бы сразу понятно о чем речь и как реализовать. Если нет... ну вы понели.

все просто, если знать в принципе о чем речь, еще лучше конкретный алгоритм, а не выводить его в процессе, тривиально- если подобное до этого писал- но это все не о фронте, и даже не о js dev. Даже если когда раз в жизни выплывет такая задача, то будет и изучена вики, найдет конкретный алгоритм, который лучше всего подходит по описанию и он реализован, хотя, в реальном мире будет найдена готовая реализация :) Это не то, с чем постоянно сталкиваешься, потому реальной ценности, чтобы держать его в КЭШе мозга оно не имеет. Вывести алгоритм и реализовать- разные по сложности и времени. Если проверка на знание алгоритмов BT- они jsнику в 99.99% ни к чему, если умение перенести алгоритм в код- дать нагуглить алгоритм, если уж как он выплывает сам, придумывая велосипед- дать определение понятий, что и как должно работать.

хотя, в реальном мире будет найдена готовая реализация :)

Мне как-то понадобилось программно выбирать цвет текста (черный/белый), более контрасного к фону (цвет фона может быть любой). Пошел гуглить, думал какие-то формулы же должны быть готовые. Первой же или почти первой ссылкой нашел готовую библиотеку, которая уже имела нужный метод.

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

колір фону перевести в HSV, колір тексту вибрати в контраст до V (врахувати, коли V буде десь посередині)

і так, це не типова js задача

а что, сеньор должен регексп наизусть?

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

Ну и собственно, если лень всю цепочку смотреть, то это ответ на:

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

дано строка
const text = ’Lorem ipsum’;
Измерьте длину строки

большая часть людей решает неверно.

Потому что имеется в виду вся строка

const text = ’Lorem ipsum’;

?

std::string s = „Lorem ipsum”;
std::cout << s.size() << endl;

А там юникод внезапно. И начинаем мерять в сантиметрах.
Но да, если локаль C и это только те символы, что в ASCII, то так сработает.

а какой именно юникод? таки лучше мерять в сантиметрах

Именно. С юникодом тоже зоопарк.

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

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

Для фронта длина строки это длина строки а не количество символов.

Интересно, что такое для фронта длина строки? Так как фраза «Длина строки это длина строки», мне ничего не объясняет :(

может в сантиметрах? годная для фронта длина строки — 26см (тм)

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

размер изображения в верстке, первично позиционируется к пикселям

к поинтам

это уже имеет мало практического смысла

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

Хороший тамада, и конкурсы интересные...

А вы точно с шириной не путаете?

для этого задания важна игра слов

На UI есть понятие width и height. В коде — length. Было бы странно говорить о length в контексте UI. Если бы вы спрашивали о width строки, избавили бы и себя и кандидата от разночтения. Ubiquitous language и все такое.

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

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

Должно быть вы говорите это основываясь на строке

Для фронта длина строки это длина строки а не количество символов

тут идет пояснение к вопросу почему .length не единственно возможное решение
далее

в пикселях

тут идет речь о том что пиксели практичнее,

это уже имеет мало практического смысла

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

Просмотрев ответы вы увидите что нигде нет фразы где я сказал что измерение в символах верно\неверно, есть только

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

Также можно найти

на удивление оказалось что люди действительно отвечают по разному

Это и есть полезный опыт который мы получили с ответов на этот вопрос.

Мои выводы основаны на этих фразах:

большая часть людей решает неверно.
большая часть людей отвечают .length

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

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

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

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

Не знаю, что там в вебфронтенд-мире, а в приличном UI это не длина строки, а размер (высота + ширина)

const text = ’Lorem ipsum’;

Где здесь UI ?

dou.ua/...​rums/topic/26444/#1524227

в пикселях, ... изображения в верстке, первично позиционируется к пикселям

Где в задаче сказано про UI ?

Вот именно. Тогда к чему тут шрифт?

Так и я о том же)

Тогда почему .length неправильный ответ?

Так правильный) я не говорил, что неправильный. Наоборот, я пытался выяснить каким боком здесь UI, если в задаче не слова об этом. Я вообще считаю что показав строчку кода, глупо расчитывать на другой ответ. Разве строки только для надписей нужны на фронте?)

Ну вот Alex Koshterek об этом тоже намекал.

Не, я так понял он всетаки о другом)

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

А в JavaScript размер строки определяется количеством символов в ней.

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

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

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

тут идет речь о том что пиксели практичнее,

смотря для чего.

Для фронта длина строки это длина строки а не количество символов.

Нет, для фронта, как и у всех людей, это будет ширина строки. Особенно если контекст не верстка, ибо уже написали строчку кода. И если уж на то пошло, то фронт это клиент, а не верстка. Но даже верстальщик это не назовет длиной строки.
Покажите мне где это в DOM есть свойство длина инлайн блока el.length? Чего это назвали width. Может хоть в canvas measureText() - returns the length of the text? Опять нет- все тот же width.

большая часть людей отвечают .length

Слава байтам! Представляю:
— const text = ’Lorem ipsum’; Измерьте длину строки...
— String.prototype.length!
— Неправильно! Мы на фронте! У нас длина строки это ширина блока в верстке!
— (неуправляемый процесс высвобождения большого количества тепловой и лучистой энергии в результате цепной ядерной реакции ниже спины)

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

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

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

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

Я уже давал ответ на этот вопрос, посмотрите внимательно топик.

Измерьте длину строки
большая часть людей решает неверно.

Неверно?! Скорее большая часть не умеют правильно формулировать вопросы, ибо никакой другой длины строки тут быть не может, ну кроме как в байтах, хотя это обычно size будет. Имхо, это только формошлепу-верстальщику в третьем колене могло бы сбрендить, что в вопросе о js длина строки это ширина инлайн блока, или канвы :)

ибо никакой другой длины строки тут быть не может, ну кроме как в байтах

В случае юникода — запросто.

ну так и это есть размер(size) строки, оно же длина строки в байтах, а сколько байт 2-4 на символ вообще другой вопрос...

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

Ну например стандарт Юникода различает символы и code points (хз как это перевести на русский). Вот пример реализации стандарта (эликсировский модуль String):

iex> string = "\u0069\u0307\u0301"
"i̇́"
iex> byte_size(string)
5
iex> String.length(string)
1
iex> String.codepoints(string)
["i", "̇", "́"]
iex> String.graphemes(string)
["i̇́"]
То есть в зависимости от контекста длина строки может быть 1 (если считать в графемах-символах — дефолтное поведение), 3 (если считать в code points) или 5 (если считать в байтах). Именно это я и имел в виду, отвечая на ваше «никакой другой длины строки быть не может».

в принципе, это все физическое представление символов в памяти, иными словами «длина в байтах», для чего там каждый байт юзаеться не так важно, все это частные случаи и обычно интересовать может 2 варианта- количество символов или raw длинна в байтах

обычно интересовать может 2 варианта- количество символов или raw длинна в байтах

Ну типа да. Обычно. Головняк начинается, когда что-то пошло необычно. Смотрите:

iex> s1                  
"é"
iex> s2
"é"
iex> String.length(s1) == String.length(s2)
true
iex> byte_size(s1) == byte_size(s2)
false
Упс. А все потому, что
iex> String.codepoints(s1)
["e", "́"]
iex> String.codepoints(s2)
["é"]
Т.е. один и тот же символ может быть представлен в юникоде двумя разными способами. Визуально они одинаковые, «длина строки» (если мерить в символах) одинаковая, но представлены по-разному. Это конечно можно считать несущественными деталями реализации — пока не придется дебажить...

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

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

Нет ничего более вечного, чем холивар вокруг JS...

А как же Java vs. .NET? Или с выходом .NET Core поутих?

Просто джависты смирились с поражением :-)

им некогда спорить.. надо код писать )

Я надеюсь, что Блазор выстрелит «JS-серы» тоже поутихнут. Для меня это весь спор о безграничном величии JS звучит как «Ребята смотрите, мы можем засунуть себе этот огурец в задницу. Это, конечно, весьма необычно но к этому просто нужно привыкнуть. Главное, что это описано в спецификации.».

Ни на что не претендую, чисто мое мнение. Все совпадения вымышлены. Ни один огурец не пострадал.

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

Так никто и не спорит, что можно.

Я надеюсь, что Блазор выстрелит

Тоесть для .net-чиков соваться во фронт — это норм, а для джс-ников куда-то еще это

весьма необычно

Я уже начал пет-проекты на блейзоре писать, это круто, скажу всем из мира js да и вообще — ничего лучше .net история не придумала, люди еще стесняются, но таки и им придется перейти😁
А теперь с выходом blazor, .nет покрывает весь стек технологий, учить намного меньше дерьма придется.

Да, вот тоже ковыряю потихоньку.

ничего лучше .net история не придумала

Ну, как человек

из мира js да и вообще

Могу согласиться, но только за счет F# :) а не Blazor, он для меня как глоток воздуха после всего остального с чем довелось работать

А вы уже встречали большие проекты на blazor ? Лично то что видел я — это пара страничек да пара кнопочек. Вроде как интересная штука, но выстрелит ли она? Был уже когда-то тут один silverlight))

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

Ты делать что-то хочешь или просто языки изучать? Потому что если тебе интересен фронтенд, то там есть только JS и вопрос снимается.

Знаю лично людей которые успешно работали мидл фулл стеками (Angular2+ и .NET) с зп $2500+ писав фронт чисто на ts, и тот же ajax в жизни не видели=)

А ts типа не JS совсем. Если так, то я уже года 3 пишу только на es6.

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

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

Особенно вещи типо вложенных ajax’ов.

Вообще такое полезно знать как работает даже если пишешь на фреймворках и ts. Например если знать только async/await и не знать про promise — можно писать неоптимальный код там где не нужно.

сли знать только async/await и не знать про promise — можно писать неоптимальный код там где не нужно

есть ссылочки что почитать для самообразования на эту тему?

пишу только на es6

так это же не модно... надо или ts, или хотя бы flow- чтобы хоть как то притронутся к миру взрослых java и не чувствовать себя ущербным ;)

притронутся к миру взрослых java

к чему-чему?

что можно в ajax видеть? Умиляет когда в помидорских вакансиях еще и пишут это отдельной строкой в скилл листе...

Не «в ajax» а просто «ajax» =) И больше умиляет когда приходит чувак на позицию синьор фул стека и не знает что это)

Так а нафига знать-то? Это же какой-то архаизм. Есть fetch и async/await.

архаизм:) , у которого год как в экспериментальном состоянии только появилась возможность оборвать запрос и то c диким костылем типа AbortController как по мне, вместо того чтобы подмешать эту событийную функциональность прямо в Promise, и чтобы this в цепочках указывал на его контекст, а не global.

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

Ну не знаю как такое в принципе возможно. Если еще и речь не про сам xmlhttprequest (и то там особо не была нужна никакая абстракция, чтобы вполне удобно юзать, особенно как отпали старые 7-е ослы), а и библиотечные обертки, то как он вообще выжил? )) Совсем не знать и не слышать это вряд ли возможно. Это был свежий ангулярист по факту?

Любой язык — это инструмент, в умелых руках способен создавать и радовать, в неумелых создает только проблемы. JS — это «швейцарский нож», который подходит на все случаи жизни, о чем и говорит концепция javascript everywhere. Возможно начинать стоит с «молотка», где все четко и понятно. С другой стороны, научившись работать с JS уж точно найдете себе место в айти.

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

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

JS — это «швейцарский нож», который подходит на все случаи жизни

А вот это была неправда...

в каком месте неправда?
— фронт js
— бэк js (Node JS)
— десктоп приложения js (Electron)
— кросс платформ мобайл js (native js, react js)
— ардуино и ежи с ними js
— нейронные сети js

Про применение WebAssembly в принципе молчу...

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

1. Скорость разработки, и как результат удешевление разработки.
2. Кол-во прогеров на рынке
3. Комьюнити и документация, как результат первых двух.
4. Простота создания прототипа.

Уже после MWP на JS можно выбирать технологию и архитектуру для решения специфических задач этого самого MWP.

Пример с микроскопом и троллейбусом совсем не очевиден, получается подмена понятий. JS это все же ЯП, я не предлагал писать код из кубиков азбуки. Захотите проверить мои слова попробуйте сравнить скорость написания прототипа на Джаве и на Жс.

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

Если у Вас знания js до 2015 года, то да, наезд на язык вполне оправдан, все же язык сценариев браузера, сегодня все намного лучше))

Интересно, много ли фронтов, которые всю жизнь формочки клепали, смогут запилить нейронку? Электрон — то еще Г, а для мобильной разработки таки лучше использовать родные инструменты, а не лепить везде js.
Для вэба — да, js пойдет, хотя MEANы, MERNы и прочие наборы букв с нодом сзади, популярны значительно меньше всяких пых и питонов.

Ну а в целом да, написали правильно — на коленке что-то быстро склепать на js, лишь бы делало вид, что работает, а позже использовать нормальные технологии :)

Интересно, много ли фронтов, которые всю жизнь формочки клепали, смогут запилить нейронку?

да, смогут. Гляньте brain.js — простой как угол дома, и видяшку как-то видел, там мумазель размер одежды на фронте через нейронку делала.

и считает жаббоскрип, конечно? или оно просто враппер в ++ код?

А вы сколько нейронок запилили за последний год? :)

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

фронт js

разьве что

бэк js (Node JS)

нода написана на плюсах. остальное — враппер

— десктоп приложения js (Electron)
— кросс платформ мобайл js (native js, react js)
— ардуино и ежи с ними js
— нейронные сети js

facepalm

Советую пройти курсы по софтскилам, Вы не умеете общаться.

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

Такой высокомерный тон, ого! Оставлю Вас фрустрировать в одиночестве.

Первые два да, остальное спорно (чем ниже по списку тем более спорно). Например я использовал node-webkit (это вроде электрона но не электрон). Плюс — большие возможности в плане UI, можно встроить YT-видео (мне нужно было), не нужно учить другой язык, кросс-платформенность. Минус — размеры самого приложения. Ну и в целом экономия скорости разработки за счет производительности. Я писал приложение лично для себя, поэтому считаю допустимым не думать о ресурсах. А вот идея пихать электрон везде мне лично не нравится. Это же по полноценному браузеру на приложение. И если не нужна работа с файлами/устройствами — почему не сделать просто веб-приложение в классическом виде

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

А на счет уместности и верности при выборе технологического решения, в реальности хуже языкового холивара. Проекты выходят откровенно написанные на чем попало. Ругать Электрон или nwjs можно, если не сталкивались с Cordova или Meteor.

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

В итоге — любой ЯП можно использовать как швейцарский нож.

Просто Konstantin Strukov решил меня обвинить в неправоте, я привел примеры, где юзается жс, по мимо фронта.

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

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

Я не знаю куда вам гики руби пихали, но я тут при чем? Не хотите попробовать в конструктив вместо фанбойства? Или «...if all you have is a hammer, everything looks like a nail»?

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

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

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

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

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

Что нам из запада скидывают, то и супортим.
Если пишут у нас с нуля, то зависит от команды и прочих важных факторов.

Прочие важные факторы — сделать быстро и дешево))

Вот это и есть правда, которую Вы хотели.

Вы еще и читать не умеете? Я не спрашивал вас ни о какой правде (тоже мне оракул из Дельф), я спросил видели ли вы когда-нить например жесткий реалтайм или взрослый компилятор, написанный на джс. Вместо этого вы мне рассказываете как космические корабли на ноде бороздят отечественный аутсорс... Ну и ладно.

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

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

интересно, с кем еще сегодня попрощается на всех обиженный г-н Котов?

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

Ба, да у Вас тут тусовка целая! Мне не сложно я поясню. Есть расхожая фраза «на все случаи жизни», обычно когда ее употребляют имеют в виду для широкого круга типичных задач. Конечно, для узкого спектра задач жс не подходит. Но мне казалось, что большого интеллекта не нужно прям понять такую простую фразу, которую достаточно часто мы слышим вокруг нас. Предвижу Ваш следующий вопрос, «достаточно часто», я вряд ли смогу посчитать в минутах. Это еще одна расхожая фраза, впрочем как и вокруг нас.

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

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

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

«Ты ж програмист!», прочти переписку последовательно. Я высказал свою точку зрения, Вы сказали что она не правдива, я привел доказательства. Вы прицепились к «фигуре речи» и далее по списку. В Каком месте я не умею общаться? У меня потеряна причинно следственная связь? Или написание компиляторов — это типичная задача, которая может войти в «фигуру речи» на все случаи жизни? Шановый, не рефлексируйте.

Мне с первых Ваших строк показалось, что у Вас есть проблемы с коммуникацией, потому и посоветовал прокачать софт скилы.

Мало того, что вы вместо ответов на конкретно поставленные простые вопросы льете водичку на какие-то вообще ортогональные материи. А теперь вот еще оказывается, что вы еще и не помните, кому и что говорите. Беда прямо. И, главное, зачем все это? «Я дерусь потому что я дерусь?» Все равно ж пришли к тому, с чего начали

Конечно, для узкого спектра задач жс не подходит

Ну так Влад же дружаня Ваш. Вы так резво накинулись на меня. прям про жс забыли. Си+руби, что Вы делаете в топике про жс?
Не пришли ли поиздеваться над убогими?
Может я открою для Вас Америку, но не существует ЯП для всех задач. Любое универсальное решение, плохо себя проявляет в узком спектре задач. Применительно не только к ЯП, в реале точно так же. Потому даже смыла не было открывать эту дискусию. Но зачем-то Вы начали. Может уже пришло время закончить? Или последнее слово должно остаться за Вами?

JS — это «швейцарский нож», который подходит на все случаи жизни, о чем и говорит концепция javascript everywhere.
Может я открою для Вас Америку, но не существует ЯП для всех задач.

«Астанавитесь» ©

нода написана на плюсах. остальное — враппер

Все написано на плюсах, а остальное по тексту ... ))

это шиза
зачем отвечать Константину с цитатами моих слов?

Ну так Влад же дружаня Ваш

(facepalm) (popcorn)

— десктоп приложения js (Electron)

Угу.. есть тут одно поделие выжирающее от 500МБ до гига памяти просто ничего не делая. Память стоит теперь дешево? А вот глупые пользователи почему-то не согласны...

Сложность фронт-энд разработки еще в том, что мало того что JS во многих местах не очевиден

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

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

Если у Вас знания js до 2015 года, то да, наезд на язык вполне оправдан, все же язык сценариев браузера, сегодня все намного лучше))

Я не то же самое сказал? К чему Ваша ремарка, вырванная из контекста?

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

все норм сейчас

Угу, особенно когда требования энтерпрайза «шоб в ie11 работало». И начинается веселье с babel, полифилами и т.д. Все таки останусь при мнении что фронт сейчас и на ближайшие пару лет просто сплошной костыль...

Угу, особенно когда требования энтерпрайза «шоб в ie11 работало»

Недавно в интернетах читал что кто-то из майкрософт призвал не пользоваться ie11 (точнее вот)

И начинается веселье с babel, полифилами и т.д.

И сколько там того веселья? Установить зависимости и прописать конфиг gulp/webpack/etc? В фреймворках со своим cli может быть даже проще. Например babel из коробки, а для добавления полифила нужно или 3 строки в конфиг добавить, или поставить аддон.

Куда хуже поддерждивать верстку для ie11. Там полифила нет.

И сколько там того веселья

ну для 5-ти летнего проекта у которого 30 плагинов с огромной кодовой базой это не тривиальная задача)

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

С ними нет никакого веселья, делаешь 2 билда и все, да и уже многие не поддерживают ие11

Ну это ie отсталый, это же не проблема в самом джс

Начинайте с АSM. Он точно ошибок не прощает.

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

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

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

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

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

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

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

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

Ну, да, о том, что это глупо было сказано еще в начале ветки.

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

UPD: проблема не только бизнес, но техническая и организационная тоже (список может быть больше)

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

JavaScript отличный язык! Рекомендую изучать через MDN.

IT в принципе не лучший кандидат для входа. Это только кажется что тут всё охуенно, выучился и ОК. Только всё новое пишется быстрее, чем ты можешь его выучить. А 50% времени тебе придётся тратить на образование ВСЕГДА.

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

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

На строгих языках тоже можно наговнокодить. Для того чтобы не запутаться есть паттерны и принципы программирования. Я бы не рекомендовал конечно рваться в более строгий typescript не поняв javascript. Лучше начать с азов и двигаться в сторону современных популярных SPA фреймворков таких как React, Vue, Angular. Советую воспользоваться анализаторами типа ESLint для того чтобы твой код был единообразным.

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

А перегружать страницу в браузере не бесит? :-)

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

Как и в любом другом компилируемом языке.

а если Node.js? то какую страницу будешь апдейтить?)

Хоть нод, хоть пыха, хоть шо угодно, браузер без сервера — пустая вкладка.

Не факт, главное данные откуда-то брать, например с Firebase

а firebase — він не на сервері?

я имею ввиду что js-приложение может работать без

нод, хоть пыха, хоть шо угодно

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

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

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

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

это точно не java script

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

А обилие синтаксического сахара в последней версии языка так вообще укоряет написание кода в разы.

Это точно про JS, не C#?

Конечно, чего только стоят спрэд синтаксис и диструктивное присваивание. Может уже есть аналоги в C# ? Может я что-то пропустил ?

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

О какой скорости разработки может идти речь если в JS нет ни ООП ни типов? Есть языки с б"ольшим количеством синтаксического сахара, и при том с системой типов.

в JS нет ни ООП ни типов

Уже давно есть нормальные классы и наследование. А типы там всегда были. Нет строгой типизации, это разные вещи.

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

Тоесть Вы всетаки настаиваите что

в JS нет ни ООП ни типов

?

Уже давно есть нормальные классы и наследование

А что такое «нормальные классы»?

Ну, когда-то было подобие классов, поэтому уточняю

Я так понимаю, вы имеете в виду только синтаксис?

Я имею ввиду механизм описания данных. Да, можно сказать синтаксис.

да вообще то и под C# можно разрабатывать в блокноте.
dotnet build в командной строке и готово:
docs.microsoft.com/...​tnet-build?tabs=netcore2x

Зачем студия?

О .net core я ничего плохого не говорю, наоборот. Но в те времена, когда я уходил в фронт, его еще не было.

лол
.net framework тоже билдится из командной строки
и так было всегда
нужно только сам фреймворк установить — в книге рихтера описано как в блокноте собрать .net framework проект

а скорость и удобство разработки

разработки чего? javascript в основном для UI, .net в основном бэкэнд к этому UI.
Или вы про razor? Ну его мало кто любит и мало кто использует, я уже забыл когда его видел.

Насколько помню в js на блокноте никто ничего не пишет и в рабочие инструменты давно вошли всякие TypeScript, webpack, jsHint или как он там с проверкой синтаксиса.
По скорости проверки написанного visual studio ничем не уступает вышеупомянутым тулам, если у вас конечно старенький пень то да, проблема таки в пне, а не в среде. Ну и на работе у меня уже лет 5 как SSD, I7 и16 Гб оперативы, что легко справляется хоть с компиляцией хоть с этой возней со скриптами и браузерами.

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

на работе у меня уже лет 5 как SSD, I7 и16 Гб оперативы

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

более резвый, более экономичный

смешно

и все?
может проект на дотнете запускается быстрее? или может студия не ставит раком комп с параметрами ниже среднего? или может кода на С# нужно меньше писать?

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

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

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

на электроне Visual Studio Code
Классическая студия на С++ и С#

Меня не бесила. Наверное потому, что любую копиляцию готовят. Тут и строгая типизация помогает, и решарпер, и голова. Нажал F6 раз в час — нормально. В JS, напротив, бесит десяти-двадцати секундная сборка после каждого чиха. Потому что даже после многих лет с JS никогда не будешь уверен, заработает, или заработает не так. Возможности отладчика Студии и браузера сравнивать тяжело. Так что сборка JS проектов меня напрягает больше, чем компиляция шарпа.

бесит десяти-двадцати секундная сборка после каждого чиха

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

Возможности отладчика Студии и браузера сравнивать тяжело

Кто запрещает отлаживать js в IDE ?

Кто запрещает отлаживать js в IDE ?

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

Тут зависит как сборщик настроен и разбивка на модули.

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

В JS, напротив, бесит десяти-двадцати секундная сборка после каждого чиха

Хз, нажимаю Ctrl+S в IDE и пока переключаюсь на браузер — там уже обычно перезагрузилась страница или перезагружается. Долгая сборка (10-20с) только в начале рабочего дня

Да любой плох, вообще программирование все плохо, хорошо когда код писать не надо

если начать с JavaScript то все будет плохо?

смотря как начинать, по каким учебникам/курсам/туториалам/видосам)

JavaScript как первый язык хорош или нет?

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

Многие советуют начать со строгих языков.

то тогда лучше учить TypeScript (ну он точно строже джаваскрипта будет) или C# / F# с прицелом на ASP.NET (ASP.NET Core) + есть компиляторы из С# и F# в джаваскрипт (например, bridge.net и fable.io ).

Учи тот с которым собираешься работать, а если чисто с циклами и базовыми алгоритмами поиграться то любой.

то любой

«учу посикс тредам на яваскрипте. дорого...очень дорого»

Как потоки коррелируют с «циклами и базовыми алгоритмами»?) К тому же в том же node.js подъехали воркеры благодаря которым можно ознакомиться с многопотоком.

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

Чувак решит что хочет идти во фронт, зачем ему нативные треды? Странная логика короче.

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

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

нах эти потоки нужны?

радует количество лайков под этим

А меня нет. Потоки будут отдавать в Индию, а сюда только формошлепство.

а меня да — никто потоки в Украину отдавать не будет

Их потом можно изучить при необходимости. Не сразу же дроны на марс запускать.

не сразу. сначала на Земле оттестировать

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

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

учу DOM деревьям на си дорого, очень дорого

на плюсах будет дешевле, потому, что оно написано на плюсах

Зачем потоки если есть RX библиотеки, или же Futures или же монада IO в асинхронном контексте выполнения?

асинхронном контексте выполнения?

это не означает мультипоточности

Только потоки в джс безопасные

потоки в джс

где там потоки? и чем они безопаснее посих потоков?

rtfm, или 70 баксов в час и я тебя могу учить

(шум сливаемой воды)

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

ты мне 2 часа будешь втирать про несуществующие треды? это еще круче чем сеньор на иос по 400

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

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

афинити нет, но синхронизация по желанию доступна/возможно в некоторых окружениях

в браузере и ноде, 99% окружений js

т.е. тредов в жаваскрипте нет

нет, но в джс их можно легко использовать

нет

с тебя 140 баксов

читай внимательно что я писал, а не то что ты себе нафантазировал

а сама синхронизация в джс :)

покаж мютекс в джаваскрипте

ты вначале в башке своей разберись — то ты спрашиваешь за синхронизацию — то за паттерны.

синхронизация есть — паттерн можно либо самому запилить либо в библиотеку запхать

ты вначале в башке своей разберись

спишем на возраст

то ты спрашиваешь за синхронизацию — то за паттерны.

блядь. мютекс — паттерн. убейте меня

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

объясняю для дебилов

все, свободен
дискуссия с тобой не отвечает моим эстетическим нормам

ну что-то далеко напоминающее есть это ВебВоркеры. Всякие coinhive активно их юзают

JavaScript как первый язык хорош или нет

(хр-моде-он) кем вы себя видите через 5 лет?(офф)

г**нокодить можно на чем угодно и как угодно. Бери и делай

Пфф.. на Go ведь невозможно:))

На го проще всего, ибо сам по себе язык к этому распологает.

Подписаться на комментарии