Прочитав данный перевод первоапрельской статьи о JavaScript я был удивлен тому, к каким мелочам могут придираться люди. И проблема не в самой статье, не в мемах и шутках о данном языке, а в том, что кто-то неиронично утверждает что JavaScript — плохой язык программирования. Но что, если попытаться его понять?
Ответьте на вопрос, если вы разрабатываете на JS, то что именно? Может быть вы работаете на FrontEnd-е, может вы разрабатываете небольшое BackEnd приложение на nodejs, а может вы являетесь разработчиком в банке где все ПО написано на нем? Если третий случай это про вас, то скорее всего вы где-то ошиблись.
Проблема в том что ни один язык программирования не сможет стать панацеей от использования разных ЯП для достижения определенных целей. Но почему-то кто-то до сих пор считает что какой-то язык да заменит все существующие, станет универсальным и вообще спасет весь мир. Но обычно инструменты создаются под решение конкретных задач (хоть тут слово «конкретный» может включать довольно обширный спектр этих самых задач), и даже швейцарский нож не решит всех ваших проблем.
JavaScript хорошо справляется с задачами, для которых его чаще всего используют. А большинство лулзовых случаев, которые были рассмотрены в вышеуказанной статье являются сферическими конями в вакууме и в реальной разработке попросту не будут применены.
Первым делом хотелось бы привести в пример следующий отрывок с кодом:
const x={
i: 1,
toString: function(){
return this.i++;
}
}
if(x==1 && x==2 && x==3){
document.write("This will be printed!")
}
Действительно, условие будет истинным. В таких случаях у меня возникает два вопроса — «Зачем?!» и «Как так получилось?». Дать ответ на первый вопрос я к сожалению не могу. Но вот попытаться ответить на второй вполне. Как известно JavaScript — язык с динамической типизацией. В нем есть два способа сравнения — строгое (===) и с преобразованием типов (==). Если бы в коде было использовано строгое сравнение, то никаких проблем бы не возникло. Но во втором случае интерпретатор пытается привести оба операнда к одному типу (строке) и сравнить их значения. Но почему-то истинность условия `x == 1 && x == 2 && x == 3` кому-то кажется смешной, несмотря на то, что нечто подобное можно реализовать и в других языках:
public class JavaScript {
public static void main(String[] args) {
AnonymousObject x = new AnonymousObject(1);
if (x.equals(new AnonymousObject(1)) && x.equals(new AnonymousObject(2)) && x.equals(new AnonymousObject(3))) {
System.out.println("JavaScript == Java // true");
}
}
}
class AnonymousObject {
public int i;
public AnonymousObject(int i) {
this.i = i;
}
public boolean equals(AnonymousObject that) {
return this.i++ == that.i;
}
}
Кто-то скажет что тут использована функция .equals(), а там .toString(), что они предназначены для разных целей, что имплементация функции .toString() не должна влиять на сравнение, да и вообще это другое. Но если использовать строгие сравнения в JS то проблемы не будет, а вот в Java данное условие всегда будет истинно.
Ещё есть претензия к функции .sort(), мол она сортирует лексикографически:
[-2, -7, 0.0000001, 0.0000000006, 6, 10].sort()
// [-2, -7, 10, 1e-7, 6, 6e-10]
Но передадим мы функцию для сравнения и все внезапно работает как надо:
[-2, -7, 0.0000001, 0.0000000006, 6, 10].sort((a, b) => a - b)
// [-7, -2, 6e-10, 1e-7, 6, 10]
Кто-то снова возразит, сказав что в <название ЯП> все работает как надо и что вы, когда переходите с одного языка на другой хотите чтобы все было как раньше. Но знаете, я начал изучение программирования с Паскаля, там оператором сравнения был один знак равно. Представляете как мне не хотелось переходить на современные языки из-за того что в них два, а то и три знака?!
Под конец хотелось бы обсудить многопоточность в JS. Причина, по которой в JavaScript-е нет нормальной реализации многопоточности не в том, что язык какой-то не такой и он просто не способен на что-то такое, а в сфере его применения — web разработка. Ведь язык программирования это всего лишь спецификация, а её реализация лежит на компиляторе / трансляторе / интерпретаторе. В веб-разработке вам в принципе не должна понадобиться возможность исполнять ваш код в несколько потоков. Если вам часто приходится прибегать к ней, то скорее всего вы делаете что-то не так. Если вам нужна многопоточность на nodejs, то как и написано в исходной статье для этого есть разные библиотеки: comlink, указанная там или paralleljs, которая на мой взгляд удобнее в использовании. А если вас не устраивает дополнительная зависимость, то скорее всего вам нужен другой ЯП. Получить все и сразу попросту не выйдет.
Всем этим я просто хочу сказать, что если язык массово используется, то он имеет право на существование. А если при разработке на каком-либо языке вы сталкиваетесь со множеством трудностей, то пересмотрите ваш выбор, а не вините язык. Ведь, как говорил Бьёрн Страуструп:
Есть всего два типа языков программирования: те, на которые люди всё время ругаются, и те, которые никто не использует.
UPD:
Прочитав комментарии я решил уточнить две вещи:
1. Сказав, что многопоточность в вебе не нужна в принципе, я имел ввиду что она не нужна в большинстве случаев, а не то, что она совершенно не нужна. Есть случаи, когда нужно вынести какие-то вычисления в отдельный поток, чтобы не нагружать основной, но они довольно редки
2. Я ни в коем случае не утверждаю, что JS лучший язык, способный заменить все остальные и спасти мир. Я наоборот, пишу что везде его применять не стоит. Да и статья в принципе не столько о JS, сколько о том, что хейтить языки только потому что они не нравятся именно вам, только потому что там что-то работает не так как вы ожидали не надо. JS это всего лишь язык, который я привожу в пример так как прочел статью именно о нем. На его месте мог бы быть любой другой язык, потому что хейт может быть в сторону любого из них
nin-jin
Претензия прежде всего в том, что она сортирует используя не оператор сравнения, а что-то иное, не важно даже что. Это полнейшая глупость.
Чем веб разработка такая особенная? Это просто платформа для исполнения кода вашего приложения. И потребности зависят от того, что это за приложение. Представьте себе, не все занимаются формошлёпством.
BaZzing0
NodeJs там нету формошлепства. По скорости работы на сколько мне известно сопоставим с php. Все чаще его выбирают как основу для backend в своих приложениях
Alekseyz
А зачем тащить js на backend? Дешевле разрабы чем на java, .net? Или есть какие-то другие веские причины?
apapacy
Интересно, а какие веские причины тянуть на бэк микросервисную архитектуру, которая основана на общении микросервисов по http-протоколу, который в свою очередь был разработан для общения браузера с веб-сервром. Почему бы не использовать для общения микросервисов на стороне бэка rmi или CORBA?
Alekseyz
Потому-что во многом удобно использовать rest api и http, а не corba. А насколько удобно лепить «многопоточного» слона из js и тащить его на бэк? Ну правда, чем это оправданно?
apapacy
Мне кажется что rest api там используются не только поэтому. Вернее было бы уточнить а почему это стало удобно. Ответ мне на эти оба вопроса кажется связанным.
1) Сначала развитие веб привело к потребности в разработки различных инструментов для своей работы — от стандартов, средств сетевой инфраструктуры — до веб-серверов и веб-браузеров.
2) Потом интернет массово распространился что привело к обкатке всех этих средств миллиардами пользователей. И вот в этот именно момент эти средства начинают становиться удобными.
3) Теперь оказывается что в нашем распоряжении есть надежный протокол https, инфраструктура для работы по этому протоколу и такие же надежные библиотеки, веб-браузер на движке v8 и наконец сам движок v8 на котором построен nodejs.
И нет ничего удивительного в том, что
Причина все та же — удобно, требует минимальных ресурсов на сервере, и минимальных затрат на разработку.
syusifov
и вся эта белиберда привела к отстою в индустрии на долгие годы
apapacy
Предположительно сейчас всех сделает mobile. Точно так как раньше всех сделал браузер. Правда монстры ERP этого еще не поняли. Но рано или поздно появятся mobile-first ERP и картинка станет другой.
JustDont
Не появится — этому мешает обычная реальность, данная нам в ощущениях: разглядывать информацию с экрана телефончика, даже большого — совершенно ужасно.
Но вот рабочие места для людей, которые данные в основном вбивают, тем или иным путем — они уже начинают быть mobile-first, да. Потому что если можно данные не вбивать, а фоткать и уверенно распознавать — это огромный прорыв в скорости работы. Ну и мобильным работникам это очень удобно (естественно).
А вот всякая отчётность и прочая аналитика из браузеров никуда не денется — работать с такими вещами на большом экране просто значительно удобнее.
Kanut
Извините, но это всё субъективно. Вам это может быть и ужасно, кому-то нормально, а кому-то вообще нравится. Особенно если рассматривать не на «экране телефончика», а скажем на планшете с нормальным экраном.
JustDont
Я повидал достаточно аналитиков, и некоторым из них даже софт писал. Нет, не субъективно. Mobile-first пригоден тем, кто данные вводит и особо ничего не смотрит, и mobile-first очень нравится биг боссам, которые воображают что-то в духе «глянул в мобилку — а там пишут, всё ли у тебя в конторе хорошо, или есть проблема». Короче, как кнопка «сделать всё хорошо». В реальности так не бывает, но в демках востребовано, да.
ЗЫ: Планшет — это по приёмам работы всё тот же телефончик, только экран побольше. Показать больше информации (или столько же, но видной издалека) — отлично работает, работать с планшетом как с ноутбуком/десктопом — вообще не вариант, даже если какая-нибудь пристегивающаяся клавиатура есть.
apapacy
Ну давайте идти дальше. Зачем нормальной ERP еще и аналитик? Тут на подходе ИИ.
JustDont
Ну как только сильный ИИ запилят, так вот прям сразу, ага.
А без него — аналитик затем, что он новости читает, по сторонам смотрит, и в силу этого способен выдать не только отчётик по историческим показателям, но и прогнозы, например. Настоящие прогнозы, а не «запихаем график цены биткоина в нейросетку, чтоб сказать, куда цена дальше пойдет».
Groramar
По тому как я вижу как работают аналитики, то ИИ уже текущий может справится уже наверно даже лучше.
apapacy
Причем тогда к новостям ERP. В конце концов сделать что-то десктопное для аналитика на mobile-first erp будет более реальной задачей чем переписать на мобльную версию тяжелую ERP
Вот Вам пример. Знаменитый аналитик https://en.wikipedia.org/wiki/Mary_Meeker (это как Лебедев только а аналитике и в Америке) ничего раньше не говорила про коронавирус и теперь не сказала что будет после коронавируса. А простой парень из Америки, Билл Гейтс уже двадцать лет в эту тему миллиарды топит.
Kanut
Ещё как субъективно. Я вот например дома в инете сижу в основном с планшета. И на нём мобильные приложения обычно гораздо удобнее чем соответствующие странички. Конечно бывают и исключения, но в большинстве случаев это так.
А уж если я захожу на смартфон, то там странички можно смотреть практически только в мобильной версии и это ещё хуже.
И я это считай уже «старпёр» и «ретроград». А молодёжь сейчас вообще большую часть времени в своих смартфонах сидит и всё на них делает. И они браузер гораздо меньше меня используют.
apapacy
Реальность она не всегда соответсвтует нашим ожиданиям от реальности. Реальность такова что многие тяжелые ERP как раз сделали интерфейс для мобильных устройств для боссов чтобы могли со смартфона увидеть основные показатели в цветных графиках. А что касается производства — то здесь как раз бы и нужно внедрить мобильные девайсы чтобы можно с ними было бродить по цеху или лазить по штабелеру. Но увы. Для этого слишком много нужно переделывать.
JustDont
Угу. Полезность этого как правило очень грустная, но да, сделали как раз это. Но это не mobile-first ERP ни разу.
apapacy
Об этом я и говорю. Изначально тред начлся с утверждения что тяжелые ERP не идут в мобайл, а если и идут только для галочки.
uldashev
Что бы переложить часть компетенции с дорогих программистов на относительно дешевых админов.
apapacy
Не буду спорить про дешевизну админов, хотя DevOps, которые сегодня поддерживают микросервисную инфраструктуру сейчас в цене, как раз по причини востребованности микросервисной архитектуры. Но почему все же эта инфраструктура дешевая? Не потому ли что прочие средства обмена данными, например CORBA, не будучи востребованной в таком количестве как http, требует привлечения редких специалистов и сложных инфраструктурных решений?
Да и речь тут не об этом. Тредстартер почему-то допускает, что для общения микросервисов можно привлекать дешевую инфраструткуру и массовых (не будем называть их дешевыми) специалистов. Хотя, по гамбургскому счету нужно было бы юзать, скажем J2ЕЕ beans. Но тут же, почему-то, для разработки этих же самых микросервисов, по мнению тредстартера, нельзя юзать простой, быстрый, надежный и массовый nodejs.
Какие-то двойные стандарты.
kmeaw
js уже есть на фронте. Так можно переиспользовать код и иногда даже людей.
Пример переиспользования кода — валидация полей форм.
Free_ze
На практике, кроме пресловутой валидации и каких-то мелких классов-утилит, переиспользовать-то особо и нечего. И людей особо не переиспользуешь — специфика работы сильно другая.
kmeaw
deleted, ara опередил меня.
Free_ze
Океееей, но прикладные к вебу вещи (какую-то часть варидации данных инпута, серверный рендеринг SPA) — это ведь слезы на фоне размера кодовой базы бизнес-логики типичного приложения. ara пишет про «большие куски», что они из себя могут представлять и почему они не могут остаться на одной из сторон?
ara
У меня не типичное приложение, которое представляет набор веб форм, а что то вроде многопользователськой онлайн игры. В этом приложении идет обмен бинарными данными между броузером и сервером в обоих направлениях. Соответственно есть логика которая сериализует и парсит эти данные, есть много общих интерфейсов, описывающих данные и алгоритмов, применяемых к ним.
ara
Я не особо люблю JavaScript, но в моем случае делать бэеэнд на NodeJS было отличной идеей по этим причинам:
typeof null === "object"
и т.д.), то получается очень хороший язык, который лично мне нравиться намного больше чем, например, Java.RoykerZen
Я всегда с трудом понимаю аргумент про «переиспользование фронт-энд кода на бэкэнде»… Моя основная специализация — бэк-энд разработка, но на нескольких проектах приходилось быть фулл-стэком, и, исходя из того опыта, могу сказать, что если возникает необходимость на бэк-энде выполнять тот же код, что и на фронт-энде, то в 90% случаев это сигнализирует о плохой архитектуре (а еще 10% — это вышеупомянутая валидация форм и что-то подобное).
faiwer
а как же SSR?
VolCh
Ещё вариант: offline first и прочий UX, с оптимизацией времени отклика и прочих UX метрик: сначала посчитаем, потом в фоне загрузим на сервер, посчитаем ещё раз, а если что-то пойдёт не так, то выведем ошибку и откатим.
AriesUa
Веб разработка особенна тем, что обращение к DOM API должно происходить из одного потока. Представьте, что у вас два или при параллельных потока и и все они в одим момент времени меняют свойство DOM. Как думаете, что произойдет?
Вот и повелось с тех пор, что JS это один поток. Сейчас появились WebWorker, но они удобны для вычислений, а вот с DOM из воркера напрямую вы работать не сможете, по причине описанной выше.
nin-jin
И зачем мне ваш DOM, если я ренделю в WebGL?
fougasse
Так можно сказать, что и под винду всё должно быть однопоточно, ведь UI поток он только один.
Странное оправдание, если честно.
AriesUa
Я не оправдываюсь, я просто указал почему так. Если у вас есть идеи, как сделать правильно и лучше, думаю вы можете написать разработчикам браузеров.
Кстати, рекомендую почитать статьи на тему «почему JS однопоточный». Вы найдете исчерпывающие ответы.
fougasse
Так почему так? Веб не ограничен манипуляциями с DOM, как и софт на десктопе не ограничен работой в UI потоке. Изначальные причины из начала 2000х, конечно, понятны. Но аргументов, почему это продолжается в 2020 году, кроме «а скажите, как сделать лучше, а мы подумаем» не слышно.
Это как с многозадачностью на смартфонах, и много где ещё. Только не нужно про мовместимость со старым кодом и т.п., 6й осёл давно умер.
AriesUa
Можете поподробнее в этом месте? Так веб, который я знаю, живет в браузере. А вот в браузере это DOM.
Кстати, приведу пример. Оговорюсь, я не противник и не сторонник, живу с тем что есть. Так вот. Давайте представим ситуацию, на странице у нас, пусть будут, два DIV.
Итак в классической однопоточной схеме, мы меняем ширину первого DIVа. Что делает браузер? Напишу примитивно, детали вы сможете нагуглить. Браузер пересчитывает всю сцену, все элементы, их размеры и стили. От верхнего левого угла и до нижнего правого.
Теперь представим, что у нас два потока. Итак первый поток, как я написал выше меняет ширину блока. Браузер проводит пересчет всех размеров… И в этот момент, второй поток меняет ширину второго блока.
Внимание вопрос — что произойдет?
PS осел конечно умер, но наследие осталось.
Tyusha
Добро пожаловать в canvas и в WebGL в частности. (Эту мысль выше несколько резко выразил несправедливо заминусованный nin-jin)
Akuma
А в других языках можно работать многопоточно с OpenGL/Dx?
Я просто не в курсе, но интересно. По идее там те же самые проблемы будут и решены они, наверное, костылями вида «нельзя что-то делать из другого потока».
ZiggiPop
Да вроде можно:
https://gamedev.ru/community/ogl/articles/multithreading
JustDont
Ну это же не параллельная отрисовка разными потоками. Это параллельная подготовительная работа. А отрисовывает на экран — всё равно, в любом случае, один поток.
Akuma
Тогда не понятна суть претензий к JS. Никто не мешает подготавливать вычисления в отдельном потоке, а потом передавать их в поток отрисовки.
wunderwaffel
Как раз-таки понятна: помимо манипуляций DOM можно ещё дела делать параллельно, синхронизуя по меобходимости с основным потоком. Как и написано выше в комментах — не UI единым.
Akuma
Ну так а я о чем? Делайте дела параллельно в вебворкерах, кто мешает то?
wunderwaffel
Оверхэд?
Akuma
Нет
wunderwaffel
Похоже на то. Тогда о чём тут ноют? :shrug:
Спасибо за информацию.
Akuma
Я не знаю о чем тут остальные ноют. У меня ужасно глючат комменты на этой странице, тут слишком много нытья :(
Free_ze
Да
lostero
Коротко: данные устарели и задержки не критичны, если подходить с умом.
Ну, 2015 года статья.
80kB/ms не так мало для того времени.
Единственный момент был у меня на мобильном железе (iphone [5:7] с 11-ым safari) перекодировка 2.5 минут PCM в MP3 с передачей в основной поток занимала 10-30 секунд. Перекидывание бинарника занимало много меньше чем перекодирование в MP3 JS кодировщиком (wasm там багованный). Даже в основном потоке там быстрее не перекодировать т.к. ресурсов мало выделяется на новый браузер на старом железе.
Спамить воркерами это вообще плохой тон (и вообще спамить). Хотя используется во всех примерах т.к. прописывать управление воркером (пулом) в них неразумно.
Тут мастера купиПасты и распространяют ересь. Так же поступают с Audio контекстами, с запросами к мультимедиа устройствам и ко многим другим API (это прививается с потребительского отношения к DOM, захочу — дёрну).
P.S.
Отсюда удалена портянка про заражённый разными болезнями браузерный зоопарк, их описанием и следствиями из этого
А JS как ЯП на своём месте. Достал Notepad++ закодил идею, кинул в консоль, сверил результат с ожиданиями и пошёл принимать решение (а как было бы весело подстраиваться под кучку браузеров в других языках...). Если JS браузерного не хватает, можно выкинуть на сервер в крайнем случае. А там в зависимости от задачи свои инструменты.
Респект разработчикам движка v8, меньше разработчикам nodejs (о производительности редко думают, приходится аддон нативный гонять для http сервера) и разработчикам браузеров (оставляют баги в API без фиксов).
Free_ze
Есть более новые, где цифры стали меньше на порядок?
Десятки миллисекунд — это очень критично. Настолько, что вы про пулы начали рассказывать и что нужно уметь готовить. Ведь это и был контр-поинт на комментарий, на который я отвечал. А ведь это в еще относительно примитивном вебе наших дней, когда клиент тонок, а бэкграунд таски — это скорее исключение, чем повсеместно используемая штука, имхо.
Флудить? Спам — это про рекламу обычно.
lostero
TLDR; Если найдёте пример, где критично время создания воркера и нельзя заранее его создать, то соглашусь, что оверхед при создании воркера значителен для современных устройств в работе с воркерами. Пропускная способность и RTT довольно хорошие.
А. Поддержка устройств, выпущенных раньше 2015 года, крайне мала. Автор скорее всего на них и тестировал. ОС-ы также поддерживают меньше старого софта. Железо дешевле и производительней.
Пересобрал бенч из статьи (лютый бред там, но для сравнения изменений с 2015 пойдёт). Все значения для стандартного postMessage.
'Latency' (в реальном приложении вы не станете бомбардировать воркер десятками сообщений каждую миллисекунду):
Создание воркера (тут накладываются расходы на подгрузку скрипта воркера — диск. кэш не мгновенный, в идеале inline worker нужно создавать и не страдать фигнёй, если нужно быстро):
Скорость передачи данных (для забивания канала нужно передавать 100-1000MB+ в секунду):
Советует не передавать больше 3MB/26MB в одном сообщении для Mob. и Desk. соответственно.
Б. На большинстве устройств можно в реальном времени аудио с микрофона в воркере в MP3 загонять и в это же время анализировать аудиопоток и выводить красивую графику в 60fps. Делал такое 2 года назад, только 1 устройство (iphone 5-6, не помню точно) не справлялось и пришлось на все iosы отложенную кодировку делать (на нём всё упиралось в железо и JS движок, т.к. даже в основном потоке оно не могло перекодировать данные за приемлемое время).
А пока 2-3 кадра основной поток может и подождать создания воркера (даже всю логику можно в воркеры вынести и оставить только изменения UI в основном потоке, а-ля локальный клиент-сервер). Всё упирается в умения разработчика.
Про пулы и прочее: либо вы хотите макс. скорость вычислений, либо макс. экономить потребление памяти. Это вечная проблема в программировании и от неё не уйдёшь.
В. И флуд и спам не подходят, но суть вы поняли.
P.S.
Проклинаю автора бенча и по совместительству статьи, которую вы подкинули. Судя по репе принадлежит к касте бездумных сборщиков. Куча ненужного Г в проекте.
И сам проект пришлось перелопатить/почистить, т.к. он не работает из коробки и имеет кучу ненужного хлама.
Вообще нужно иметь представление о технологии (лучше опыт работы с ней), чтобы не кидать результаты бенчей сомнительного качества. Также вы бы знали, что создавать воркер на лету и закидывать его данными плохой тон. Этот этап развития 'поток на каждый запрос' показал себя неэффективным, когда нужна макс. производительность, на front и end частях веба.
YemSalat
Так в JS тоже можно. WebWorkers, все дела
kmeaw
Разработчик может захотеть выполнить какие-нибудь вычисления, не дожидаясь окончания отрисовки. Это бывает полезно, например, в играх.
По поводу потоков — можно либо заблокировать второй поток при попытке обратиться к DOM на запись, либо поставить запрос на изменение в очередь, либо даже начать исполнять его параллельно, если браузер так будет уметь (например, инвалидируя часть результатов первого расчёта прямо в то время, пока он выполняется).
HEKET313
Лет 9 назад, когда я писал на C# для WindowsForms и WPF, там подобные действия вызвали бы исключение, в разработке на Java под Android, если мне не изменяет память, изменение UI из параллельного потока — тоже вызывает исключение. Возможно, в каких-то языках можно одновременно из нескольких потоков выполнять действия над UI, но в тех, с которыми работал я — нельзя. Нужно сначала вернуться в главный поток, который может работать с UI, и потом уже из этого потока выполнять над ним действия.
DmitryOlkhovoi
JS это имплементация стандарта ECMAScript который нечего не знает о DOM. DOM это уже другой стандарт и API браузера. Как бы, что раньше, курица или яйцо. DOM не причина однопоточности JS :)
Браузер это движок JS + движок рендера. Одно является имплементацией JS, другое имплементацией DOM и прочих стандартов по типу веб сокетов и интерфейсов.
В многопоточном мире есть огромное колво инструментов для работы с подобными задачами. JS обращается к DOM через event loop, который по своей природе однопоточный, но то куда ведет этот чудный мост, зачастую C++ который многопоточный. И рендер в браузере многослойный и часть интерфейса может рендерится отдельно от другой. Возьми тот же css transform и посмотрим на слои. Однопоточно все только для тебя, как для пользователя DOM.
Удачи — https://github.com/ampproject/worker-dom
AriesUa
Не забывайте, что DOM появился раньше чем JS. И JS подстраивался под DOM. Собственно, почитайте историю развития. Повторюсь, я не защищаю JS. Мне самому не нравятся некоторые вещи.
Сейчас мы имеем то что имеем.
AriesUa
Когда приводите пример, хотя бя гляньте как это реализовано под капотом. Но если вам лень, то в кратце — реализация основана на обмене сообщениями из дочернего потока в основной. И уже основной поток работает с DOM.
Удачи.
DmitryOlkhovoi
Да какая разница, люди юзают его для обновы DOM с вычислениями в отдельном потоке и это главное.
JS не работает с DOM, он работает с DOM API. C DOM работает движок рендера который умеет в асинхронщину.
Да да, сперва было яйцо, а попа у курицы под него подстроилась. DOM для JS — инструмент который не входит в стандарт языка. Посыл, что JS синхронный из за DOM попросту не очень
Твой пример выше
Это известный кейс когда происходит репейнт и рекалькуляция лаяута из за работы с размерами, офсетами и тд. Но есть куча других апдейтов и разные слои которые можно асинхронно обновлять. Сама структура DOM в виде дерева идеально подходит для асинхронных обновлений в разных местах.
Ты как пользователь ограничен одним потоком, и твои обновления не редко попадают в буфер, перед тем как движки выполняют апдейты, но тебе и не нужна чистая асинхронная возможность обновления DOM.
faiwer
Но ведь это правда :-) Язык ведь изначально предназначался для "игрушечных" нужд, вот и не завезли в него многопоточности. Причина именно историческая. Стало быть, глядя на то что происходит сейчас, то и ещё будет, в него ещё завезут столько всего, что пожалеем.
KasperGreen
Минутка занудства — сначало было яйцо. Яйцо динозавра, который тысячами и миллионами лет эволюционировал в курицу.
AriesUa
Извиняюсь, но что вы мне хотите доказать? Что DOM API кривое? Так и так все знают что оно кривое. Что JS так себе? Так и мне не нравятся многи вещи в JS, примеру наследование на прототипах. Что в JS нет нормальной многопоточности. Ну ок.
Да, так история сложилась.
Хотите это улучшить — так я только «за». И если у вас получится выкатить лучший движок и язык — я с удовольствием буду его, и его инструменты, использовать. OpenSource позволяет сделать форки и улучшить что либо. А ломать копья и не предлагать что либо в замен — так себе.
kornerr
Написал гневно человек на сайте. Оказалось, что все пользуются сайтами, даже те самые, которые не формошлёпят.