|
| 1.3, Пушистик (ok), 21:05, 18/04/2014 [ответить] [﹢﹢﹢] [ · · · ]
| –6 +/– |
 "В процессе компиляции серверная часть компилируется в нативный код"
Для неё Native Client нужен или нет? А то он запускает машинный код в различных браузерах и на разных ОС. А на снимке Chromium.
| | |
| |
| 2.30, XoRe (ok), 21:35, 19/04/2014 [^] [^^] [^^^] [ответить]
| +/– |
 > "В процессе компиляции серверная часть компилируется в нативный код"
> Для неё Native Client нужен или нет? А то он запускает машинный
> код в различных браузерах и на разных ОС. А на снимке
> Chromium.
Серверная часть - это та часть, которая выполняется на стороне веб сервера.
Серверную часть они почему-то решили делать с нуля - скомпилированный бинарник сам биндится на порт и отвечает на http запросы, используя либу libpion.
Хотя его, конечно, все ещё можно спрятать за nginx, странно, что они не используют fastcgi/wsgi/etc для этих целей.
| | |
| |
| |
| 4.35, XoRe (ok), 10:30, 20/04/2014 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> Благодарю, КЭП, но речь была не об этом.
Оно компилится в бинарник, без всяких браузеров.
| | |
| |
| |
| 6.40, XoRe (ok), 16:36, 22/04/2014 [^] [^^] [^^^] [ответить]
| +/– |
>>Какие хромы на сервере?
> Есть хромы для серверов.
Если вы про nodejs и v8, то там этим даже не пахнет.
| | |
|
|
|
|
|
| 1.4, Tav (ok), 21:12, 18/04/2014 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
 Использование C++ обычно пытаются оправдать производительностью. А здесь? Это для тех, кто готов на все, лишь бы не изучать другой язык?
| | |
| |
| 2.5, Аноним (-), 21:35, 18/04/2014 [^] [^^] [^^^] [ответить]
| –10 +/– |
На js уже всё пишут, он даже для распределенных высоконагруженных систем подходит. За ним будующее!
| | |
| |
| 3.6, A.Stahl (ok), 21:39, 18/04/2014 [^] [^^] [^^^] [ответить]
| +8 +/– |
 >будующее
О всеспящий Ктулху, пусть это будет невероятно тонкий сарказм, а не индикатор общей грамотности JavaScript-тистов///
| | |
| 3.19, Аноним (-), 01:32, 19/04/2014 [^] [^^] [^^^] [ответить]
| +2 +/– |
Js как раз позволяет снизить нагрузку с высоконагруженных систем,
выполняя часть функционала на пользователе. Будущее, конечно, у этого
не особо хорошо спроектированного языка несомненно есть,
поскольку сейчас бум веб творчества, всем нужны сайты. Каждый чих
порождает новый сайт, даже багу heartbleed сделали сайт.
| | |
| 3.39, Потерпевший (?), 07:19, 21/04/2014 [^] [^^] [^^^] [ответить]
| +1 +/– | |
Боюсь показаться занудой, но ведь собственно "подходимость" javascript как языка, то есть синтаксис и семантика, не имеет отношения к проектам типа node.js, выполняемых в v8. Вы же на это намекаете?
Будущее мне понятно. Раз у нас есть суперпрограмма, которая уже без пяти минут ОС (браузер) с виртуальной машиной и песочницами, то, действительно, часть вычислений с серверов имеет смысл переложить на пользователей, не зря же они себе всякие i7 покупают.
Непонятно только причем тут именно js, сложный и неудобный язык?
| | |
|
| 2.8, хм (?), 21:52, 18/04/2014 [^] [^^] [^^^] [ответить]
| +1 +/– |
В Emscripten основная идея в портировании существующего кода. Портировали удачно и эффектно, но ни для чего кроме игрушек пока не используют так чтобы с пользой.
Здесь очередной Web-фреймворк, теперь банановый. Тоже игрушка, но другого плана.
| | |
| 2.17, Crazy Alex (ok), 01:22, 19/04/2014 [^] [^^] [^^^] [ответить]
| +/– |
 А здесь - промышленный строго типизированный язык, пригодный для написания больших проектов. Впрочем, это решает только часть проблемы - безумный комплект "DOM/HTML/CSS" остаётся всё тем же - громоздким и плохо предсказуемым.
| | |
| 2.20, Аноним (-), 01:37, 19/04/2014 [^] [^^] [^^^] [ответить]
| +/– |
> Использование C++ обычно пытаются оправдать производительностью. А здесь? Это для тех,
> кто готов на все, лишь бы не изучать другой язык?
Ага, порадовало предупреждение:
Warning: Depending on the browser and system configuration this demo may use a lot of memory
| | |
|
| 1.7, Xasd (ok), 21:42, 18/04/2014 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
 > прямой маппинг C++ объектов в объекты JavaScript, что позволяет снизить потребление памяти, так как сборщик мусора JavaScript имеет возможность удалять неиспользуемые объекты
JavaScript позволяет, но как это задекларировать внутри C++ ?
или же получается что это не C++ а лишь язык похожий на него, но существуенно отличающийся при детальном осмотре.
| | |
| |
| 2.9, хм (?), 21:54, 18/04/2014 [^] [^^] [^^^] [ответить]
| +/– |
>> прямой маппинг C++ объектов в объекты JavaScript, что позволяет снизить потребление памяти, так как сборщик мусора JavaScript имеет возможность удалять неиспользуемые объекты
> JavaScript позволяет, но как это задекларировать внутри C++ ?
Так же как и в JavaScript -- никак^W удалить все ссылки на объект.
| | |
| |
| 3.21, Xasd (ok), 13:50, 19/04/2014 [^] [^^] [^^^] [ответить]
| +/– |
>>> прямой маппинг C++ объектов в объекты JavaScript, что позволяет снизить потребление памяти, так как сборщик мусора JavaScript имеет возможность удалять неиспользуемые объекты
>> JavaScript позволяет, но как это задекларировать внутри C++ ?
> Так же как и в JavaScript -- никак^W удалить все ссылки на
> объект.
в C++ же "указатели" а не "ссылки" :-)
["ссылки" тоже есть.. но C++ "ссылки" это не тоже самое что "ссылки" Javascript]
| | |
|
|
| 1.10, iZEN (ok), 22:32, 18/04/2014 [ответить] [﹢﹢﹢] [ · · · ]
| –9 +/– |
 Что только ни придумают, на какие хитрости только ни идут с мухлежом ведванольных "построителей чудес" (JavaScript, HTML5), но лишь бы не использовать Java-апплеты!
| | |
| |
| 2.11, TEye (?), 23:01, 18/04/2014 [^] [^^] [^^^] [ответить]
| +3 +/– |
а из других языков много чемпионов по числу уязвимостей превосходящих Яву?
| | |
| 2.12, corr256 (ok), 23:11, 18/04/2014 [^] [^^] [^^^] [ответить]
| +/– |
 Сударь, с вашими аплетами я могу порекомендовать вам посетить Криптон.
| | |
| 2.24, Xasd (ok), 14:35, 19/04/2014 [^] [^^] [^^^] [ответить]
| +4 +/– | |
> Что только ни придумают, на какие хитрости только ни идут [...], но лишь бы не использовать Java-апплеты!
если эти Java-апплеты такие чудесные -- то не хочешь ли ты протолкнуть идею чтобы в библиотеки для KDE и GNOME -- включили бы функции вывода Java-апплетов внутри GUI-программ?
представляешь как здорово было бы -- открываешь ты какой-нибудь музыкальный проигрыватель -- а он в свою очередь подгружает Java-апплет!
вот веселье-то будет и для разработчиков и для пользователей :-) :-D .. я уже сейчас предвкушаю тонны нецензурной лексики :-)
| | |
|
| 1.14, Жлой (?), 00:22, 19/04/2014 [ответить] [﹢﹢﹢] [ · · · ]
| –2 +/– | |
Вроде скриптовые языки с утиной типизацией для того и придумывали, чтобы разрабатывать веб-приложения _быстро_. А сейчас - Facebook выпустил Hack (подмножество PHP со статической типизацией), MS выпустил TypeScript (JS со статической типизацией), Google пропихивает Dart (замена JS, язык со статической типизацией)
Тут авторы еще дальше пошли, C++ под веб пропихивают. Мне кажется это глупо в квадрате. Во-первых, на С++ писать дольше и сложнее. Во-вторых, при трансляции в JS многие прелести C++, а в частности скорость, в значительной степени потеряются, т.к. JS код останется JS кодом и будет выполняться всё теми же JS движками
В чём смысл, кто объяснит?
| | |
| |
| 2.16, хм (?), 00:58, 19/04/2014 [^] [^^] [^^^] [ответить]
| –1 +/– |
>Facebook выпустил Hack
>MS выпустил TypeScript
>Google пропихивает Dart
и что?
| | |
| 2.18, Crazy Alex (ok), 01:30, 19/04/2014 [^] [^^] [^^^] [ответить]
| +2 +/– | |
В том, что эта быстрота начиная с определенного размера проекта оборачивается граблями. Пока JS использовался для оживляжа страничек и реализации отдельного не слишком важного функционала - он был приемлем. Когда дело дошло до больших приложений - приходится что-то решать.
Чем больше проект - не важно, IT или что-то ещё - тем важнее формализация взаимодействий. К примеру, мелкая контора из пяти человек может работать практически без бюрократии. Если у вас пара сотен сотрудников - вы не обойдётесь без должностных инструкций, формально прописанных полиси и тому подобного. Собачью будку или сарай можно просто построить. Для многоэтажки не обойтись без чертежей, строительных норм и тому подобного. Не потому что это кому-то нравится, а потому что без этого вы вообще ничего не построите. Для общего развития - вот: http://rusnano.fizteh.ru/courses/levenchuk/ - рекомендую хотя бы первую лекцию глянуть.
| | |
| |
| 3.23, Xasd (ok), 13:58, 19/04/2014 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> Чем больше проект - не важно, IT или что-то ещё - тем важнее формализация взаимодействий.
кто же вам мешает сделать формализацию для процесса разработки на JS ?
для этого не обязательно придумывать другой язык, который конвертируется в JS.. всё можно организовать на самом JS..
посмотрите крупные проекты на JS -- там всё формализованно без всяких TypeScript и Dart.
| | |
|
| 2.22, Xasd (ok), 13:55, 19/04/2014 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> Мне кажется это глупо в квадрате.
мне тож так кажется :-)
писать приложения на Javascript
--- это быстрая разработка но медленная скорость полученного приложения..
писать приложения на C/C++
--- это медленная-и-сложная разработка но быстрая скорость полученного приложения..
писать приложения на C/C++ с компиляцией в Javascript
--- это медленная-и-сложная разработка и медленная скорость полученного приложения..
:-)
а Emscripten хорош лишь только тем что с помошью него -- можно скопилировать в Javascript те алгоритмы, которые были *раньше* реализованы на C/C++..
(портировать уже готовое C/C++ приложение с использование Emscripten -- может занять времени меньше чем разработать всё с нуля на Javascript)
а чём же прелесть Duetto -- вообще не понятно.
| | |
| |
| 3.25, iZEN (ok), 15:07, 19/04/2014 [^] [^^] [^^^] [ответить]
| –1 +/– | |
Плюсую.
писать приложения на Java без компиляции в JavaScript, а с JIT-компиляцией в код процессора
--- это быстрая разработка с потреблением большого количества памяти, но с высокой скоростью и безопасностью выполняемого приложения в конечном итоге.
Ошибки в Java быстро находятся и исправляются благодаря развитым инструментам наблюдения и профилирования байт-кода. Повсеместно на Java принято использование автоматических модульных тестов, а в других средствах программирования на других языках это всё ещё находится в зачаточном состоянии, если вообще что-то есть. В других языках практически нет способа объективной оценки подтверждения корректности программ кроме ручного тестирования каждой функции.
| | |
| |
| 4.27, vn971 (ok), 15:52, 19/04/2014 [^] [^^] [^^^] [ответить]
| +2 +/– |
 Не забывайте, мы говорим о client-side приложениях.
Апплеты я уже давно не видел в вебе и видеть не хочу. Это спорно, вы можете доказывать мне что я не прав и должен любить джаву, но по факту её на client side нет (или количество пренебрежимо мало).
Иными словами, у вас жуткий оффтопик.
| | |
| 4.28, тоже Аноним (ok), 15:58, 19/04/2014 [^] [^^] [^^^] [ответить]
| +/– |
 > Повсеместно на Java принято использование автоматических модульных тестов
В энтерпрайзе - возможно. А, например, под тот же Андроид на той же Жабе пишет конный и пеший. И хорошо, если хотя бы один из десяти этих пишущих вообще знаком с таким термином.
Каким бы языком ни пользовались для раздувания веб-пузыря - это заведомо будет массовый говнокод, без острой необходимости никем и никогда не разгребаемый. Сейчас под эту раздачу попал Джаваскрипт, но если его заменит что-либо другое - результат будет аналогичным.
| | |
|
|
| 2.26, vn971 (ok), 15:46, 19/04/2014 [^] [^^] [^^^] [ответить]
| +/– | |
А вы давно в программировании? Просто, как мне кажется, существует много других обстоятельств помимо "утиной" или "не утиной" типизации.
Например:
поддержка модели акторов (dart, м.б. scalajs),
поддержка функционального программирования (haskell-js, scalajs),
поддержка макросов в стиле плюсов,
поддержка макросов в стиле lisp/clojure,
поддержка макросов в стиле AST-трансформаций (scala, rust,..),
weak и strong typing (не путать с динамичностью!)
и так далее и тому подобное.
Причём по моему комменту может быть видно что я всякими "Скалами" и статическими языками увлекаюсь -- а если бы взгляд был шире, то я бы сказал и почему питоно/php/ruby-подобные языки в JS компилят.
И, кстати, вот это не совсем верно, т.к. вы не забыли о том же asm.js:
> JS код останется JS кодом и будет выполняться всё теми же JS движками | | |
| 2.32, XoRe (ok), 21:49, 19/04/2014 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Во-первых, на С++ писать дольше и сложнее. Во-вторых,
> при трансляции в JS многие прелести C++, а в частности скорость,
> в значительной степени потеряются, т.к. JS код останется JS кодом и
> будет выполняться всё теми же JS движками
> В чём смысл, кто объяснит?
Компании типа фейсбука могут себе позволить потратить кучу человеко-месяцев, чтобы их приложение работало на 10% быстрее (т.е. даже небольшой профит - уже хорошо).
Просто они решают конкретные проблемы, которые стоят именно перед ними.
И если у вас нет таких проблем (и таких ресурсов), никто не заставляет вас применять их решения.
К примеру, в mail.ru, лет 10 назад тоже писали свои велосипеды, которые им требовались.
Им нужно было, они и писали.
Сейчас модно со всеми делиться своими наработками.
Но от того, что вы можете это скачать, не значит, что вам это нужно.
| | |
|
| 1.29, Пиу (ok), 16:48, 19/04/2014 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
 наконецто можно будет писать на нормальных языках вместо этого убогого js
| | |
| |
| 2.31, XoRe (ok), 21:42, 19/04/2014 [^] [^^] [^^^] [ответить]
| +/– | |
> наконецто можно будет писать на нормальных языках вместо этого убогого js
Не забывайте, что потом все равно код транслируется с нормального языка в убогий js
| | |
| 2.34, Аноним (-), 08:57, 20/04/2014 [^] [^^] [^^^] [ответить]
| –1 +/– |
Пока школота на нормальном языке неделю борет одну утечку на ровном месте, жалкие ремесленники с яваскриптом лепят по два безглючиных и в меру шустрых приложения в день.
| | |
|
|
