Здравствуйте, anonymous, Вы писали:
A>Так не надо внедрять в страницу, подгружай скрипт отдельно. Зачем говнокодить даже в приложении уровня Hello World?
Ну т.е. нельзя. Насчет говнокодить — можно поспорить, зачем-то ведь даже картинки разрешили прямо в html вставлять.
A>По идее модули должны так же транслироваться в JS, если они на Си. Всякую склейку и прочие пляски с бубном же можно организовать на привычной инфраструктуре языка, хоть на make-файлах.
В смысле должны? А если не на C? Вот у меня скрипт импортирует какую-то библиотеку, что с ней делать, тоже в js перегонять, а заодно и все зависимости? А как подгружать потом, js ведь даже сам этого не умеет? Вот зачем мне такой геморрой?
A>Ну, да. В теории. А что практика такая, так я вижу проблему (проблему ли?) в том, что оно никому не нужно.
Оно никому пер-ректум, через js, не нужно, потому что все равно в него лезть придется.
A>Иначе б взяли и сделали все как надо.
Ну вот похоже, что делают. А там посмотрим, если взлетит, то может хоть говносайтов поубавится.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, Ops, Вы писали:
A>>Так не надо внедрять в страницу, подгружай скрипт отдельно. Зачем говнокодить даже в приложении уровня Hello World? Ops>Ну т.е. нельзя. Насчет говнокодить — можно поспорить, зачем-то ведь даже картинки разрешили прямо в html вставлять.
Можно не значит нужно. Кроме того ради Hello World не стоит тащить другие языки в браузер — это надуманный пример.
A>>По идее модули должны так же транслироваться в JS, если они на Си. Всякую склейку и прочие пляски с бубном же можно организовать на привычной инфраструктуре языка, хоть на make-файлах. Ops>В смысле должны? А если не на C? Вот у меня скрипт импортирует какую-то библиотеку, что с ней делать, тоже в js перегонять, а заодно и все зависимости? А как подгружать потом, js ведь даже сам этого не умеет? Вот зачем мне такой геморрой?
Я имел в виду «если не на Си». И далее если JS не может подгрузить какую-то библиотеку, и твой язык не может, то в чём вообще сравнение?
A>>Ну, да. В теории. А что практика такая, так я вижу проблему (проблему ли?) в том, что оно никому не нужно. Ops>Оно никому пер-ректум, через js, не нужно, потому что все равно в него лезть придется.
На деле это просто постулируется, чтобы и далее болтать на форумах и ничего не делать. Поэтому и нет никаких практических результатов.
A>>Иначе б взяли и сделали все как надо. Ops>Ну вот похоже, что делают. А там посмотрим, если взлетит, то может хоть говносайтов поубавится.
Серьёзно? Говносайты не из-за говноязыков, а из-за говнопрограммистов. И я гарантирую увеличение их количества с наплывом криворуких поклонников других языков.
Здравствуйте, Serginio1, Вы писали:
A>>Ну, да. В теории. А что практика такая, так я вижу проблему (проблему ли?) в том, что оно никому не нужно. Иначе б взяли и сделали все как надо. Но нет, всё ограничивается разговорами о том, какой плохой JS, и как ему покажут когда-нибудь, когда реализуют ту или иную крайне необходимую фичу. S> Ну почему же. Есть TS, Dart, C#/XAML for HTML5
Это не то. Я упоминал уже выше, что есть языки на замену JS, но это новые языки специально разработанные на замену JS. А старые языки, типа Python, никто не спешит использовать в браузере. Их поклонники всё ждут, когда им создадут какие-то расчудесные условия, и тогда-то они всем покажут, а пока можно и потрындеть, как всё плохо с клиентском вебе.
Здравствуйте, Ops, Вы писали:
S>> Рассматривай JS как ассемблер. Возможно в скором времени выпустят спецификацию байт кода с расширенным набором типов, куда и модно будет компилировать другие языки. Ops>Никакой это не ассемблер, идиотская прослойка.
Думаю всё дело в выкачивании денег.
Вместо написания мелкого бинарного модуля Сильверлайта или Флэша, который будет работать во всех(*) браузерах, люди вынуждены извращаться.
Так что утверждение "JS — просто язык с низким порогом вхождения" — есть лукавство, ибо сам по себе он не особо используется.
Связка JS+HTML+CSS — это как извозчики в начале 20-го века — их время ушло, но ретроградное лобби их ещё поддерживает.
Здравствуйте, turbocode, Вы писали:
T>На что то более вменяемое типа C# с хорошей стандартной библиотекой? Сколько можно тянуть этот JS легаси из 90-х годов?
1) Первое, что бросается в глаза, — это то, что сейчас веб-разработчиков больше всего (72,6%). А также то, что 2/3 из них — full stack (63,7%). Так что если вы еще не знаете javascript, советую все-таки посмотреть в его сторону.
2) Это становится еще очевиднее, если взглянуть на топ самых используемых языков:
Здравствуйте, Ops, Вы писали:
I>>Не "пилили", а яростно продлжают пилить, например. новый тулчейн влупили для того, что бы больше оптимизаций можно было реализовать.
Ops>Сейчас модно не оптимизировать, а наоборот, прикрутить сбоку стильно-молодежную либу из-за одной функции, раздув страничку еще на пару мегабайт. Иначе как объяснить 177 запросов 15.39Мб при заходе на гмыло?
Гмыло при таком количестве запросов работает очень шустро. Кроме того, в гмыле целый вагон фич. Не так много, как в Outlook, но вообще мало какой веб интерфейс сравнится с гмылом по качеству исполнения и скорости при тех же фичах.
Я думаю, скоро гмыло переведут на http2 и гмыло станет еще шустрее. Сколько запросов — неинтересно. Ты еще дисковое пространство в килобайтах посчитай. Ого-го, как много выходит!
Здравствуйте, Ikemefula, Вы писали:
I>Гмыло при таком количестве запросов работает очень шустро.
То-то перед показом примитивной странички аж заставку "гружусь" показывает, причем секунды.
I>Кроме того, в гмыле целый вагон фич. Не так много, как в Outlook, но вообще мало какой веб интерфейс сравнится с гмылом по качеству исполнения и скорости при тех же фичах.
Да нахрена мне эти фичи на странице, где они не используются? И почему их не сократить до 30 строчек — JS же может целый Exel в таком объеме реализовать?
I>Я думаю, скоро гмыло переведут на http2 и гмыло станет еще шустрее. Сколько запросов — неинтересно. Ты еще дисковое пространство в килобайтах посчитай. Ого-го, как много выходит!
Я лучше в них трафик посчитаю.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, Ops, Вы писали:
Ops>Здравствуйте, Ikemefula, Вы писали: I>>Гмыло при таком количестве запросов работает очень шустро. Ops>То-то перед показом примитивной странички аж заставку "гружусь" показывает, причем секунды.
У меня даже на хилом инете ничего подобного не видно Ты через диалап сидишь ?
Ops>Да нахрена мне эти фичи на странице, где они не используются?
Это лично ты их не используешь. Предлагаешь гуглу на тебя ориентироваться ?
>И почему их не сократить до 30 строчек — JS же может целый Exel в таком объеме реализовать?
Гмайл мало чем уступает гуглодокам по фичам.
I>>Я думаю, скоро гмыло переведут на http2 и гмыло станет еще шустрее. Сколько запросов — неинтересно. Ты еще дисковое пространство в килобайтах посчитай. Ого-го, как много выходит!
Ops>Я лучше в них трафик посчитаю.
Здравствуйте, Ikemefula, Вы писали:
I>У меня даже на хилом инете ничего подобного не видно Ты через диалап сидишь ?
Просто редко захожу, все кеши протухают.
I>Это лично ты их не используешь. Предлагаешь гуглу на тебя ориентироваться ?
Их никто не использует, в виду недоступности. На странице со списком писем можно очень мало чего сделать. Я бы оценил необходимый для нее код в 50Кб. Но говнокодеры грузят все что можно. Не влезал вглубь, но не удивлюсь, если там даже переводы на все возможные языки сразу подгружаются.
I>Гмайл мало чем уступает гуглодокам по фичам.
И как же там посчитать 2+2?
I>У тебя инет по трафику ?
Если через мобилу — считай по трафику, после лимита скорость до непотребных 64кбит режется.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, Ikemefula, Вы писали:
I>Наоборот. Это в джаве он новичок. Соответственно, будет пытаться ехать на старом опыте. Например, я уже говорил, память он продолжает использовать как сиплюсник — пытается всё руками контролировать, но при этом не знает ничего про неявно создаваемые объекты и тд.
В C++ можно временные структуры и буферы создавать на стеке, вообще не неся никаких расходов на выделение памяти. Это наверное прокатит в качестве примера "руками контролировать память". Что предлагает взамен Java?
Здравствуйте, gandjustas, Вы писали:
G>Это ты пошутил так, да? Java взлетела именно потому что вытеснила C\C++ в банкинге и трейдинге, а в дальнейшем во всем остальном сервер-сайде. Это случилось в районе начала-середины 90-х. До этого Java позиционировалась как язык для чайников и была по факту не нужна вообще никому.
В районе начала 90х Java просто не существовала, а что-то осмысленное на ней сделать стало возможно лишь году к 2000.
Здравствуйте, Hobbes, Вы писали:
H>Здравствуйте, gandjustas, Вы писали:
G>>Это ты пошутил так, да? Java взлетела именно потому что вытеснила C\C++ в банкинге и трейдинге, а в дальнейшем во всем остальном сервер-сайде. Это случилось в районе начала-середины 90-х. До этого Java позиционировалась как язык для чайников и была по факту не нужна вообще никому.
H>В районе начала 90х Java просто не существовала, а что-то осмысленное на ней сделать стало возможно лишь году к 2000.
Я видел java-аплеты в 1998. А на первой работе в 2002 увидел трехзвенку, где сервер на java пилили с 1996.
По сравнению с C\C++ в то время это был мега-крутой язык для сервер-сайда.
Здравствуйте, Hobbes, Вы писали:
I>>Наоборот. Это в джаве он новичок. Соответственно, будет пытаться ехать на старом опыте. Например, я уже говорил, память он продолжает использовать как сиплюсник — пытается всё руками контролировать, но при этом не знает ничего про неявно создаваемые объекты и тд.
H>В C++ можно временные структуры и буферы создавать на стеке, вообще не неся никаких расходов на выделение памяти. Это наверное прокатит в
качестве примера "руками контролировать память". Что предлагает взамен Java?
Потому, например, сиплюсников узнают, что они пытаются сорганизовать такие буферы даже на джаве, не удосужившись понять как она унутре устроена.
С++ девелопер почти всегда считает, что new это дико дорого и начинает, например, оптимизировать. С++ девелопер как правило понимает ГЦ много хуже джава девелопера, и отсюда снова неправильно использует память, например — пытается на ровном месте организовывать пулы объектов.
Далее, в той области, где Джава, БД используются каждый божий день. С++ уже давно оттуда вытеснен. ORM в силу этой причины для С++ девелопера пустое место. Он его понимает как умную склейку строк и код пишет соответствующий.
Есть конечно исключения, но в целом при резком переходе из Java в C++, т.е. "было 100% С++ стало 100% Java" вылезают самые разные проблемы.
Здравствуйте, vdimas, Вы писали:
V>Потому что модель DOM — это тоже устаревшая тупая хрень, ограничивающая всё, что только можно ограничить. DOM был нужен исключительно и только для JS.
Надо только добавить, что модель эквивалентная DOM была фактически паттерном для всяких движков рендеринга и во многих случаях испокон веков являлась стандартом де-факто. В случае с браузерами эта модель была реализована задолго до войн браузеров. Во время этих самых войнах её просто опубликовали и окультурили.
Здравствуйте, Ikemefula, Вы писали:
I>Надо только добавить, что модель эквивалентная DOM была фактически паттерном для всяких движков рендеринга и во многих случаях испокон веков являлась стандартом де-факто.
Речь не об "патеррне", а о реализации. Изначально DOM появился как биндинг на скриптовый язык, вот этот момент и является ограничением. Я не помню, чтобы до этого публиковали некий АПИ исключительно как бинд на скрипт. Да это был бы нонсенс. ))
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, Ikemefula, Вы писали:
I>>Надо только добавить, что модель эквивалентная DOM была фактически паттерном для всяких движков рендеринга и во многих случаях испокон веков являлась стандартом де-факто.
V>Речь не об "патеррне", а о реализации. Изначально DOM появился как биндинг на скриптовый язык, вот этот момент и является ограничением. Я не помню, чтобы до этого публиковали некий АПИ исключительно как бинд на скрипт. Да это был бы нонсенс. ))
Разумеется это не так. DOM появился задолго до скриптинга и никакого отношения к биндингу не имел. Объектная модель внятных рисовалок и разных процессоров именно так и выглядит. А всевозможные 'xxx объектая модеь' это тренд девяностых. На такой модели очень легко реализовывать самые разные сценарии
Здравствуйте, Ikemefula, Вы писали:
V>>Речь не об "патеррне", а о реализации. Изначально DOM появился как биндинг на скриптовый язык, вот этот момент и является ограничением. Я не помню, чтобы до этого публиковали некий АПИ исключительно как бинд на скрипт. Да это был бы нонсенс. )) I>Разумеется это не так.
I>DOM появился задолго до скриптинга и никакого отношения к биндингу не имел. Объектная модель внятных рисовалок и разных процессоров именно так и выглядит.
Тебя опять не туда несет. Критиковался именно DOM HTML-страницы. Обсуждать некий "абстрактный" DOM не имею ни малейшего желания. Рядом я уже озвучивал более подробно свои претензии — без опубликованного ABI этого DOM, он является гирей на ногах, потому что "пренебречь тонкостями" можно только в случае как раз скриптинга. Именно это является главным тормозом развития веб-технологий как таковых.
Здравствуйте, vdimas, Вы писали:
I>>DOM появился задолго до скриптинга и никакого отношения к биндингу не имел. Объектная модель внятных рисовалок и разных процессоров именно так и выглядит.
V>Тебя опять не туда несет. Критиковался именно DOM HTML-страницы. Обсуждать некий "абстрактный" DOM не имею ни малейшего желания.
Мы именно его и обсуждаем.
>Рядом я уже озвучивал более подробно свои претензии — без опубликованного ABI этого DOM, он является гирей на ногах, потому что "пренебречь тонкостями" можно только в случае как раз скриптинга. Именно это является главным тормозом развития веб-технологий как таковых.
Ты утверждал, что он появился из-за JS. На самом деле он появился гораздо раньше и публикация его ради JS было несложной задачей.
Вообще говоря это легко объяснимо — в то время DOM не являлся и не мог являться узким местом, потому что никакой динамики не было. Стили и то были в проекте.