Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 52
Отличная статья
интересно, хоть и не совсем конкретно. я планирую сегодня или в понедельник добить статью про оптимизацию виджета EditableGrid из EXT JS. хочу в начале добавить ссылку на этот топик :). вот только пока не знаю, в какой блог постать :( наверное, будет в "Ревизия кода"
Статья хорошая. Но вот этот перл автору я простить не могу...
>Апплеты, сервлеты и даже такая страшная вещь, как Enterprise Java Beans, на >самом деле, имеют не так много фактических отличий от виджетов.
EJB ~= JS . Браво !
>Апплеты, сервлеты и даже такая страшная вещь, как Enterprise Java Beans, на >самом деле, имеют не так много фактических отличий от виджетов.
EJB ~= JS . Браво !
эмм, это почти цитата. Стоит посмотреть это место в первоисходнике. Вообще-то автор статьи сравнивает серверное окружение с клиентским, проводит параллель между разработками на JavaScript и Java
меня тоже покоробило, но, если задуматься, некоторая правда тут есть. есть ведь GWT, а значит, серверная часть может быть интегрированна с клиентской частью.
Статья расплывчатая, ничего особо конкретного, указание на prototype ничем не подтверждается кроме личного отношения автора к создателям prototype. Даются какие-то общие сведения.
Есть и другие перлы типа
> (миллиарды часов машинного времени, истраченного на исполнение JavaScript; миллионы расстроенных блогеров; сотни тысяч долларов упущенной прибыли)
- очень бы хотелось услышать доказательства такой легко брошенной фразы. Начиная с общей постановки, ведь без Javascript было бы потрачено еще больше времени, денег, еще больше миллиардов часов времени и еще больше расстроено блоггеров. И до конкретных фактов - почему, например, блоггеры растроены, если на самом деле наоборот.
Посмотрите критическим взглядом - все в материале очень поверхностно и спорно.
Есть и другие перлы типа
> (миллиарды часов машинного времени, истраченного на исполнение JavaScript; миллионы расстроенных блогеров; сотни тысяч долларов упущенной прибыли)
- очень бы хотелось услышать доказательства такой легко брошенной фразы. Начиная с общей постановки, ведь без Javascript было бы потрачено еще больше времени, денег, еще больше миллиардов часов времени и еще больше расстроено блоггеров. И до конкретных фактов - почему, например, блоггеры растроены, если на самом деле наоборот.
Посмотрите критическим взглядом - все в материале очень поверхностно и спорно.
В оригинале ничего такого нет. Рановато взялся автор за перевод таких серьезных статей.
это мой личный комментарий. В данном случае имелось в виду машинное время пользователей, которое так неоптимизированно расходует клиентский JavaScript, это уменьшает пользовательское удобство от конечного сайта и трафик в блогах
— броузеры → браузеры;
— JavaScript виджеты → JavaScript-виджеты (аналогично JavaScript скрипт → JavaScript-скрипт, веб странице → веб-странице, и т. д.);
— Working draft я бы перевёл как «черновая версия».
— JavaScript виджеты → JavaScript-виджеты (аналогично JavaScript скрипт → JavaScript-скрипт, веб странице → веб-странице, и т. д.);
— Working draft я бы перевёл как «черновая версия».
Интересная статья, спасибо.
>У виджетов на Flash'е одни трудности: большой размер файлов, невозможность изменить размер
>картинки, невозможность взаимодействия с DOM.
У виджетов на Flash'е нет этих трудностей, просто реализовывать не все умеют ;)
Как создатели, так и пользователи. Именно поэтому «Flash 99% bad» © Nielsen
>картинки, невозможность взаимодействия с DOM.
У виджетов на Flash'е нет этих трудностей, просто реализовывать не все умеют ;)
Как создатели, так и пользователи. Именно поэтому «Flash 99% bad» © Nielsen
Спасибо, отличная статья!
я правильно понял, что скоро большинство JS кода будет писаться по стандартам?)
Используйте балансировщик нагрузки при помощи различных URL для подгружаемого файла JavaScript
Относительно javascript, css и прочей "статики" - балансирование нагрузки путем размещения ресурсов на разных доменах/поддоменах малоэффективно и даже отрицательно:
1. статика кешируется - и нагрузка на сервер осуществляется только при первом обращении
2. При размещении ресурсов для одной страницы на разных доменах - скорость загрузки ее(страницы) на клиенте падает из за дополнительных DNS запросов и новых соединений.
о конкретном примере оптимизации одного из виджетов здесь
Странно слышать, что виджеты на флэше - это по-дефолту тяжело из-за картинок.
Есть ведь уймища чисто текстовых виджетов - погодных, новостных, котировочных и так далее. Или же встраиваемых интерфейсов с загрузкой картинок on demand - по клику или по событию. По весу - до 5килобайт максимум, а реально - на два или три с половиной.
...Имхо, все от кривизны рук зависит. В JS-версии можно с таким же успехом заюзать полуторакилограммовый самописный фрэймворк с комментариями, авторскими ремарками и пятнадцатью миллиардами неиспользуемых функций - и получить страницу с загрузкой на полчаса.
Было бы желание :)
Есть ведь уймища чисто текстовых виджетов - погодных, новостных, котировочных и так далее. Или же встраиваемых интерфейсов с загрузкой картинок on demand - по клику или по событию. По весу - до 5килобайт максимум, а реально - на два или три с половиной.
...Имхо, все от кривизны рук зависит. В JS-версии можно с таким же успехом заюзать полуторакилограммовый самописный фрэймворк с комментариями, авторскими ремарками и пятнадцатью миллиардами неиспользуемых функций - и получить страницу с загрузкой на полчаса.
Было бы желание :)
Мне кажется, что проблемы JS - в том, что он есть :) В смысле, Java - технологии, некогда скоростью и гибкостью не обладали. И очень странно почему к примеру, не сделают другого языка. На основе того-же, PHP, руби, питона.
Тут такая-же дилемма. Как примеру развитие операционных систем, тормозит C++.
Появляться конечно новые языки, как примеру D - http://www.digitalmars.com/d/.
Но они многим не известны, да и не популярны.
Тут такая-же дилемма. Как примеру развитие операционных систем, тормозит C++.
Появляться конечно новые языки, как примеру D - http://www.digitalmars.com/d/.
Но они многим не известны, да и не популярны.
JavaScript и Java - это разные технологии, только названия похожи :)
Интересно в чём различие? У всех у них виртуальная машина. У всех чистильщик мусора. Только у JAVA ООП по продвинутей. Конечно, название чисто маркетинговый ход. Но для меня, что JAVA, что JavaScript, что ActionScript, всё очень тормозит, много есть оперативки.
Даже не знаю что и ответить...
Это два совершенно разных языка с разными принципами работы. Конечно, если считать все, что не преобразуется в бинарный код злом, то да, вы правы.
Но в современных реалиях бинарный код - не всегда хорошо.
Это два совершенно разных языка с разными принципами работы. Конечно, если считать все, что не преобразуется в бинарный код злом, то да, вы правы.
Но в современных реалиях бинарный код - не всегда хорошо.
Ну как в моём представлении. Если взять к примеру. C++, с библиотеками типа QT, php - как скриптовой язык. Плюс можно взять ещё библиотеку qt-php для GUI. Далее берём C--, как альтернатива ассемблеру.
То в принципе, на этих связках можно всё написать. И не нужны ни NET, ни JAVA, ни perl с ruby и питоном.
Так, что если к примеру вместо JS - был бы php - на стороне клиента. PHP-5 я имею ввиду. Ну или хотябы ActionScript. То поверьте мне. WEB - бы шагнул далеко вперёд!
То в принципе, на этих связках можно всё написать. И не нужны ни NET, ни JAVA, ни perl с ruby и питоном.
Так, что если к примеру вместо JS - был бы php - на стороне клиента. PHP-5 я имею ввиду. Ну или хотябы ActionScript. То поверьте мне. WEB - бы шагнул далеко вперёд!
и что же бы такого написали на клиентском PHP, чего нельзя написать сейчас на JS?
serelize, нормальные многомерные массивы, iconv, приличный ООП, include, статические переменные, статические функции класса, нормальные регулярки, как perl так и posix, сортировка массивов, человеческий foreach, sprintf - функции, все globals off - тоесть область видимости переменных.
функции как isset и unset. Тоесть возможность проверить есть ли переменная, и возможность удалить переменную. Много чего есть.
функции как isset и unset. Тоесть возможность проверить есть ли переменная, и возможность удалить переменную. Много чего есть.
это список того, что не делается на JS? что-то я с половиной не согласен, взять хотя бы области видимости переменных и возможность include (через AJAX методы)
Область видимости. В JS - Глобальные переменные видны везде. Пишите вы функцию, а она видет все переменные глобальные. Вот вам и тормоза :))!. Далее можно через ajax - делать include. Только смысл? В php можно делать через чтение файлов а потом eval.
Но это не гуд. Это искуственная тема.
Ну а самый отстой в JS. Это объектная модель. Чтобы сделать класс, нужно париться долго. Не говоря уже о статических переменных, и статических функциях класса.
Насчёт массивов да. Можно в JS - сделать многомерные массивы через Object.
Но это будет супер гиморно.
Не говоря уже о регулярках. Глупо в правилах регулярки создавать свой тип?
Чем строка не устраивает.
Ну а самое главное приведение типов.
Согласитесь
f="12";
e = (int)f;
Более элегантно и понятно, чем приведение через функцию.
Можно долго обсуждать.
Даже php - не панацея.
Вот есть AS - более человеческих язык, был бы он хотябы. Бы ла бы другая картинка.
Но это не гуд. Это искуственная тема.
Ну а самый отстой в JS. Это объектная модель. Чтобы сделать класс, нужно париться долго. Не говоря уже о статических переменных, и статических функциях класса.
Насчёт массивов да. Можно в JS - сделать многомерные массивы через Object.
Но это будет супер гиморно.
Не говоря уже о регулярках. Глупо в правилах регулярки создавать свой тип?
Чем строка не устраивает.
Ну а самое главное приведение типов.
Согласитесь
f="12";
e = (int)f;
Более элегантно и понятно, чем приведение через функцию.
Можно долго обсуждать.
Даже php - не панацея.
Вот есть AS - более человеческих язык, был бы он хотябы. Бы ла бы другая картинка.
Мда... а мне почему-то кажется, что это интеллект некоторых программистов "скоростью и гибкостью" не обладает. И правда, очень странно: почему для них не сделают другого языка — получше? Дилемма, однако...
Как говориться всё познается в сравнении. Тем кто программит под WEB. Нету другой альтернативы. Хотя странно, вот с HTML, прогесс есть. Там XHTML. Или как несколько лет назад стали говорить AJAX. WEB 2.0. Хотя я ещё до всяких AJAX. Юзал httprequest. Или submit в скрытый iframe. Я думаю. Пока не сделают нормального WEB языка. Пока не уйдёт на свалку истории HTML. Не будет прорыва в WEB. Когда появился FLASH. Я думал, вот наконецто можно делать нормальные сайты на нём. И никакой вёртски. Потом оказывается поисковики не любят индексировать FLASH. В итоге, я хочу сказать. Что JS - это зло. Безальтернативное зло. И мне очень жалко программистов google. :(
Перечитав ваши последние 3 поста, хочу вас поздравить: в вашу голову встроен отличный бредогенератор! :)
Не надо грази:) Просто после нормальных языков, JS - это зло. Однозначно причем. По всем критериям!. Но альтернативы нет для WEB.
Вы неправы.
http://www.flamefork.ru/development/java…
http://www.flamefork.ru/development/java…
Поправь, пожалуйста:
начиная с технологии AJAX и заканчивая виджетами
"сотни тысяч долларов упущенной прибыли" — вот он, звериный оскал капитализма. =)
А по сути ситуацию может исправить только наличие мозга и временных ресурсов у разработчика сайта, поскольку ни одна серебрянная пуля (стандарты, стайлгайды, фреймворки) не решают проблемы связанные с отсутствием информационной архитектуры
А по сути ситуацию может исправить только наличие мозга и временных ресурсов у разработчика сайта, поскольку ни одна серебрянная пуля (стандарты, стайлгайды, фреймворки) не решают проблемы связанные с отсутствием информационной архитектуры
>> Если мы обратимся к сообществу Java программистов, то можно обнаружить, что эта проблема уже давно у них решена.
Во-первых, стоит заметить, что Java-сообщество — это всё же не другая галактика, и проблемы с использованием js у них ровно те же :) Не решена у них эта проблема, как java-программер говорю вам по секрету.
Фраза про апплеты, сервлеты и страшного зверя EJB — абсолютная дикость, НО: есть мнение, что если бы java-апплеты в своё время не проиграли бы на рынке (не как технология, а именно в маркетинге) — не было бы у нас ни флеша, ни (вероятно) js. И не пришлось бы гугловцам писать фреймворк, компилирующий js в java, а программерам — ломать мозг, интегрируя js-библиотеки со своими приложениями.
Во-первых, стоит заметить, что Java-сообщество — это всё же не другая галактика, и проблемы с использованием js у них ровно те же :) Не решена у них эта проблема, как java-программер говорю вам по секрету.
Фраза про апплеты, сервлеты и страшного зверя EJB — абсолютная дикость, НО: есть мнение, что если бы java-апплеты в своё время не проиграли бы на рынке (не как технология, а именно в маркетинге) — не было бы у нас ни флеша, ни (вероятно) js. И не пришлось бы гугловцам писать фреймворк, компилирующий js в java, а программерам — ломать мозг, интегрируя js-библиотеки со своими приложениями.
Прыгал бы от счастья, узнав, что в новой версии яваскрипта объекты поимеют методы из prototype. В 1.8-й ничего кроме гуляния в сторону ахтунг-синтаксиса нет.
Исправьте, плз:
Они написаны довольно опытными людями
:)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как JavaScript тормозит Веб (и что с этим делать)?