Будет ли JavaScript лучше, если он будет многопоточным

Question

Это дополнительный вопрос к Есть ли смысл в многопоточности ?

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

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

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

Answer 1

Брендан Айх (технический директор Mozilla) рассказал о сложности, которую это может создать в « Threads suck ».

Его вывод: «Поэтому мой стандартный ответ на такие вопросы, как тот, который я получил в мае прошлого года на Ajax Experience« Когда вы добавите потоки в JavaScript? », Звучит так:« поверх вашего мертвого тела! »

Использование веб-работников * Альтернативой является 1010 *.

Answer 2

Если бы JavaScript был многопоточным, был бы он лучше, чем существующая система?

На что именно вы ссылаетесь, когда говорите «существующая система»?Выходящий Javascript встроен в ваш браузер?Или автономные реализации Javascript?

Я не пытаюсь определить JavaScript как неэффективный

Язык сам по себе не эффективен или неэффективен, это реализация.: -)

Принесет ли многопоточность с одним потоком пользовательского интерфейса и другие задачи в разные потоки (фон) более быстрое реагирование и эффективное использование ресурсов?

Rhino, Javascriptна JVM в Java можно получить доступ и использовать потоки и любую другую библиотеку Java, так что да, вы можете создать сценарий для всего приложения Swing на Javascript, и оно будет работать как любое другое приложение Swing на Java.

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

Answer 3

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

Рядом с веб-работниками, JS, серверная JS, в частности, также склоняется к асинхронностиобработка, еще больше устраняя необходимость в линейной обработке.

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

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