Основной кейс — уход в бизнес-анализ и возвращение в разработку(JavaScript)
Здесь и далее "поколение jQuery" — люди, которые ушли во время расцвета jQuery и потом хотели вернуться в разработку.
А>У вас явные противоречия в рассуждения. Если программист активно имел дело с jQuery, то почему у них будет вызывать вопросы язык JavaScript?
Это наблюдаемая реальность. Язык это минорная проблема. Весь нынешний стек фронтенда состоит из вещей, неизвестных поколению jQuery. Билды, тесты, загрузчики модулей, фремворки, разнообразные библиотеки, новые архитектуры и тд и тд.
Все такие вещи раньше были в наличии в десктопных или мобильных приложениях. В jQuery-мире этого ничего не было нужно. Потому нынешний фронтенд он 'неправильный' с точки зрения поколения jQuery.
А>Т потом Node.js — это для серверной части. Почему это должно вызывать большие трудности для тех, кто знает JavaScript, но не имел дело с
Node.js?
В Node.js только язык такой же, а все остальное принципиально отличное от jQuery в браузере — сборка, хостинг, деплоймент, базы данных, HTTP/REST в полный рост, кучи самых разнообразных фреймворков, библиотек и тд для кеширования, авторизации, аутентификации и тд и тд.
Отдельная проблем — Node.js тотально асинхронный при том что внешне однопоточный. Опыта такого программирования у поколения jQuery нет вообще. Всё что они писали — простые обработчики.
А>А самое главное — вам в голову не приходит простая мысль, что если вы, допустим, пишите на Node.js, а другой еще не имел с ним дело, это совершенно не означает, что вы — хороший программист, а тот, другой, — плохой программист.
Да, это известный кейс — узнать, где хорошее лучше плохого, а где наоборот. Здесь доказывать нужно не мне, а тем интервьюерам, которые повстречаются на собеседонии. У каждой конторы свой подход, своё видение.
Здравствуйте, Ikemefula, Вы писали:
I>Это наблюдаемая реальность. Язык это минорная проблема. Весь нынешний стек фронтенда состоит из вещей, неизвестных поколению jQuery. Билды, тесты, загрузчики модулей, фремворки, разнообразные библиотеки, новые архитектуры и тд и тд.
Да, во фронтенде понаворотили кучу странных вещей, которых и на десктопе не было. Причём сделали это максимально неудобным способом. А вся-то задача — DOM прости господи частично перегенерировать без перезагрузки всей страницы.
Здравствуйте, Ikemefula, Вы писали:
А>>А самое главное — вам в голову не приходит простая мысль, что если вы, допустим, пишите на Node.js, а другой еще не имел с ним дело, это совершенно не означает, что вы — хороший программист, а тот, другой, — плохой программист.
I>Да, это известный кейс — узнать, где хорошее лучше плохого, а где наоборот. Здесь доказывать нужно не мне, а тем интервьюерам, которые повстречаются на собеседонии. У каждой конторы свой подход, своё видение.
Ничего не мешает выучить Node.js(или любую технологию) самостоятельно, и написать какой-нибудь небольшой проект, о котором можно рассказать. Да, часть вакансий отсеится, и тех-лидом не возьмут. Однако работу найти можно, особенно если есть глубокие знания программирования и какой-то серьезный опыт.
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
С>А вся-то задача — DOM прости господи частично перегенерировать без перезагрузки всей страницы.
Angular может это вполне. Там просто делаешь директиву, контроллер, инжектишь зависимости, потом angular.js:14328 ReferenceError: GroupSettingsDialogController1 is not defined at e.$scope.showGroupSettings (groupController.js:68) at fn (eval at compile (angular.js:15156), <anonymous>:4:316) at callback (angular.js:26744) at Scope.$eval (angular.js:17972) at Scope.$apply (angular.js:18072) at TMLButtonElement.<anonymous> (angular.js:26749) at defaultHandlerWrapper (angular.js:3613) at HTMLButtonElement.eventHandler (angular.js:3601) (anonymous) @ angular.js:14328 :(
Я немного покопался в современном JS. У меня примерно такие претензии (я с острова Java).
1. Сложность сборки. Grunt. Очень низкоуровнево, проще шелл-скрипт написать. Одна радость — относительно кроссплатформенно. Gulp — хрен редьки не слаще. Только якобы более производительно. Где там производительность, я не знаю, оно собирает несложный JS-проект больше 30 секунд. За 30 секунд я половину линуксового ядра соберу. А тут какой-то JS. Webpack. Ну вроде как чуть более высокий уровень, но ВСЁ РАВНО ВСЁ НАДО ОПИСЫВАТЬ САМОМУ. Очень хочется простой инструмент. Я буду класть всё в нужные пути и он сделает ВСЁ, что мне надо сам, без какой-то конфигурации. Я использую maven, я вообще ничего не пишу ни о чём, но он сам умеет и компилировать и собирать артефакт и прогонять все тесты и генерировать жавадоки. Так и тут. Дайте мне инструмент, который с нулём конфигурации будет генерировать dev/release сборки, всякие map-ы, hot reload-ы, тесты прогонять, документацию генерировать, линтить, в общем делать всё, что делает любой уважающий себя проект. Кажется к этому придёт, скорее всего будут инструменты уровнем выше этих gulp-ов, но всё равно это всё некрасиво. В общем не хватает в JS своего gradle-а. Существующие решения некачественные.
2. Сложность отладки. Пока не видел ни одного проекта, который можно было бы по-человечески отлаживать в браузере. Или отключаешь все эти сборки и тупо инклудишь файлы в HTML-е, тогда браузер видит всё. Или всё минифицировано и отлаживаться невозможно. Вроде map-файлы для этого нужны, но никогда не видел, чтобы они работали.
3. Очень долгий цикл написал-собрал-проверил. В Java гораздо быстрее. С Hot Reload-ом всё очень плохо. Последний проект, в котором я участвовал, выглядел так: изменил 1 букву, 30 секунд пересобираешь проект, 20 секунд обновляешь страницу в браузере, пару минут натыкиваешь всё, чтобы прийти на ту форму, которую ты делаешь. И не дай бог что-нибудь там закешировалось или ты поспешил — начинай всё сначала. Для Java-программиста выглядит дико. В Java с современными инструментами вроде JRebel я вообще практически никогда не делаю редеплой, все изменения подхватываются за доли секунды. Вроде в react+redux что-то такое есть, но надо, чтобы было стандартно и везде. Иначе это привет из девяностых.
А вообще мне JS-мир нравится. Куча разных языков, куча разных фреймворков. Иногда даже не знаешь, что лучше выбрать. Красота.
Здравствуйте, Слава, Вы писали:
С>Да, во фронтенде понаворотили кучу странных вещей, которых и на десктопе не было. Причём сделали это максимально неудобным способом. А вся-то задача — DOM прости господи частично перегенерировать без перезагрузки всей страницы.
Тут как раз наоборот, постепенно внедряются именно те подходы, что ранее были на десктопе. С той разницей, что все это перепиливается под BOM и DOM.
Здравствуйте, Ikemefula, Вы писали:
I>Основной кейс — уход в бизнес-анализ и возвращение в разработку(JavaScript)
Продолжение беседы с анонимами
>У вас подход дилетантский, который плодит некомпетентность. Как я уже написал, таким способом вы отбираете не хороших программистов, а тех, кто опередил вас, успев прочитать новую аббревиатуру какой-нибудь очередной технологии и выполнив расписанную по шагам программу "Hello World".
Речь прежде всего про собеседования вообще, а не лично мои Я стараюсь время от времени напрашиваться на собеседование. Как правило такие наблюдения подтверждают ровно то, о чем говорят другие — спрашивают в основном по баззвордам, с той целью что бы человек сразу встал к станку и начал точить гайки. Скажем, на вопрос "три кита ооп" лучше давать ответ как в книге
Здравствуйте, vsb, Вы писали:
vsb>1. Сложность сборки. vsb>2. Сложность отладки. vsb>3. Очень долгий цикл написал-собрал-проверил. В Java гораздо быстрее.
У меня прямо противоположные ощущения. По моему типичный джава-бакенд это 'сегодня фикшу — завтра будете пользоваться'. В JS 'комитаю — нажмите кнопку рефреш'
Здравствуйте, lpd, Вы писали:
I>>Да, это известный кейс — узнать, где хорошее лучше плохого, а где наоборот. Здесь доказывать нужно не мне, а тем интервьюерам, которые повстречаются на собеседонии. У каждой конторы свой подход, своё видение.
lpd>Ничего не мешает выучить Node.js(или любую технологию) самостоятельно, и написать какой-нибудь небольшой проект, о котором можно рассказать. Да, часть вакансий отсеится, и тех-лидом не возьмут. Однако работу найти можно, особенно если есть глубокие знания программирования и какой-то серьезный опыт.
Вопрос в том, какая будет эта доля отсеявшихся вакансий и какая останется ЗП. Бывает так, что люди скатываются на уровень джуниора.
vsb>>А вообще мне JS-мир нравится. Куча разных языков, куча разных фреймворков. Иногда даже не знаешь, что лучше выбрать. Красота.
S>Это называется не красота, а идейный разброд, шатание и графомания авторов.
это был не отсыл ли к
Люблю стандарты... Их много — есть из чего выбрать!
Здравствуйте, Ikemefula, Вы писали:
I>Это наблюдаемая реальность. Язык это минорная проблема. Весь нынешний стек фронтенда состоит из вещей, неизвестных поколению jQuery. Билды, тесты, загрузчики модулей, фремворки, разнообразные библиотеки, новые архитектуры и тд и тд.
Всё это говнище будет заменено чем-то новым и так же канет в лету, как и jQuery. Нынешние "скилы" в вебе — просто выброшенное время. Никакого увеличения производительности труда "современный" подход к веб-разработке не даёт, его просто придумали, чтобы инициировать ещё один цикл бесконечных "апгрейдов архитектуры".
Худшее, что может сделать толковый архитектор, это использовать "такие" подходы при серьёзной разработке (ключевое слово — серьёзная), которым от силу пару лет.
Здравствуйте, iHateLogins, Вы писали:
HL>Всё это говнище будет заменено чем-то новым и так же канет в лету, как и jQuery. Нынешние "скилы" в вебе — просто выброшенное время. Никакого увеличения производительности труда "современный" подход к веб-разработке не даёт, его просто придумали, чтобы инициировать ещё один цикл бесконечных "апгрейдов архитектуры".
Фронтенд стремительно взрослеет. С производительностью труда все в порядке — прежде всего сейчас используется более сложный UI. На jQuery такое пилить надо было годами. Новые фремворки позволяют делать это со скоростью поступления требований.
HL>Худшее, что может сделать толковый архитектор, это использовать "такие" подходы при серьёзной разработке (ключевое слово — серьёзная), которым от силу пару лет.
А что значит серьёзная ? Распознавание лиц в режиме реального времени в браузере ?
Здравствуйте, iHateLogins, Вы писали:
HL>Здравствуйте, Ikemefula, Вы писали:
I>>Это наблюдаемая реальность. Язык это минорная проблема. Весь нынешний стек фронтенда состоит из вещей, неизвестных поколению jQuery. Билды, тесты, загрузчики модулей, фремворки, разнообразные библиотеки, новые архитектуры и тд и тд.
HL>Всё это говнище будет заменено чем-то новым и так же канет в лету, как и jQuery.
Ну и куда подевался jQuery, если без него ни один фреймворк не обходится. Разве что в стандарт.
Здравствуйте, vsb, Вы писали:
vsb>3. Очень долгий цикл написал-собрал-проверил. В Java гораздо быстрее. С Hot Reload-ом всё очень плохо. Последний проект, в котором я участвовал, выглядел так: изменил 1 букву, 30 секунд пересобираешь проект, 20 секунд обновляешь страницу в браузере, пару минут натыкиваешь всё, чтобы прийти на ту форму, которую ты делаешь.
какой фронтенд вы делаете на джаве? gwt в этом смысле намного хуже. 300 секунд пересобираешь один permutation, 200 ждешь пока просрётся gwt shell, шаг отладки еще 60 секунд. приложение весит 11М т.е. не очень крупное
Здравствуйте, sr_dev, Вы писали:
vsb>>3. Очень долгий цикл написал-собрал-проверил. В Java гораздо быстрее. С Hot Reload-ом всё очень плохо. Последний проект, в котором я участвовал, выглядел так: изменил 1 букву, 30 секунд пересобираешь проект, 20 секунд обновляешь страницу в браузере, пару минут натыкиваешь всё, чтобы прийти на ту форму, которую ты делаешь.
_>какой фронтенд вы делаете на джаве? gwt в этом смысле намного хуже. 300 секунд пересобираешь один permutation, 200 ждешь пока просрётся gwt shell, шаг отладки еще 60 секунд. приложение весит 11М т.е. не очень крупное
Я про бэкэнд на JVM. С GWT дел не имел, от Java там только язык, насколько я понимаю.
Здравствуйте, Sharov, Вы писали:
HL>>Всё это говнище будет заменено чем-то новым и так же канет в лету, как и jQuery.
S>...без него ни один фреймворк не обходится...
Здравствуйте, vsb, Вы писали:
vsb>Здравствуйте, sr_dev, Вы писали:
vsb>>>3. Очень долгий цикл написал-собрал-проверил. В Java гораздо быстрее. С Hot Reload-ом всё очень плохо. Последний проект, в котором я участвовал, выглядел так: изменил 1 букву, 30 секунд пересобираешь проект, 20 секунд обновляешь страницу в браузере, пару минут натыкиваешь всё, чтобы прийти на ту форму, которую ты делаешь.
_>>какой фронтенд вы делаете на джаве? gwt в этом смысле намного хуже. 300 секунд пересобираешь один permutation, 200 ждешь пока просрётся gwt shell, шаг отладки еще 60 секунд. приложение весит 11М т.е. не очень крупное
vsb>Я про бэкэнд на JVM. С GWT дел не имел, от Java там только язык, насколько я понимаю.
ну не совсем, там отладка из под gwt shell — это обычное jvm приложение. тормозит страшно. hot reload пару раз видел, но с теми скоростями никакой отладкой заниматься вообще невозможно. в релизе да, java конвертится в javascript.
16.01.2017 13:42, sr_dev пишет:
> vsb>3. Очень долгий цикл написал-собрал-проверил. В Java гораздо > быстрее. С Hot Reload-ом всё очень плохо. Последний проект, в котором я > участвовал, выглядел так: изменил 1 букву, 30 секунд пересобираешь > проект, 20 секунд обновляешь страницу в браузере, пару минут натыкиваешь > всё, чтобы прийти на ту форму, которую ты делаешь. > > какой фронтенд вы делаете на джаве? gwt в этом смысле намного хуже. 300 > секунд пересобираешь один permutation, 200 ждешь пока просрётся gwt > shell, шаг отладки еще 60 секунд. приложение весит 11М т.е. не очень крупное
Давайте обменяемся опытом. У нас в яве на сервер-сайде отладка, когда в
ней появляется необходимость, происходит так — поднимается приложение
(внутри сервера приложений или само по себе, если это какой-то
микросервис), цепляемся к jvm стандартным отладчиком или через jrebel
(там возможностей hot reload больше), делаем к нему запросы через
curl/jmeter/browser/etc., смотрим что у нас там внутри, какие переменные
какие значения имеют, правим код, делаем прямо из IDE(A) hot reload,
повторяем запрос, опять смотрим, опять правим и т.д. Всё достаточно
быстро и удобно.
Вот появился у нас развесистый фронтенд, для примера на ангуляре,
собираемый из кучи файлов (т.к. он реально развесистый) через gulp.
Необходимо что-то изменить/проверить. Что делать? gulp build каждый раз
запускать? Долго. Пробовали gulp watch — всё бы ничего, но на ряде машин
под совершенно обычной вендой он выжирает весь ЦПУ. Ну и как уже отмечал
коллега это ещё не всё — если у нас SPA, возможно придётся после F5 в
браузере предварительно потыкать в кучу кнопок чтобы попасть в то место,
которое нам интересно.
Расскажите — как у вас организован процесс разработки больших
фронтендов, как правильно решаются подобные проблемы в мире javascript.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, Sharov, Вы писали:
HL>>>Всё это говнище будет заменено чем-то новым и так же канет в лету, как и jQuery.
S>>...без него ни один фреймворк не обходится...
I>Это заблуждение.
Здравствуйте, hrensgory, Вы писали:
H>16.01.2017 13:42, sr_dev пишет:
H>Давайте обменяемся опытом. У нас в яве на сервер-сайде отладка
С бэкендом всё так, да всё удобно
H>Вот появился у нас развесистый фронтенд, для примера на ангуляре, H>собираемый из кучи файлов (т.к. он реально развесистый) через gulp. H>Необходимо что-то изменить/проверить. Что делать? gulp build каждый раз H>запускать? Долго. Пробовали gulp watch — всё бы ничего, но на ряде машин H>под совершенно обычной вендой он выжирает весь ЦПУ. Ну и как уже отмечал H>коллега это ещё не всё — если у нас SPA, возможно придётся после F5 в H>браузере предварительно потыкать в кучу кнопок чтобы попасть в то место, H>которое нам интересно.
Сейчас у нас именно angular. Лично я делаю gulp build (вотч тормозит). Коллеги юзают gulp watch, может у них получше.
Всё правда, и f5 и куча кнопок. Но после gwt эти проблемы меня как то не достают особо.
Для отладки сборка без минифая. Отладка в браузере чаще всего (или webstorm, но тормозит).
Для разработки webstorm, достойнее для js ничего нет.
16.01.2017 16:15, sr_dev пишет: > Но после gwt эти проблемы меня как то не > достают особо.
Пробовали очень давно GWT, отказались на этапе проб. Даже JSF на тот
момент оказался лучше.
> Для разработки webstorm, достойнее для js ничего нет.
Согласен ) Фронтендщики у нас тоже его используют.
Здравствуйте, Sharov, Вы писали:
HL>>>>Всё это говнище будет заменено чем-то новым и так же канет в лету, как и jQuery.
S>>>...без него ни один фреймворк не обходится...
I>>Это заблуждение.
S>Примеры.
Здравствуйте, hrensgory, Вы писали:
H>Вот появился у нас развесистый фронтенд, для примера на ангуляре, H>собираемый из кучи файлов (т.к. он реально развесистый) через gulp. H>Необходимо что-то изменить/проверить. Что делать? gulp build каждый раз H>запускать? Долго. Пробовали gulp watch — всё бы ничего, но на ряде машин H>под совершенно обычной вендой он выжирает весь ЦПУ. Ну и как уже отмечал H>коллега это ещё не всё — если у нас SPA, возможно придётся после F5 в H>браузере предварительно потыкать в кучу кнопок чтобы попасть в то место, H>которое нам интересно.
А при чем здесь развесистый фремвор, watch и винда ? Хот-релоад на клиенте не даёт особого профита — все равно каждый кейс надо прокликать _руками_. Это особенность любой клиентской разработки. На клиенте конская зависимость от нативного кода. Ну сделал ты фикс, что браузер вдруг DOM перестроит в соответствии с твоим фиксом ? Css перепарсится ? Картинки перерисуются ? Нет, это все надо перекликать руками.
Вообще даже на сервере хот-релоад дает далеко не в 100% кейсах. Когда ты нашел баг, состояние в большинстве случаев уже невалидное. Например была аутентификация с некорректным токеном, который взял и записался в базу, кеш и тд и тд. Как тут хот-релоад поможет ?
16.01.2017 22:12, Ikemefula пишет: > А при чем здесь развесистый фремвор, watch и винда ?
Притом, что между исправлением кода и нажатием F5 в браузере появился
новый этап, иногда достаточно длительный — билд "клиентского приложения"
(gulp build/gulp watch). Ещё очень недавно этого не было.
> Вообще даже на сервере хот-релоад дает далеко не в 100% кейсах. Когда ты > нашел баг, состояние в большинстве случаев уже невалидное. Например была > аутентификация с некорректным токеном, который взял и записался в базу, > кеш и тд и тд. Как тут хот-релоад поможет ?
Хот релоад исправляет код без необходимости перезагрузки приложения, для
того чтобы убедиться что мы всё правильно исправили — конечно же запрос
(или серию запросов) придётся повторить. В простых случаях это делается
прямо через браузер, если повторять надо значительно более одного раза —
мы применяем пакетный файл с последовательными вызовами curl или
запускаем скрипт jmeter. Есть наверняка и другие способы автоматизации.
Здравствуйте, hrensgory, Вы писали:
>> А при чем здесь развесистый фремвор, watch и винда ?
H>Притом, что между исправлением кода и нажатием F5 в браузере появился H>новый этап, иногда достаточно длительный — билд "клиентского приложения" H>(gulp build/gulp watch). Ещё очень недавно этого не было.
Разумеется. И причины не во фремворках, а в усложнении требований к UI. Фремворки — следствие этого усложнения.
H>Хот релоад исправляет код без необходимости перезагрузки приложения, для H>того чтобы убедиться что мы всё правильно исправили — конечно же запрос H>(или серию запросов) придётся повторить. В простых случаях это делается H>прямо через браузер, если повторять надо значительно более одного раза — H>мы применяем пакетный файл с последовательными вызовами curl или H>запускаем скрипт jmeter. Есть наверняка и другие способы автоматизации.
Если непонятно, еще раз — фронтенд хранит состояние в нативной части. Каким образом без перезагрузки приложения обновить это состояние ?
На сервере у тебя состояния по большому счету нет вообще. В браузере ровно наоборот — DOM/BOM и есть твоё состояние.
Каким чудом ты собираешься хот релоадом решать проблему нативных модулей ?
Собственно в браузере есть возможность патчить JS прямо на лету. Жмешь в хроме F12, выбираешь JS файл, патчишь его, сохраняешь, радуешься результату. Это твой любимый хот-релоад. Проблема в том, что в более менее серьезном приложении это не даёт эффекта, нисколько, никакого. На страничках где функционала около нуля, такой патч помогает,но ровно до тех пор, пока ты не завязан на состояние.
Как только изменения затрагивают состояние, упс, надо перегружать приложение. И такое было уже на чистом, ванильном жээсе когда еще ангуляра и реакта даже в планах не было.
17.01.2017 10:54, Ikemefula пишет:
> H>Притом, что между исправлением кода и нажатием F5 в браузере появился > H>новый этап, иногда достаточно длительный — билд "клиентского приложения" > H>(gulp build/gulp watch). Ещё очень недавно этого не было. > > Разумеется. И причины не во фремворках, а в усложнении требований к UI. > Фремворки — следствие этого усложнения.
По-моему такой зоопарк фронтенд фреймворков, который образовался сейчас
(о чем была статья на хабре "Каково оно учить JavaScript в 2016", с
которой и началось обсуждение) и частота смены "лидеров" в этой гонке
обуславливается скорее воплощением описанного ещё давно Дж. Спольски
принципа "огонь и движение" чем "усложнением требований к UI". Вот
оттуда цитатка подходящая:
"Подумайте об истории всевозможных стратегий доступа к данным,
разработанным Microsoft. ODBC, RDO, DAO, ADO, OLEDB, теперь вот ADO.NET
— И все абсолютно новые! Может это было вызвано технологической
необходимостью? Может это результат некомпетентной группы
проектирования, которой необходимо придумывать по-новой доступ к данным
каждый чертов год? (Возможно, это в самом деле так.) Но конечный
результат — всего лишь огонь для прикрытия. Конкуренты не имеют никакого
другого выбора, кроме как тратить своё время, переписывая код под новые
библиотеки и поспевая за лидером — время, которое они не могут
использовать для создания новых возможностей."
> Если непонятно, еще раз — фронтенд хранит состояние в нативной части.
Я "фронтендом" в т.ч. занимаюсь со времен Netscape Navigator 2.0 и
мне-то это всё понятно ) Просто жалко кучи времени, которое тратится
программистами на разработку фронта в сравнении с разработкой бэка.
Здравствуйте, hrensgory, Вы писали:
>> Разумеется. И причины не во фремворках, а в усложнении требований к UI. >> Фремворки — следствие этого усложнения. H>По-моему такой зоопарк фронтенд фреймворков, который образовался сейчас H>(о чем была статья на хабре "Каково оно учить JavaScript в 2016", с H>которой и началось обсуждение) и частота смены "лидеров" в этой гонке H>обуславливается скорее воплощением описанного ещё давно Дж. Спольски H>принципа "огонь и движение" чем "усложнением требований к UI". Вот H>оттуда цитатка подходящая:
Ага, эдакий заговор. Все решили усложнять ради усложнения а юзеры радостно ведутся.
H>каждый чертов год? (Возможно, это в самом деле так.) Но конечный H>результат — всего лишь огонь для прикрытия. Конкуренты не имеют никакого H>другого выбора, кроме как тратить своё время, переписывая код под новые H>библиотеки и поспевая за лидером — время, которое они не могут H>использовать для создания новых возможностей."
Так и есть — заговор. Юзеру профита якобы нет, но он яростно отказыватся от работающих приложений и покупает лютое говно на новых технологиях
H>Я "фронтендом" в т.ч. занимаюсь со времен Netscape Navigator 2.0 и H>мне-то это всё понятно ) Просто жалко кучи времени, которое тратится H>программистами на разработку фронта в сравнении с разработкой бэка.
Оно и видно, что постишь конспироложество в исполнении Джоэля Спольски.
Здравствуйте, vsb, Вы писали:
vsb>Я немного покопался в современном JS. У меня примерно такие претензии (я с острова Java). vsb>1. Сложность сборки. Grunt. Очень низкоуровнево, проще шелл-скрипт написать. Одна радость — относительно кроссплатформенно. Gulp — хрен редьки не слаще. Только якобы более производительно. Где там производительность, я не знаю, оно собирает несложный JS-проект больше 30 секунд. vsb>3. Очень долгий цикл написал-собрал-проверил. В Java гораздо быстрее. С Hot Reload-ом всё очень плохо. Последний проект, в котором я участвовал, выглядел так: изменил 1 букву, 30 секунд пересобираешь проект
Попробуй webpack. В режиме watch он первый раз долго собирает-собирает, но последующие сборки при изменениях кода происходят очень быстро.
17.01.2017 16:04, Ikemefula пишет: > H>По-моему такой зоопарк фронтенд фреймворков, который образовался сейчас > H>(о чем была статья на хабре "Каково оно учить JavaScript в 2016", с > H>которой и началось обсуждение) и частота смены "лидеров" в этой гонке > H>обуславливается скорее воплощением описанного ещё давно Дж. Спольски > H>принципа "огонь и движение" чем "усложнением требований к UI". Вот > H>оттуда цитатка подходящая: > > Ага, эдакий заговор. Все решили усложнять ради усложнения а юзеры > радостно ведутся.
... > Так и есть — заговор. Юзеру профита якобы нет, но он яростно отказыватся > от работающих приложений и покупает лютое говно на новых технологиях
Юзера никто не спрашивает. Мне как "юзеру" непонятно — зачем сделали
несовместимый с первым Angular2 (а сейчас уже лепят Angular4), если
единственным серьезным недостатком первого был повсеместный two-way
binding, от которого стало возможно избавляться уже с версии, ЕМНИП,
1.3? Понятно же что сейчас куча библиотек, написанная под первый,
останется без поддержки и по мере выхода всё новых и новых версий
браузеров будет глючить всё больше и больше, что приведет к тому, что
приложения перестанут быть "работающими" и будут заменены по вашему
меткому замечанию "лютым говном на новых технологиях".
Ещё, кстати, совершенно непонятно почему бы не обеспечить, хотя бы в
Хроме и ИЕ (остальные быстро бы подтянулись) нативную поддержку
какого-нибудь более нормального чем JavaScript языка (TypeScript вполне
бы подошёл)?
> P.S. "ODBC, RDO, DAO, ADO, OLEDB, теперь вот ADO.NET" — все эти > баззворды решают конкретные проблемы. Вот хороший ликбез:
99% процентов ПО не использует всерьёз никаких других датасорсов кроме
тех, к которым можно написать JDBC(ODBC) драйвер.
Здравствуйте, hrensgory, Вы писали:
>> Так и есть — заговор. Юзеру профита якобы нет, но он яростно отказыватся >> от работающих приложений и покупает лютое говно на новых технологиях
H>Юзера никто не спрашивает. Мне как "юзеру" непонятно — зачем сделали H>несовместимый с первым Angular2 (а сейчас уже лепят Angular4),
Ты реально считаешь, что юзер в курсе, на чем написан его любимый фейсбук ?
H>единственным серьезным недостатком первого был повсеместный two-way H>binding, от которого стало возможно избавляться уже с версии, ЕМНИП, H>1.3?
Вообще то первый ангуляр был крив буквально во всем. Слишком много текста и телодвижений для любой вещи.
Разработчики этого первого ангуляра так и не смогли внятно объяснить девелоперам все концепции.
Первый ангуляр это ООП поверх ООП на джаваскрипте. Изобретение модулей, классов, зависимостей и тд и тд.
Практически все разрабы, которые сталкиваются с Angular2, испытывают облегчение после первого. Люди без опыта фронтенда, джависты, дотнетчики, воспринимают Ангуляр2 как обычные ООП.
Кроме того, Ангуляр2 тупо быстрее, по скромной оценке — на порядок. Там где в первом надо оптимизировать дайджесты, во втором хватит тупого решения "в лоб", и работает быстрее чем первый со всеми оптимизациями.
H>останется без поддержки и по мере выхода всё новых и новых версий H>браузеров будет глючить всё больше и больше, что приведет к тому, что H>приложения перестанут быть "работающими" и будут заменены по вашему H>меткому замечанию "лютым говном на новых технологиях".
Ужос, если у юзера будет глючить фейсбук, он наверняка пойдет туда, где ничего не глючит. Правильно ?
Или ты думаешь фейсбук юзерам взятку даёт, шоб те к конкурентам не ходили ?
H>Ещё, кстати, совершенно непонятно почему бы не обеспечить, хотя бы в H>Хроме и ИЕ (остальные быстро бы подтянулись) нативную поддержку H>какого-нибудь более нормального чем JavaScript языка (TypeScript вполне H>бы подошёл)?
Уже давно идет к этому, только опенсорс он слишком медленный. Перед этим была компиляция. Сейчас проходим этап транспайлеров. Потиху вводится поддержка webassembly и тд и тд и тд.
H>99% процентов ПО не использует всерьёз никаких других датасорсов кроме H>тех, к которым можно написать JDBC(ODBC) драйвер.
Во первых, ты проспал документы. Эти вещи не имеют sql-интерфейса а изобрели их еще в семидесятых.
Во вторых, кроме odbc есть еще и технология OLE(OLE2, COM, ActiveX), и здесь собственно получаем внятный интерфейс поверх ODBC безо всякого паскудства.
Собственно, на чистом odbc никто всерьез ничего не писал, как ты говоришь "в 99% случаяв"
Здравствуйте, Ikemefula, Вы писали:
I>Кроме того, Ангуляр2 тупо быстрее, по скромной оценке — на порядок. Там где в первом надо оптимизировать дайджесты, во втором хватит тупого решения "в лоб", и работает быстрее чем первый со всеми оптимизациями.
А что лучше использовать angular2 или react? А то когда мне довелось писать простенький web ui для своего сервиса, я выбрал angular + kendoui. Это было года 2 назад. Что сейчас считается хорошим фреймворком? Чтобы mvc и вот это вот все.
Здравствуйте, Sharov, Вы писали:
S>А что лучше использовать angular2 или react? А то когда мне довелось писать простенький web ui для своего сервиса, я выбрал angular + kendoui. Это было года 2 назад. Что сейчас считается хорошим фреймворком? Чтобы mvc и вот это вот все.
Для старта лучше использовать более знакомый тебе инструмент. Если тащишься от функциональщины и прочих вещей, бери реакт с прибамбасами.
Если ты понимаешь и умеешь классическое ООП, статическую типизацию и тд, то тебе стоит взять Ангуляр2. Люди без опыта во фронтенде с ООП-бекграундом легко поднимают Ангуляр2. Вот первый ангуляр или реакт уже так легко не даются, судя по наблюдениям.
Здравствуйте, selkwind, Вы писали:
I>>Ага, эдакий заговор. Все решили усложнять ради усложнения а юзеры радостно ведутся.
S>Никакой не заговор, а просто графомания, типичная для лиц с шизоидными наклонностями, коих среди ИТшников валом.
В обсуждаемом примере баззворды появлялись как раз для решения новых проблем.
17.01.2017 18:36, Ikemefula пишет:
> H>Юзера никто не спрашивает. Мне как "юзеру" непонятно — зачем сделали > H>несовместимый с первым Angular2 (а сейчас уже лепят Angular4), > > Ты реально считаешь, что юзер в курсе, на чем написан его любимый фейсбук ?
Под "юзером" здесь имелся в виду "юзер" фреймворка, т.е.
фронтенд-разработчик.
> Вообще то первый ангуляр был крив буквально во всем. Слишком много > текста и телодвижений для любой вещи. > Разработчики этого первого ангуляра так и не смогли внятно объяснить > девелоперам все концепции. > Первый ангуляр это ООП поверх ООП на джаваскрипте. Изобретение модулей, > классов, зависимостей и тд и тд.
Ну не знаю, как-то слишком это уж пессимистично звучит, наблюдениями не
подтверждается. Наши фронтендщики его достаточно быстро освоили и
клепают на нем всякий энтерпрайз уверенно. Хотя писанины могло бы быть и
поменьше, это да.
Теперь вот второй осваиваем. Только сомневаемся — может надо четвёртый
сразу ) ?
> H>Ещё, кстати, совершенно непонятно почему бы не обеспечить, хотя бы в > H>Хроме и ИЕ (остальные быстро бы подтянулись) нативную поддержку > H>какого-нибудь более нормального чем JavaScript языка (TypeScript вполне > H>бы подошёл)? > > Уже давно идет к этому, только опенсорс он слишком медленный. Перед этим > была компиляция. Сейчас проходим этап транспайлеров. Потиху вводится > поддержка webassembly и тд и тд и тд.
Да вот куда-то оно не туда идёт по-моему. Применение транспайлеров
приводит к тому, что в браузере исполняется javascript, связь которого с
исходниками неочевидна. То есть по сути это такой GWT light edition —
пишем на одном языке, в браузере другой.
А что до webassembly — так по-моему более идиотской идеи ещё поискать.
Давайте выкосим из браузеров отработанные десятилетиями VM явы, флэша и
сильверлайта, а взамен напишем свою! А остальные пусть под неё пишут
биндинги своих языков. Прекрасная идея, что тут скажешь.
> H>99% процентов ПО не использует всерьёз никаких других датасорсов кроме > H>тех, к которым можно написать JDBC(ODBC) драйвер. > > Собственно, на чистом odbc никто всерьез ничего не писал, как ты > говоришь "в 99% случаяв"
Возможно, хотя это звучит странно. Я практически незнаком с миром винды,
а в той же яве все "надстройки" вроде JPA и подобных фреймворков
работают в конечном счёте именно через JDBC драйвера. И "чистый JDBC"
используется в больших приложениях нередко (хелловорды не рассматриваем
— там конечно и JPA за глаза хватит).
Ну да, взрослеет. И при этом продолжает в случае чего срать направо и налево в лог нечто типа "undefined is not a function" или там еще какой "MISMATCHED ANONYMOUS DEFINE() MODULES" безо всякой возможности пройтись дебаггером по обфусцированному коду с кучей promises & callbacks.
Здравствуйте, hrensgory, Вы писали:
>> Ты реально считаешь, что юзер в курсе, на чем написан его любимый фейсбук ?
H>Под "юзером" здесь имелся в виду "юзер" фреймворка, т.е. H>фронтенд-разработчик.
>> Первый ангуляр это ООП поверх ООП на джаваскрипте. Изобретение модулей, >> классов, зависимостей и тд и тд.
H>Ну не знаю, как-то слишком это уж пессимистично звучит, наблюдениями не H>подтверждается. Наши фронтендщики его достаточно быстро освоили и H>клепают на нем всякий энтерпрайз уверенно. Хотя писанины могло бы быть и H>поменьше, это да.
Фронтенды — быстро. А вот люди без опыта фронтенда осваивают с большим трудом.
С старом фронтенде изобретение ООП, модулей, классов, импорта-экспорта депенденсов встречалось повсеместно.
Но это в основном графомания и пережитки старого JS — поддержка языковых фич на уровне библиотеки.
package App
import dependency1
import dependency2
import dependency3
class Service {
public Service(dependency1 d1,dependency2 d2,dependency3 d3) {
...
}
}
Ничего не напоминает ? До кучи в Ангуляре1 смешали зависимости дизайн-тайм с зависимостями ран-тайм. Пока в голове разраба не сложится этот пазл, в ангуляре1 от него толку не будет.
ES6 и ТайпСкрипт прекращают эти глупости. Получается почти как в Jave, с той разницей, что язык чуть-чуть другой, ибо рантайм JS таки отличается от JVM.
H>Теперь вот второй осваиваем. Только сомневаемся — может надо четвёртый H>сразу ) ?
Не надо сомневаться — сейчас просто Ангуляр. Будут иногда ломающие изменения, но это лучше, чем один большой прыжок с 1 на 2.
>> Уже давно идет к этому, только опенсорс он слишком медленный. Перед этим >> была компиляция. Сейчас проходим этап транспайлеров. Потиху вводится >> поддержка webassembly и тд и тд и тд.
H>Да вот куда-то оно не туда идёт по-моему. Применение транспайлеров H>приводит к тому, что в браузере исполняется javascript, связь которого с H>исходниками неочевидна. То есть по сути это такой GWT light edition — H>пишем на одном языке, в браузере другой.
Причина в разнице рантайма JS и JVM. Так вот сложилось, что Java сама по себе тащит в языке зависимостей больше, чем поддерживается рантаймом JS.
Кроме того, обилие обычного JS позволяет легко проткнуть сразу все абстракции разом.
В браузере будет внятно работать только тот язык, который хорошо ложится на рантайм JS. Это, как ни странно, JS и С++ Со вторым, правда, проблем не избежать — сейчас, похоже, его уверенно знают только реликты из 80-90х.
H>А что до webassembly — так по-моему более идиотской идеи ещё поискать. H>Давайте выкосим из браузеров отработанные десятилетиями VM явы, флэша и H>сильверлайта, а взамен напишем свою! А остальные пусть под неё пишут H>биндинги своих языков. Прекрасная идея, что тут скажешь.
Идея правильная, но запоздалая. Изначально было такое понимание, что браузер идеален (IE6) и его только плагинами нужно обложить.
Собтсвенно не ясно, зачем пилить UI на джаве, если браузер сам обладает наилучшими возможностями в этом вопросе.
vm, флеш, сервелат зашли в тупик. Сервелат, Джава, Флеш это песочницы, не позволяют внятную интеграцию с другими частями сайта, имеют проблемы с перформансом, функциональностью, инсталяцией и тд и тд. Зачем юзеру пять дополнительных рантаймов для браузера, которые создают проблемы, если омжно обойтись родным браузером ?
Насколько я понимаю, нынешний тренд в браузерах — превращение движка в полноценную платформу, фактически как OS.
Здравствуйте, selkwind, Вы писали:
I>>Фронтенд стремительно взрослеет.
S>Ну да, взрослеет. И при этом продолжает в случае чего срать направо и налево в лог нечто типа "undefined is not a function" или там еще какой "MISMATCHED ANONYMOUS DEFINE() MODULES" безо всякой возможности пройтись дебаггером по обфусцированному коду с кучей promises & callbacks.
Это пример реликтового подхода к модулям на фронтенде.
Здравствуйте, Ikemefula, Вы писали:
I>В браузере будет внятно работать только тот язык, который хорошо ложится на рантайм JS. Это, как ни странно, JS и С++
Шо?! Почему на "рантайм js" не ложится java, но ложится c++?
Здравствуйте, hrensgory, Вы писали:
H>Да вот куда-то оно не туда идёт по-моему. Применение транспайлеров H>приводит к тому, что в браузере исполняется javascript, связь которого с H>исходниками неочевидна.
197...ые годы. Опытный специалист сетует:
— Применение компиляторов приводит к тому, что на процессоре исполняется код, связь которого с исходниками на алголе неочевидна.
Здравствуйте, sr_dev, Вы писали:
_>Здравствуйте, Ikemefula, Вы писали:
I>>В браузере будет внятно работать только тот язык, который хорошо ложится на рантайм JS. Это, как ни странно, JS и С++
_>Шо?! Почему на "рантайм js" не ложится java, но ложится c++?
Потому, что С++ умеет компилировать свои шаблоны в zero-overhead, а джава так не умеет.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, sr_dev, Вы писали:
_>>Здравствуйте, Ikemefula, Вы писали:
I>>>В браузере будет внятно работать только тот язык, который хорошо ложится на рантайм JS. Это, как ни странно, JS и С++
_>>Шо?! Почему на "рантайм js" не ложится java, но ложится c++?
I>Потому, что С++ умеет компилировать свои шаблоны в zero-overhead, а джава так не умеет.
Ну и что? Джава в ГВт совершенно нормально транслируется в жс со всеми женериками и прочим. Все нормально ложится на рантайм и нормально работает в браузере
Здравствуйте, sr_dev, Вы писали:
I>>Потому, что С++ умеет компилировать свои шаблоны в zero-overhead, а джава так не умеет.
_>Ну и что? Джава в ГВт совершенно нормально транслируется в жс со всеми женериками и прочим. Все нормально ложится на рантайм и нормально работает в браузере
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, sr_dev, Вы писали:
I>>>Потому, что С++ умеет компилировать свои шаблоны в zero-overhead, а джава так не умеет.
_>>Ну и что? Джава в ГВт совершенно нормально транслируется в жс со всеми женериками и прочим. Все нормально ложится на рантайм и нормально работает в браузере
I>Врёшь. Стандартная либа джавы не скомпилируется ни во что. То есть, джава в браузере работает в виде ЭМУЛЯЦИИ рантайма. C++ никакой эмуляции не требует. I>http://www.gwtproject.org/doc/latest/DevGuideCodingBasicsCompatibility.html I>http://www.gwtproject.org/doc/latest/RefJreEmulation.html
По моему ты запутался.
Вопрос был: почему c++ в браузере ок, а java не ок?
Твой ответ: из за дженериков
Я говорю что с дженериками всё ок, ты теперь отвечаешь "джава требует эмуляции рантайма, а с++ не требует". С дженериками то ок теперь?
Какого "рантайма"? JVM? классов JRE? В каком месте C++ то будет лучше?
Здравствуйте, sr_dev, Вы писали:
I>>Врёшь. Стандартная либа джавы не скомпилируется ни во что. То есть, джава в браузере работает в виде ЭМУЛЯЦИИ рантайма. C++ никакой эмуляции не требует. I>>http://www.gwtproject.org/doc/latest/DevGuideCodingBasicsCompatibility.html I>>http://www.gwtproject.org/doc/latest/RefJreEmulation.html
_>По моему ты запутался. _>Вопрос был: почему c++ в браузере ок, а java не ок? _>Я говорю что с дженериками всё ок, ты теперь отвечаешь "джава требует эмуляции рантайма, а с++ не требует". С дженериками то ок теперь?
Не надо передергивать. Я сказал про zero-overhead. В джаве надо пилить слой эмуляции. Про дженерики сказал не я, а ты. Вот эта разница — эмуляция рантайма, — и есть ответ на твой
вопрос.
_>Какого "рантайма"? JVM? классов JRE? В каком месте C++ то будет лучше?
С++ не требует никакой эмуляции. Что именно эмулируется, какие ограничения, издержки, проблемы — всё есть по ссылкам.
_>Короче тема на данный момент не раскрыта.
I>Не надо передергивать. Я сказал про zero-overhead. В джаве надо пилить слой эмуляции. Про дженерики сказал не я, а ты.
Ну как
Потому, что С++ умеет компилировать свои шаблоны в zero-overhead, а джава так не умеет.
Это ты сказал или я?
Шаблоны (темплейты) C++ это дженерики в джаве. Или ты не про темлпейты? Кстати насчет zero overhead ты не совсем прав, по скорости может и да (и то не уверен, что jvm на лету не сможет оптимизировать), но по размеру исполняемого файла нет.
Теперь насчет твоих ссылок по поводу "эмуляции рантайма"
GWT includes a library that emulates a subset of the Java runtime library. The list below shows the set of JRE packages, types and methods that GWT can translate automatically. Note that in some cases, only a subset of methods is supported for a given type
Написано что GWT часть джрешных типов поддерживает не полностью. На практике кстати это большую проблему у меня не представляло.
Ты думаешь всё что есть в c++ (в стандарт кстати входят и такие вещи как std::thread) в браузере будет поддерживаться?
Здравствуйте, sr_dev, Вы писали:
_>Ну как
_>Потому, что С++ умеет компилировать свои шаблоны в zero-overhead, а джава так не умеет.
_>Это ты сказал или я?
Здесь нет ничего про дженерики.
_>Шаблоны (темплейты) C++ это дженерики в джаве.
Разумеется, это разные механизмы.
>Или ты не про темлпейты? Кстати насчет zero overhead ты не совсем прав, по скорости может и да (и то не уверен, что jvm на лету не сможет оптимизировать), но по размеру исполняемого файла нет.
Речь в том числе про перформанс и возможности. Стандартная библиотека — на шаблонах. То есть, zero-overhead, получаем её же в JS без пенальтей. В джаве тебе надо _портировать_ руками весь код. Как минимум — всю библиотеку.
_>GWT includes a library that emulates a subset of the Java runtime library. The list below shows the set of JRE packages, types and methods that GWT can translate automatically. Note that in some cases, only a subset of methods is supported for a given type _>Написано что GWT часть джрешных типов поддерживает не полностью. На практике кстати это большую проблему у меня не представляло. _>Ты думаешь всё что есть в c++ (в стандарт кстати входят и такие вещи как std::thread) в браузере будет поддерживаться?
На практике есть проект Ecmascripten, ты можешь в браузере поиграть в игры написаные двадцать лет назад на C++. Что бы повторить такой перформанс на джаве, тебе надо вместо эмуляции реализовать полноценную JVM поверх JS.
Ну как, сможешь показать аналогичное решение, навроде Ecmascripten, но на джаве ?
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, sr_dev, Вы писали:
_>>Ну как
_>>Потому, что С++ умеет компилировать свои шаблоны в zero-overhead, а джава так не умеет.
_>>Это ты сказал или я?
I>Здесь нет ничего про дженерики.
А про что тут есть, какие шаблоны джава не умеет компилить?
I>Речь в том числе про перформанс и возможности. Стандартная библиотека — на шаблонах. То есть, zero-overhead, получаем её же в JS без пенальтей. В джаве тебе надо _портировать_ руками весь код. Как минимум — всю библиотеку.
не надо
I>На практике есть проект Ecmascripten, ты можешь в браузере поиграть в игры написаные двадцать лет назад на C++. Что бы повторить такой перформанс на джаве, тебе надо вместо эмуляции реализовать полноценную JVM поверх JS.
Ну а тут потребовалось реализовать llvm поверх js. Одинаково. Короче дело не в языке
18.01.2017 14:51, Ikemefula пишет:
> Сравни > appModule.service(ServiceFunction, [dependency1,dependency2,dependency3]) > с этим > class Service { > public Service(dependency1 d1,dependency2 d2,dependency3 d3) { > ... > } > }
Ну, мне как джависту конечно больше нравится второй вариант, только вот
с TypeScript отладка получается немного костыльная — только через source
maps и только Хром: https://www.jetbrains.com/help/webstorm/2016.3/debugging-typescript.html
> Собтсвенно не ясно, зачем пилить UI на джаве, если браузер сам обладает > наилучшими возможностями в этом вопросе.
Апплеты уже давно применялись не для "пиления UI", а для обеспечения
дополнительных возможностей браузеру — криптография, взаимодействие с
локальной аппаратурой и т.п. Да и на webassembly я так понимаю
планируется не элементы DOM с места на место переставлять )
> vm, флеш, сервелат зашли в тупик. Сервелат, Джава, Флеш это песочницы, > не позволяют внятную интеграцию с другими частями сайта,
Неясно что за такая "внятная интеграция" с другими частями "сайта".
Связка java <-> js в тех проектах, где применяли апплеты, работала
исправно (это, конечно, были не "сайты", а "веб-приложения").
> имеют проблемы > с перформансом, функциональностью, инсталяцией и тд и тд.
С перфомансом и функциональностью у всех трёх никаких существенных
проблем не встречалось, проблемы с инсталляцией обратно пропорциональны
распространенности плагина, у флэша я не помню никаких проблем с
инсталляцией — он был везде и везде работал.
> Зачем юзеру > пять дополнительных рантаймов для браузера, которые создают проблемы, > если омжно обойтись родным браузером ?
Да, в этом смысле, конечно, должно стать более удобно.
> Насколько я понимаю, нынешний тренд в браузерах — превращение движка в > полноценную платформу, фактически как OS.
По-моему эту тему уже давно пилят, если не забросили. На память приходит
словосочетание "Chrome OS".
18.01.2017 18:38, "Слава" пишет:
> H>Да вот куда-то оно не туда идёт по-моему. Применение транспайлеров > H>приводит к тому, что в браузере исполняется javascript, связь которого с > H>исходниками неочевидна. > > 197...ые годы. Опытный специалист сетует: > > — Применение компиляторов приводит к тому, что на процессоре исполняется > код, связь которого с исходниками на алголе неочевидна.
Транспайлер (в отличие от компилятора) "переводит" между языками
примерно одного уровня.
Здравствуйте, sr_dev, Вы писали:
I>>Здесь нет ничего про дженерики. _>А про что тут есть, какие шаблоны джава не умеет компилить?
Шаблоны != дженерики. В С++ шаблоны, например, тьюринг полные. И на этой полноте основаны библиотеки. Джереники джавы обладают полнотой по тьюрингу ?
Далее, ты можешь на джавовских дженериках запилить __итератор__, который развернется сам собой в честный цикл for ?
Джава так не умеет.
В С++ ты можешь сделать поддержку джаваскриптовых типов и работать с ними как с обычными. Это обойдется в 0 затрат рантайма. Тот самый zero overhead.
Java:
Heavy use of long operations will have a performance impact due to the underlying emulation
I>>Речь в том числе про перформанс и возможности. Стандартная библиотека — на шаблонах. То есть, zero-overhead, получаем её же в JS без пенальтей. В джаве тебе надо _портировать_ руками весь код. Как минимум — всю библиотеку. _>не надо
Окей. Покажи как путем простой перекомпиляции можно джавовскую прогу со внятным GUI запустить в браузере. Спасибо !
I>>На практике есть проект Ecmascripten, ты можешь в браузере поиграть в игры написаные двадцать лет назад на C++. Что бы повторить такой перформанс на джаве, тебе надо вместо эмуляции реализовать полноценную JVM поверх JS.
_>Ну а тут потребовалось реализовать llvm поверх js. Одинаково. Короче дело не в языке
Под этим страшным словосочетанием скрывается всего лишь компилятор в js. В джаве компилятор тебе ничем не поможет — надо пилить слой эмуляции.
Здравствуйте, hrensgory, Вы писали:
>> Собтсвенно не ясно, зачем пилить UI на джаве, если браузер сам обладает >> наилучшими возможностями в этом вопросе. H>Апплеты уже давно применялись не для "пиления UI", а для обеспечения H>дополнительных возможностей браузеру — криптография, взаимодействие с H>локальной аппаратурой и т.п. Да и на webassembly я так понимаю H>планируется не элементы DOM с места на место переставлять )
Сейчас взаимодействие с аппаратурой делается немного иначе. А для всего остального апплеты не нужны.
>> vm, флеш, сервелат зашли в тупик. Сервелат, Джава, Флеш это песочницы, >> не позволяют внятную интеграцию с другими частями сайта, H>Неясно что за такая "внятная интеграция" с другими частями "сайта". H>Связка java <-> js в тех проектах, где применяли апплеты, работала H>исправно (это, конечно, были не "сайты", а "веб-приложения").
И каким чудом твоя джава умела css, что бы ничем не отличаться от остального html ?
>> с перформансом, функциональностью, инсталяцией и тд и тд. H>С перфомансом и функциональностью у всех трёх никаких существенных H>проблем не встречалось, проблемы с инсталляцией обратно пропорциональны H>распространенности плагина, у флэша я не помню никаких проблем с H>инсталляцией — он был везде и везде работал.
Инсталяиця это вечный геморрой, что с флешем, что с джавой. Крик и плач юзеров, которым админы пообрезали всё подряд. Как правило таким оставалось только посочувствовать.
Функциональность это примерно так "вот эти кнопки пусть работают вот там". Кнопки на флеше, "там" — сильверлайт или апплеты.
Вот с подобными хотелками на джаваскрипте проблем никогда не возникает.
20.01.2017 20:14, Ikemefula пишет:
> H>Апплеты уже давно применялись не для "пиления UI", а для обеспечения > H>дополнительных возможностей браузеру — криптография, взаимодействие с > H>локальной аппаратурой и т.п. Да и на webassembly я так понимаю > H>планируется не элементы DOM с места на место переставлять ) > > Сейчас взаимодействие с аппаратурой делается немного иначе. А для всего > остального апплеты не нужны.
Как именно иначе? Из того что я видел — люди пишут нативный, требующий
инсталляции на клиентской машине (WinXX 32/64, Mac & Linux zoo welcomes
u!), сервера для общения с аппаратурой по http и плагин под каждый
поддерживаемый браузер. Чрезвычайно эффектно и очень элегантно )
> H>Неясно что за такая "внятная интеграция" с другими частями "сайта". > H>Связка java <-> js в тех проектах, где применяли апплеты, работала > H>исправно (это, конечно, были не "сайты", а "веб-приложения"). > > И каким чудом твоя джава умела css, что бы ничем не отличаться от > остального html ?
Зачем ей это? UI занимался JS.
> Инсталяиця это вечный геморрой, что с флешем, что с джавой. Крик и плач > юзеров, которым админы пообрезали всё подряд. Как правило таким > оставалось только посочувствовать.
Там где резали флэш — будут резать и webassembly.
Здравствуйте, hrensgory, Вы писали:
>> Сейчас взаимодействие с аппаратурой делается немного иначе. А для всего >> остального апплеты не нужны. H>Как именно иначе? Из того что я видел — люди пишут нативный, требующий H>инсталляции на клиентской машине (WinXX 32/64, Mac & Linux zoo welcomes H>u!), сервера для общения с аппаратурой по http и плагин под каждый H>поддерживаемый браузер. Чрезвычайно эффектно и очень элегантно )
Ты небось драйвера на джаве пишешь и всё такое, да ?
>> И каким чудом твоя джава умела css, что бы ничем не отличаться от >> остального html ? H>Зачем ей это? UI занимался JS.
Кул. UI отпадает. Значит остаётся два кейса — логика, которую тоже умеет JS, и железо, которое Джава умеет далеко не всегда, в силу ряда ограничений.
Так зачем тебе джава в бровзере ?
>> оставалось только посочувствовать. H>Там где резали флэш — будут резать и webassembly.
Нисколько. webassembly это фактически тот же JS, только в профиль. И возможности ровно те же. webassembly добавляет только перформанс и поддержку разных _языков_.
23.01.2017 15:50, Ikemefula пишет:
> Ты небось драйвера на джаве пишешь и всё такое, да ?
Причём тут драйвера? Как именно пообщаться с железом или любым сторонним
не-HTTP сервисом (TCP, UDP) из JS?
>>> И каким чудом твоя джава умела css, что бы ничем не отличаться от >>> остального html ? > H>Зачем ей это? UI занимался JS. > > Кул. UI отпадает. Значит остаётся два кейса — логика, которую тоже умеет > JS,
Дай пример реализации ГОСТ-овской криптографии на JS. Можно
несертифицированную реализацию — лишь бы работало следующее: открыли
файл, посчитали хэш, проверили отсоединенную ЭП. Для экономии времени
скажу сразу что подписанный апплет может открыть файл на компьютере
пользователя и прочесть его содержимое, если пользователь дал ему такие
разрешения.
> и железо, которое Джава умеет далеко не всегда, в силу ряда ограничений.
Да, не всегда. Но шансы часто есть.
>>> оставалось только посочувствовать. > H>Там где резали флэш — будут резать и webassembly. > > Нисколько. webassembly это фактически тот же JS, только в профиль. И > возможности ровно те же. webassembly добавляет только перформанс и > поддержку разных _языков_.
Поживём — увидим. Я думаю, что те кто резали флэш — порежут и
вебассембли. Тем более что наверняка в его VM поначалу будут дыры, а к
ним будут писаться эксплойты.
Здравствуйте, hrensgory, Вы писали:
>> Ты небось драйвера на джаве пишешь и всё такое, да ? H>Причём тут драйвера? Как именно пообщаться с железом или любым сторонним H>не-HTTP сервисом (TCP, UDP) из JS?
Никак, что вобщем то очевидно. И это одна из причин отказа от джавы.
H>Дай пример реализации ГОСТ-овской криптографии на JS. Можно H>несертифицированную реализацию — лишь бы работало следующее: открыли H>файл, посчитали хэш, проверили отсоединенную ЭП. Для экономии времени H>скажу сразу что подписанный апплет может открыть файл на компьютере H>пользователя и прочесть его содержимое, если пользователь дал ему такие H>разрешения.
Такая хрень вообще должна работать вне браузера. Кликаешь ссылку, открывается специализированое приложение.
Расскажи, как ты решишь следующую проблему — что сайтописатели как то забывают внятно обновлять аплеты, либы и тд и тд.
Если этим занимается отдельная софтина, то она контролируется через систему апдейтов. А вот с твоими аплетами как быть ?
>> и железо, которое Джава умеет далеко не всегда, в силу ряда ограничений. H>Да, не всегда. Но шансы часто есть.
Неинтересно. Надо 100% и что бы работало внятно, а не в зависимости от хотения сайтопейсателей.
>> Нисколько. webassembly это фактически тот же JS, только в профиль. И >> возможности ровно те же. webassembly добавляет только перформанс и >> поддержку разных _языков_. H>Поживём — увидим. Я думаю, что те кто резали флэш — порежут и H>вебассембли. Тем более что наверняка в его VM поначалу будут дыры, а к H>ним будут писаться эксплойты.
Это уже давно известно — ровно те же эксплойты, что есть сейчас для JS VM. Wasm это она же и есть.
24.01.2017 13:00, Ikemefula пишет: > Такая хрень вообще должна работать вне браузера. Кликаешь ссылку, > открывается специализированое приложение.
Кому должна?
> Расскажи, как ты решишь следующую проблему — что сайтописатели как то > забывают внятно обновлять аплеты, либы и тд и тд. > Если этим занимается отдельная софтина, то она контролируется через > систему апдейтов. А вот с твоими аплетами как быть ?
Уважаемый, меня, честно говоря, несколько утомляет этот разговор.
Давайте вы сначала ознакомитесь с тем что это вообще были за такие
апплеты (в прошедшем времени, т.к. NPAPI через которую подключался java
plugin стремительно выпиливается), как их встраивали в "сайты" (а их
нормальные люди не встраивали в "сайты", а только в веб-приложения,
исполняемые зачастую в корпоративном интранете) а потом, если будут
конкретные вопросы — зададите их. А то получается разговор ни о чем,
"должна работать вне браузера", "100% и не зависеть", "сайтопейсатели"
хрень какая-то.
Если вам просто из полемического задора хочется оставить последнее слово
за собой — напишите что-нибудь (неважно что) в ответ на этот пост.
Здравствуйте, hrensgory, Вы писали:
>> Такая хрень вообще должна работать вне браузера. Кликаешь ссылку, >> открывается специализированое приложение. H>Кому должна?
Тренд нынче такой. Не хавать, что дают разрабы, а принуждать их поддерживать определенный стандарт. Не готова поддержка — твою классную фичу юзер не сможет юзать.
>> Расскажи, как ты решишь следующую проблему — что сайтописатели как то >> забывают внятно обновлять аплеты, либы и тд и тд. >> Если этим занимается отдельная софтина, то она контролируется через >> систему апдейтов. А вот с твоими аплетами как быть ? H>Уважаемый, меня, честно говоря, несколько утомляет этот разговор. H>Давайте вы сначала ознакомитесь с тем что это вообще были за такие H>апплеты
Ты на вопрос попробуй ответить. Кто гарантирует, что ты в аплете заимплементируешь все необходимые гарантии, актуальные на нынешний день ?
И что делать юзеру, если он хочет юзать прогу, но хочет гарантии посильнее ? Кто ему специальный аплет напишет ?
Вот JS это позволяет решить. А у тебя только общие слова, как всё классно в джаве.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, sr_dev, Вы писали:
I>>>Здесь нет ничего про дженерики. _>>А про что тут есть, какие шаблоны джава не умеет компилить?
I>Шаблоны != дженерики. В С++ шаблоны, например, тьюринг полные. И на этой полноте основаны библиотеки. Джереники джавы обладают полнотой по тьюрингу ? I>Далее, ты можешь на джавовских дженериках запилить __итератор__, который развернется сам собой в честный цикл for ? I>Джава так не умеет.
Осталось выяснить, как это относится к переносимости джавы в js.
_>>Ну а тут потребовалось реализовать llvm поверх js. Одинаково. Короче дело не в языке
I>Под этим страшным словосочетанием скрывается всего лишь компилятор в js. В джаве компилятор тебе ничем не поможет — надо пилить слой эмуляции.
GWT без "слоя эмуляции" и "оверхеда" справляется с конвертацией дженериков и прочего в js.
UPDATE
Прочитай из какого ты это выдрал контекста и объясни как себя в аналогичной ситуации должен вести int64_t в c++. Спасибо)
Heavy use of long operations will have a performance impact due to the underlying emulation
Здравствуйте, sr_dev, Вы писали:
I>>Шаблоны != дженерики. В С++ шаблоны, например, тьюринг полные. И на этой полноте основаны библиотеки. Джереники джавы обладают полнотой по тьюрингу ? I>>Далее, ты можешь на джавовских дженериках запилить __итератор__, который развернется сам собой в честный цикл for ? I>>Джава так не умеет.
_>Осталось выяснить, как это относится к переносимости джавы в js.
Непосредственно — код на С++ работает или лучше, чем чистый JS, или так же. С джавой ровно наоборот — или так же, или хуже. И все это есть следствие той самой эмуляции и оверхеду.
_>GWT без "слоя эмуляции" и "оверхеда" справляется с конвертацией дженериков и прочего в js.
Это значит, что ты сможешь скомпилировать и запустить свой код на джаве и только. Но это у тебя на ровном месте будет серьезный оверхед, что съест и перформанс, и память. Это особенность Джавы. В С++ этого нет — zero-everhead темплейтов.
То есть, ты не сможешь запустить старую софтину — её придется всерьёз переделывать. В С++ ровно наоборот, и проект Ecmascripten именно это и демонстрирует.
_>Прочитай из какого ты это выдрал контекста и объясни как себя в аналогичной ситуации должен вести int64_t в c++. Спасибо)
В С++ такой тип работает идентично обычному нативному С++. _Идентично_.
Кроме того, буде необходимость каких то оптимизаций, в С++ я могу объявить типы, идентичные джаваскриптовым, определить нужные операторы, и тд и тд, и это будет работать не хуже встроеных типов.
то есть, в с++ это будет примерно так
auto n = a + b;
И здесь имеем тот самый zero-overhead, т.е. трансляцию в js-типы, как будто пишешь на JS. Подложили либу, перекомпилировали, дело в шляпе.
Аналогичный фокус мы получаем с темплейтами.
В джаве для того же фокуса придется писать так
JsNumber n = JsNumber.sum(a, b);
И в чуть более сложных кейсах появляется осязаемый оверхед, поскольку компилер джавы заточен под Джит целиком и полностью.
Итого — придется не просто перекомпилировать, а переписывать все связаные с этим участки кода, а возможно и архитектуру менять.
I>В С++ такой тип работает идентично обычному нативному С++. _Идентично_.
Повторяю вопрос.
Прочитай из какого ты это выдрал контекста и объясни как себя в аналогичной ситуации должен вести int64_t в c++.
Выдрано вот это
Heavy use of long operations will have a performance impact due to the underlying emulation
Вот отсюда
long: JavaScript has no 64-bit integral type, so long needs special consideration. Prior to GWT 1.5, the long type was was simply mapped to the integral range of a 64-bit JavaScript floating-point value, giving long variables an actual range less than the full 64 bits. As of GWT 1.5, long primitives are emulated as a pair of 32-bit integers, and work reliably over the entire 64-bit range. Overflow is emulated to match the expected behavior. There are a couple of caveats. Heavy use of long operations will have a performance impact due to the underlying emulation. Additionally, long primitives cannot be used in JSNI code because they are not a native JavaScript numeric type.
На пальцах.
Использования джававского лонга (64 бит) неэффективно ибо в js нет подходящего типа. И требуется его эмулировать либо флоатом либо как еще. В каком месте тут c++ лучше (в котором есть int64_t)?
Здравствуйте, sr_dev, Вы писали:
_>Повторяю вопрос.
_>На пальцах. _>Использования джававского лонга (64 бит) неэффективно ибо в js нет подходящего типа. И требуется его эмулировать либо флоатом либо как еще. В каком месте тут c++ лучше (в котором есть int64_t)?
Смотри в той части, где zero-overhead. Хочешь эмуляцию — она есть, и лучше, чем в джаве. Хочешь без эмуляции — и это возможно, и снова лучше, чем в джаве.
I>Кул. UI отпадает. Значит остаётся два кейса — логика, которую тоже умеет JS, и железо, которое Джава умеет далеко не всегда, в силу ряда ограничений.
Нет такого железа. Если для устройства уже написан драйвер — то общаться с драйвером можно из любого языка, хоть из Lua. Самое обычное — байтики из/в ком-порт писать.
Здравствуйте, Слава, Вы писали:
I>>Кул. UI отпадает. Значит остаётся два кейса — логика, которую тоже умеет JS, и железо, которое Джава умеет далеко не всегда, в силу ряда ограничений.
С>Нет такого железа. Если для устройства уже написан драйвер — то общаться с драйвером можно из любого языка, хоть из Lua. Самое обычное — байтики из/в ком-порт писать.
Ты сам себе и ответил. Теперь дело за малым — кто гарантирует, что ты в джавовском коде заимплементил самые свежие и актуальные гарантии ?
Если все дело в аплете, то юзеры будут годами ждать, пока ты соизволишь аплет подфиксить. А если дело в сторонней софтине, то она обновляется независимо от твоих хотелок, а девелоперы, то есть ты, обязаны будут писать такой код, как эта софтина требует.
То есть, останется только общатся с этой софтиной. А это, как ты сам сказал, можно из любого языка. Итак — зачем здесь Джава ?
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, sr_dev, Вы писали:
_>>Повторяю вопрос.
_>>На пальцах. _>>Использования джававского лонга (64 бит) неэффективно ибо в js нет подходящего типа. И требуется его эмулировать либо флоатом либо как еще. В каком месте тут c++ лучше (в котором есть int64_t)?
I>Смотри в той части, где zero-overhead. Хочешь эмуляцию — она есть, и лучше, чем в джаве. Хочешь без эмуляции — и это возможно, и снова лучше, чем в джаве.
Задан предельно конкретный вопрос про int64_t, ответ как обычно zero overhed. Слив зачитан?
Здравствуйте, Ikemefula, Вы писали:
I>Ты на вопрос попробуй ответить. Кто гарантирует, что ты в аплете заимплементируешь все необходимые гарантии, актуальные на нынешний день ? I>И что делать юзеру, если он хочет юзать прогу, но хочет гарантии посильнее ? Кто ему специальный аплет напишет ? I>Вот JS это позволяет решить. А у тебя только общие слова, как всё классно в джаве.
Какие "гарантии"-то? Вот для явы и для апплетов есть security manager и policy-файлы. А теперь расскажи, как для некоего "веб-приложения" на JS, то есть кучки html, css, jpg и js файлов со всего интернета? не подписанных даже — как этому мутному приложению программно дать права на чтение-запись некоей конкретной папки? А как проконтролировать то, что приложение не изменилось? Может быть злой хакер функцию paddingLeft подменил (или что там за недавно драма была среди js'ников...)
Всё то, что было в яве и во многих других средах, всё что казалось излишне сложным — оно не на пустом месте возникло. Когда вася пишет скрипт на JS, чтобы у него на сайте обезьянка за курсором бегала — сложностей не надо. А потом они возникают всё равно, потом что сложные задачи решаются сложными методами. И то, что в других местах уже решено и описано в документации, в JS будет делаться десятью разными способами — по числу браузеров с учётом мобильных.
Заходит вася на сайт корпоративного Hangouts, в конференцию, а его не слышат, потому что надписи "это приложение требует доступа к микрофону" он не видит, потому что он тупой вася. Как групповой политикой для google chrome дать некоему веб-приложению доступ к микрофону, чтобы не вася кликал сам, а для него всё было настроено?
Здравствуйте, Ikemefula, Вы писали:
С>>Нет такого железа. Если для устройства уже написан драйвер — то общаться с драйвером можно из любого языка, хоть из Lua. Самое обычное — байтики из/в ком-порт писать.
I>Ты сам себе и ответил. Теперь дело за малым — кто гарантирует, что ты в джавовском коде заимплементил самые свежие и актуальные гарантии ? I>Если все дело в аплете, то юзеры будут годами ждать, пока ты соизволишь аплет подфиксить.
То же и с кодом на сайте.
I>А если дело в сторонней софтине, то она обновляется независимо от твоих хотелок, а девелоперы, то есть ты, обязаны будут писать такой код, как эта софтина требует.
"Софтина" ничего не требует. Взять например обычный фискальный регистратор — его подключили, появилось устройство на ком-порте. Поставили прогу, идущую с ним — появилась возможность создавать объект COM и через него работать с регистратором.
I>То есть, останется только общатся с этой софтиной. А это, как ты сам сказал, можно из любого языка. Итак — зачем здесь Джава ?
При том, что создание COM-объектов в яве уже есть. А вот в JS с этим могут быть проблемы. Как ты раздашь права на доступ? Работает например человек в ворде, и у него открыт сайт. Если у JS будет прямой доступ к COM, то можно просто подключиться к работающему ворду и копировать из него всё, что открывается в нём.
Здравствуйте, sr_dev, Вы писали:
I>>Смотри в той части, где zero-overhead. Хочешь эмуляцию — она есть, и лучше, чем в джаве. Хочешь без эмуляции — и это возможно, и снова лучше, чем в джаве.
_>Задан предельно конкретный вопрос про int64_t, ответ как обычно zero overhed. Слив зачитан?
Здравствуйте, Слава, Вы писали:
I>>И что делать юзеру, если он хочет юзать прогу, но хочет гарантии посильнее ? Кто ему специальный аплет напишет ? I>>Вот JS это позволяет решить. А у тебя только общие слова, как всё классно в джаве.
С>Какие "гарантии"-то? Вот для явы и для апплетов есть security manager и policy-файлы. А теперь расскажи, как для некоего "веб-приложения" на JS, то есть кучки html, css, jpg и js файлов со всего интернета? не подписанных даже — как этому мутному приложению программно дать права на чтение-запись некоей конкретной папки? А как проконтролировать то, что приложение не изменилось? Может быть злой хакер функцию paddingLeft подменил (или что там за недавно драма была среди js'ников...)
Снова 'читатель'. По клику на ссылку в браузере система открывает подписаное независимое приложение, которое просто не будет работать с корявым сайтом. Вот с этим приложением ты и заканчиваешь операцию. Это приложение апдейтится независимо от твоей хотелки.
С>Заходит вася на сайт корпоративного Hangouts, в конференцию, а его не слышат, потому что надписи "это приложение требует доступа к микрофону" он не видит, потому что он тупой вася. Как групповой политикой для google chrome дать некоему веб-приложению доступ к микрофону, чтобы не вася кликал сам, а для него всё было настроено?
Уже давно придумали — клик мыши ведет на независимое приложение, которое умеет все что надо. Очнись, уже 2017й год начался.
Здравствуйте, Ikemefula, Вы писали:
I>Здравствуйте, Слава, Вы писали:
I>Снова 'читатель'. По клику на ссылку в браузере система открывает подписаное независимое приложение, которое просто не будет работать с корявым сайтом. Вот с этим приложением ты и заканчиваешь операцию. Это приложение апдейтится независимо от твоей хотелки.
Покажи мне пример такого независимого приложения. Задача со звёздочкой — чтобы в приложении была карта, гугловая ли , яндексовая или своя — неважно.
С>>Заходит вася на сайт корпоративного Hangouts, в конференцию, а его не слышат, потому что надписи "это приложение требует доступа к микрофону" он не видит, потому что он тупой вася. Как групповой политикой для google chrome дать некоему веб-приложению доступ к микрофону, чтобы не вася кликал сам, а для него всё было настроено?
I>Уже давно придумали — клик мыши ведет на независимое приложение, которое умеет все что надо. Очнись, уже 2017й год начался.
На чём оно написано? Внутри чего работает, чьими правами пользуется? Покажи пример.
Здравствуйте, Слава, Вы писали:
I>>Ты сам себе и ответил. Теперь дело за малым — кто гарантирует, что ты в джавовском коде заимплементил самые свежие и актуальные гарантии ? I>>Если все дело в аплете, то юзеры будут годами ждать, пока ты соизволишь аплет подфиксить. С>То же и с кодом на сайте.
Я говорю про независимое приложение, а тебе мерещится код на сайте
С>"Софтина" ничего не требует. Взять например обычный фискальный регистратор — его подключили, появилось устройство на ком-порте. Поставили прогу, идущую с ним — появилась возможность создавать объект COM и через него работать с регистратором.
Вот эта часть должна быть не COM объектом, а прежде всего независимым приложением, которое обеспечит все необходимые гарантии. И не надо никакого кода ни в браузере, ни в апплете.
I>>То есть, останется только общатся с этой софтиной. А это, как ты сам сказал, можно из любого языка. Итак — зачем здесь Джава ?
С>При том, что создание COM-объектов в яве уже есть. А вот в JS с этим могут быть проблемы.
Всё что надо в браузере — по клику на ссылке открывать стороннее независимое приложение. Это даже без COM реализуется.Ты путаешь винду и браузеры вообще. В винде джава нужна всего лишь как костыль для связи через COM-объект. Это давно не нужно.
С>>"Софтина" ничего не требует. Взять например обычный фискальный регистратор — его подключили, появилось устройство на ком-порте. Поставили прогу, идущую с ним — появилась возможность создавать объект COM и через него работать с регистратором.
I>Вот эта часть должна быть не COM объектом, а прежде всего независимым приложением, которое обеспечит все необходимые гарантии. И не надо никакого кода ни в браузере, ни в апплете.
А эти свои пожелания ты в спортлото АТОЛ напиши, может и откликнутся
I>Всё что надо в браузере — по клику на ссылке открывать стороннее независимое приложение. Это даже без COM реализуется.Ты путаешь винду и браузеры вообще. В винде джава нужна всего лишь как костыль для связи через COM-объект. Это давно не нужно.
Здравствуйте, Слава, Вы писали:
I>>Снова 'читатель'. По клику на ссылку в браузере система открывает подписаное независимое приложение, которое просто не будет работать с корявым сайтом. Вот с этим приложением ты и заканчиваешь операцию. Это приложение апдейтится независимо от твоей хотелки.
С>Покажи мне пример такого независимого приложения. Задача со звёздочкой — чтобы в приложении была карта, гугловая ли , яндексовая или своя — неважно.
Господи, открой pinterst, reddit, skype и тд. Ты банкинг на мобиле юзал когда нибудь ?
I>>Уже давно придумали — клик мыши ведет на независимое приложение, которое умеет все что надо. Очнись, уже 2017й год начался.
С>На чём оно написано? Внутри чего работает, чьими правами пользуется? Покажи пример.
На чем хошь, это независимое приложение, их пишут и на С++, и на джаве, и на JS, сюрприз ! Работает внутри операционной системы. Пользуется правами которые ему дали при регистрации.
Есть, например, банкинг — по нажатию кнопки 'оплатить' открывается приложение банка, которое делает все что надо, с подписями и сертификатами. Тоже мне, рокет саенс нашел
Здравствуйте, Ikemefula, Вы писали:
С>>Покажи мне пример такого независимого приложения. Задача со звёздочкой — чтобы в приложении была карта, гугловая ли , яндексовая или своя — неважно.
I>Господи, открой pinterst, reddit, skype и тд. Ты банкинг на мобиле юзал когда нибудь?
Давай не про мобилу, это отдельная тема.
I>>>Уже давно придумали — клик мыши ведет на независимое приложение, которое умеет все что надо. Очнись, уже 2017й год начался.
А причём тут JS и замена апплетов?
С>>На чём оно написано? Внутри чего работает, чьими правами пользуется? Покажи пример.
I> На чем хошь, это независимое приложение, их пишут и на С++, и на джаве, и на JS, сюрприз ! Работает внутри операционной системы. Пользуется правами которые ему дали при регистрации.
Здравствуйте, Слава, Вы писали:
I>>Вот эта часть должна быть не COM объектом, а прежде всего независимым приложением, которое обеспечит все необходимые гарантии. И не надо никакого кода ни в браузере, ни в апплете.
С>А эти свои пожелания ты в спортлото АТОЛ напиши, может и откликнутся
Здравствуйте, Ikemefula, Вы писали:
I>>>Вот эта часть должна быть не COM объектом, а прежде всего независимым приложением, которое обеспечит все необходимые гарантии. И не надо никакого кода ни в браузере, ни в апплете.
С>>А эти свои пожелания ты в спортлото АТОЛ напиши, может и откликнутся
I>Это новость только для тебя.
Здравствуйте, Слава, Вы писали:
I>>Господи, открой pinterst, reddit, skype и тд. Ты банкинг на мобиле юзал когда нибудь? С>Давай не про мобилу, это отдельная тема.
Ты вероятно не заметил, но Винда уже давно встала на этот путь. Мы выясняем, что произошло, на секундочку. Джавы в браузере больше нет. Ха-ха.
Аналогичный кстати фокус умеет скайп для бизнеса — кликнул, запустилось новое приложение. Мы в своей софтине реализовали аналогичный фокус. Хочешь секретный документ посмотреть — кликай где хочешь, но будешь смотреть только у нас и никуда твои секреты не утекут.
I>>>>Уже давно придумали — клик мыши ведет на независимое приложение, которое умеет все что надо. Очнись, уже 2017й год начался. С>А причём тут JS и замена апплетов?
Я как раз ничего не говорю про замену аплетов. Я говорю о том, как решаются те проблемы, которые ранее решались джавой.
С>>>На чём оно написано? Внутри чего работает, чьими правами пользуется? Покажи пример.
I>> На чем хошь, это независимое приложение, их пишут и на С++, и на джаве, и на JS, сюрприз ! Работает внутри операционной системы. Пользуется правами которые ему дали при регистрации.
С>А причём тут JS и замена апплетов?
Вот бы узнать, почему тебе мерещится код в браузере ? Я как раз говорю о решении, которое не требует никакого кода в браузере.
Здравствуйте, Слава, Вы писали:
I>>>>Вот эта часть должна быть не COM объектом, а прежде всего независимым приложением, которое обеспечит все необходимые гарантии. И не надо никакого кода ни в браузере, ни в апплете.
С>>>А эти свои пожелания ты в спортлото АТОЛ напиши, может и откликнутся
I>>Это новость только для тебя.
С>??? Ты вообще читаешь то, на что отвечаешь?
Именно. Я пишу про независимое прилоежние, а тебе мерещится замена аплетов. Я пишу, что в браузере надо только кликать ссылки, а тебе мерещится джаваскриптовый код
Здравствуйте, Ikemefula, Вы писали:
С>>??? Ты вообще читаешь то, на что отвечаешь?
I>Именно. Я пишу про независимое прилоежние, а тебе мерещится замена аплетов. Я пишу, что в браузере надо только кликать ссылки, а тебе мерещится джаваскриптовый код
Ну так независимое приложение тоже не сможет работать с указанным мной выше оборудованием иначе, чем указал я. Потому что поставщик другого не предоставляет.
Здравствуйте, Ikemefula, Вы писали:
I>Я как раз ничего не говорю про замену аплетов. Я говорю о том, как решаются те проблемы, которые ранее решались джавой. I>>> На чем хошь, это независимое приложение, их пишут и на С++, и на джаве, и на JS, сюрприз ! Работает внутри операционной системы. Пользуется правами которые ему дали при регистрации. I>Вот бы узнать, почему тебе мерещится код в браузере ? Я как раз говорю о решении, которое не требует никакого кода в браузере.
Таки я понял. Юзер кликает на ссылку, ему загружается классический .exeшник, юзер его запускает, оно работает. Так?
Здравствуйте, Слава, Вы писали:
С>>>??? Ты вообще читаешь то, на что отвечаешь? I>>Именно. Я пишу про независимое прилоежние, а тебе мерещится замена аплетов. Я пишу, что в браузере надо только кликать ссылки, а тебе мерещится джаваскриптовый код С>Ну так независимое приложение тоже не сможет работать с указанным мной выше оборудованием иначе, чем указал я. Потому что поставщик другого не предоставляет.
Это частный случай. Во первых, принципиально оборудование может быть разным. Во вторых, оборудования может и не быть. Например платежка через банкинг. Кликнул в интернет магазине, открылось приложение __твоего__ банка, где ты проводишь оплату.
Сравни — кликнул в интернет магазине и открылся аплет который выбрали разрабы интернет магазина и который ты не можешь даже сменить, какой бы дырявой он ни был.
Здравствуйте, Ikemefula, Вы писали:
I>Это частный случай. Во первых, принципиально оборудование может быть разным. Во вторых, оборудования может и не быть. Например платежка через банкинг. Кликнул в интернет магазине, открылось приложение __твоего__ банка, где ты проводишь оплату.
Нет. Открылась форма банка-эквайрера того магазина, или какого-нибудь платежного шлюза. А оттуда тебя может быть перекинет на форму твоего банка, для подтверждения операции. И всё это — приложения на JS, по сути сайты работающие внутри браузера с присущими им ограничениями.
В другой ветке ты пишешь о других приложениях, кликнул на ссылку, загрузилось нечто бинарное — опа, ну ни один банк так не делает.
I>Сравни — кликнул в интернет магазине и открылся аплет который выбрали разрабы интернет магазина и который ты не можешь даже сменить, какой бы дырявой он ни был.
I>Скажи честно, для тебя это что, рокет саенс ?
Я сюда не рокет сайенсом пришёл мериться. Только вот я не понимаю, в чём новизна того, о чём ты говоришь.
Здравствуйте, Слава, Вы писали:
I>>Это частный случай. Во первых, принципиально оборудование может быть разным. Во вторых, оборудования может и не быть. Например платежка через банкинг. Кликнул в интернет магазине, открылось приложение __твоего__ банка, где ты проводишь оплату.
С>Нет. Открылась форма банка-эквайрера того магазина, или какого-нибудь платежного шлюза. А оттуда тебя может быть перекинет на форму твоего банка, для подтверждения операции. И всё это — приложения на JS, по сути сайты работающие внутри браузера с присущими им ограничениями.
Ты все еще аплетами мыслишь. Вот мне надо свою роспись поставить. Я это делаю безо всякой джавы и не в браузере и даже без джаваскрипта. Прикинь ?
С>В другой ветке ты пишешь о других приложениях, кликнул на ссылку, загрузилось нечто бинарное — опа, ну ни один банк так не делает.
I>>Сравни — кликнул в интернет магазине и открылся аплет который выбрали разрабы интернет магазина и который ты не можешь даже сменить, какой бы дырявой он ни был. I>>Скажи честно, для тебя это что, рокет саенс ? С>Я сюда не рокет сайенсом пришёл мериться. Только вот я не понимаю, в чём новизна того, о чём ты говоришь.
Новизна в том, что критичный к секурити функционал контролируется независимо от скилов разработчиков интернет-магазина.
I>Ты все еще аплетами мыслишь. Вот мне надо свою роспись поставить. Я это делаю безо всякой джавы и не в браузере и даже без джаваскрипта. Прикинь ?
Пошёл вон со своими представлениями о чужом мышлении. И поясни, что у тебя там в чём открывается. Технически. Без высказываний о чужих мыслях.
С>>Я сюда не рокет сайенсом пришёл мериться. Только вот я не понимаю, в чём новизна того, о чём ты говоришь.
I>Новизна в том, что критичный к секурити функционал контролируется независимо от скилов разработчиков интернет-магазина.
Здравствуйте, Слава, Вы писали:
I>>Ты все еще аплетами мыслишь. Вот мне надо свою роспись поставить. Я это делаю безо всякой джавы и не в браузере и даже без джаваскрипта. Прикинь ?
С>Пошёл вон со своими представлениями о чужом мышлении. И поясни, что у тебя там в чём открывается. Технически. Без высказываний о чужих мыслях.
Технически — браузер форвардит операционной системе 'sberbankbilling://xxx.yyy.zzz/transaction_id=1111-2222-3333-4444' и та сама запускает ассоциированое приложение.
Идетично тому, как это в мобиле. В системе на это повешен биллинг твоего банка, в котором ты заканчиваешь транзакцию, ставишь роспись и тд.
Например, itunes работает аналогично — ссылка в браузере ведет в itunes. В ём покупаешь все что надо, жмешь 'назад' и возвращаешься туда, где был.
I>>Новизна в том, что критичный к секурити функционал контролируется независимо от скилов разработчиков интернет-магазина. С>Это не ново
Это гораздо новее аплетов. Потому они и не нужны больше.
Здравствуйте, Слава, Вы писали:
I>>>> На чем хошь, это независимое приложение, их пишут и на С++, и на джаве, и на JS, сюрприз ! Работает внутри операционной системы. Пользуется правами которые ему дали при регистрации. I>>Вот бы узнать, почему тебе мерещится код в браузере ? Я как раз говорю о решении, которое не требует никакого кода в браузере.
С>Таки я понял. Юзер кликает на ссылку, ему загружается классический .exeшник, юзер его запускает, оно работает. Так?
Юзер ничего сам не запускает.
Кликнул в интернет магазине, открылось приложение __твоего__ банка, где ты проводишь оплату.
Сравни — кликнул в интернет магазине и открылся аплет который выбрали разрабы интернет магазина и который ты не можешь даже сменить, какой бы дырявой он ни был.
Начало — http://rsdn.org/forum/job/6656364.flat
