LINUX.ORG.RU
Ответ на: комментарий от foror

так никто не пилит, это никому не нужно

с одной стороны те кто на ноде это трогать не будут - зачем? v8 круче

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

umren ★★★★★
() автор топика
Ответ на: комментарий от umren

так никто не пилит, это никому не нужно

я пилю, мне нужно )

с одной стороны те кто на ноде это трогать не будут - зачем? v8 круче

Не круче java, бенчмарки уже кидал, отставание в разы. Нету в ноде мультитрединга. И к тому же, nashorn+java красивее выглядят и интегрируются, чем nodejs+c.

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

Затем, что людям нужны альтернативы - https://www.google.com/trends/explore#q=grails, spring framework, spring mvc,...

foror ★★★★★
()
Ответ на: комментарий от foror

v8 круче

Если грамотно распределить обязонности между java и nashorn, то последняя связка будет круче и быстрее. А если тупо эмулировать node.js, то тогда да v8 будет круче.

foror ★★★★★
()
Ответ на: комментарий от lazy_aleks

nashorn тухнет с каждым апдейтом

Я только рад, что насхорн по перформансу сравним с nodejs, а с оптимизациями в 9-ке может и обойти по перформансу. Но памяти будет жрать за два nodejs, если не за 3-4. Пока в 10-ке не докинут нам array 2.0 и value types, по памяти будет все плохо.

foror ★★★★★
()
Ответ на: комментарий от foror

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

lazy_aleks
()
Ответ на: комментарий от lazy_aleks

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

umren ★★★★★
() автор топика
Ответ на: комментарий от lazy_aleks

Он был сопоставим, а за последние 2 апдейта они все сломали.

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

Производительность подпилят и можно уже будет и над джавой думать.

Что думать? Как скриптота (да еще убогая) может заменить типизированный язык? Или GWT от нечего делать изобретали?

После webassembly джаваскрипт начнет терять в популярности, быстрее, чем руби сейчас теряет свои позиции. А это уже ближайшие два-три года Если лебедь, рак и щука будут в одном направлении телегу тянуть.

Да и, честно говоря, я фиг знает зачем они его там усиленнопилят.

Ну как минимум на замену не взлетевшому груви, для всякой скриптоты. А как максимум гибкая интеграция java+javascript в новых веб-фреймворках.

foror ★★★★★
()
Ответ на: комментарий от foror

После webassembly джаваскрипт начнет терять в популярности, быстрее, чем руби сейчас теряет свои позиции. А это уже ближайшие два-три года Если лебедь, рак и щука будут в одном направлении телегу тянуть.

ты ваще читал что это такое? :D мне кажется ты не понимаешь что это такое и зачем это нужно, это никак не конкурирует с яваскриптом

umren ★★★★★
() автор топика
Ответ на: комментарий от foror

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

Хорошо, если так. Будем надеяться, потому что я за многообразие и конкуренцию.

Что думать? Как скриптота (да еще убогая) может заменить типизированный язык? Или GWT от нечего делать изобретали?

Легко и просто. Питон, пхп и руби тому доказательство. Ну не особо нужна статическая типизация. Для того, чтобы парсить json и писать в базу оно нафиг не нужно, а статика еще и многословности добавляет. А вот зачем создавали гвт мне вообще не особо понятно, хорошо, что оно массово не взлетело. Каким нужно быть ССЗБ, чтобы писать на этом. Даже на жабоскрипте приятнее писать интерфейсы.

После webassembly джаваскрипт начнет терять в популярности

Я, конечно, не эксперт, не вчитывался даже в эти материалы еще, но разве там не тот же самый жс будет?

Ну как минимум на замену не взлетевшому груви, для всякой скриптоты. А как максимум гибкая интеграция java+javascript в новых веб-фреймворках.

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

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

lazy_aleks
()
Ответ на: комментарий от lazy_aleks

Ну не особо нужна статическая типизация.

Она нужна для проектов больше «hello world». Иначе бы не пихали сейчас аннотации типов в python3, и не предлагали бы это в es7 стандарт.

А angular2 он уже юзает аннотации типов, через babel или typescript, потому что по другому очень сложно создавать с большую систему. И я их прекрасно понимаю, начав делать веб-фреймвор без типизации на es6.

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

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

Я, конечно, не эксперт, не вчитывался даже в эти материалы еще, но разве там не тот же самый жс будет?

От жс останется только модернезированная вирт. машина. У гугла будет некий v8++ (мультитрединг, ручное управление памятью, статическая типизация), у мелкомягких и лисы свои совместимые вирт. машины.

Да, сможешь и дальше пилить на жс. Но также у тебя появится возможность работать с DOM через любой ЯП, умеющий выдать байт-код новой вирт. машины. Т.е. тот же Java Applet, только в браузере из коробки без всяких сторонних плагинов и более тесной интеграцией с железом.

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

Ну это плохое решение, т.к. скриптота сковывает масштабы проекта и его перформанс. Да можно интегрироваться с си, но связка с nashorn+java найдет больше сторонников, чем связка nodejs+cи. Хотя бы из-за того, что java удобнее в разработке, чем си. Не говоря уже об инфраструктуре java vs си.

Только у ноды с потреблением ресурсов и со скоростью выполнения проблем нет.

Как раз есть. Память жрет больше, чем java или на равных. Про перформанс, так вообще смешно сравнивать скриптоту и типизированный код.

foror ★★★★★
()
Ответ на: комментарий от umren

Я смогу манипулировать DOM веб-страницы в браузере через C или C++? По документации webassembly - смогу. Тогда нахрен мне JS, если я смогу манипулировать DOM через С++, а позже через C# или Java?

foror ★★★★★
()
Ответ на: комментарий от foror

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

JS всем этим будет оркестрировать с помощью API работы с этими объектами/компонентами.

Работа с DOM и прочим специфическим в С++ - удачи тебе, инструментария такого не будет, слепому ясно.

umren ★★★★★
() автор топика
Ответ на: комментарий от foror

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

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

От жс останется только модернезированная вирт. машина. У гугла будет некий v8++ (мультитрединг, ручное управление памятью, статическая типизация), у мелкомягких и лисы свои совместимые вирт. машины.

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

Да, сможешь и дальше пилить на жс. Но также у тебя появится возможность работать с DOM через любой ЯП, умеющий выдать байт-код новой вирт. машины. Т.е. тот же Java Applet, только в браузере из коробки без всяких сторонних плагинов и более тесной интеграцией с железом.

Ооох, опять зоопарков поразведут.

Да можно интегрироваться с си, но связка с nashorn+java найдет больше сторонников, чем связка nodejs+cи. Хотя бы из-за того, что java удобнее в разработке, чем си. Не говоря уже об инфраструктуре java vs си.

А если сравнить инфраструктуру java vs js, то js тут имхо уже как-то поинтересней смотрится.

Как раз есть. Память жрет больше, чем java или на равных. Про перформанс, так вообще смешно сравнивать скриптоту и типизированный код.

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

lazy_aleks
()
Ответ на: комментарий от lazy_aleks

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

Где у facebook проекты уровня google docs или хотя бы gmail?

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

А зачем сейчас три движка JS? У firefox, ie и chrome, если не в курсе разные движки. И как-то смогли договориться по текущему ES6. А новые фичи это по сути развитие JS. К тому же asm.js вроде как всех устроил.

foror ★★★★★
()
Ответ на: комментарий от lazy_aleks

Ооох, опять зоопарков поразведут.

Лучше так, чем транспилить в JS. А на уровне байт-кода все либы будут совместимы. Это как сейчас можно из nashorn прозрачно работать с java классами, так и в webassembly дергать классы из c# в java и наоборот.

Так что node.js довольно скоро станет не нужно. Как впрочем и jvm, mono и т.д. Как только запилят все это в webassembly. Думаю года три уйдет на все про все. Если они не слопоуки, надеюсь.

foror ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.