Comments 50
Файрфокс станет тормозить ещё сильнее!
Так и компы будут быстрее!
Ну, как сказать... Они одновременно и ядро новое разрабатывают, которое пошустрей должно быть. Ведь, если задуматься, то разница между 1.5, 2, и даже 3 будет не такой и значительной, скорее добавление поддержки новых технологий в старый движок, новые возможности в интерфейсе и т.п.
В то же время идет разработка нового ядра, основанного на целой связке новых революционных технологий.
В то же время идет разработка нового ядра, основанного на целой связке новых революционных технологий.
Tamarin обрабатывает javascript примерно в 5 раз быстрее чем Gecko.
Что-то мне подсказывает, что это часть общей программы по поддержке в FF Silverlight'а, JavaFX и т.п. расширений.
так и до операционной системы недалеко
Вы смеетесь, а Mozilla Foundation ведет разработку собственной рабочей среды для Linux.
это же отлично!
А можно ссылку на какой-нибудь текст, это подтверждающий?
Pyro is a new kind of desktop environment for Linux built on Mozilla Firefox. Its goal is to enable true integration between the Web and modern desktop computing.
http://www.pyrodesktop.org
http://www.pyrodesktop.org
http://www.pyrodesktop.org
FF4 когда еще будет. Вот FF3 альфы пока только выпускают.
Насчет Tamarin'а (никак разработчикам имя Тамара нравится :) ) - сама идея отдельной машины для обработки js'а мне нравится - скорость выполнения js скриптов должна вырости, хотя хз как там будет, на данный момент медленнее ff js обрабатывает только ie6, а тут гордится нечем.
Не нравится мне здесь одно - привязка к четвертому файрфоксу. Т.е. раньше первых альф 4-го фф - мы НИКАКИХ либ по тамарину не увидим скорее всего. А мне бы хотелось, например, получить альфу тамарина для ФФ2 или ФФ3, как только она будет готова.
Насчет Tamarin'а (никак разработчикам имя Тамара нравится :) ) - сама идея отдельной машины для обработки js'а мне нравится - скорость выполнения js скриптов должна вырости, хотя хз как там будет, на данный момент медленнее ff js обрабатывает только ie6, а тут гордится нечем.
Не нравится мне здесь одно - привязка к четвертому файрфоксу. Т.е. раньше первых альф 4-го фф - мы НИКАКИХ либ по тамарину не увидим скорее всего. А мне бы хотелось, например, получить альфу тамарина для ФФ2 или ФФ3, как только она будет готова.
Вы куда-то торопитесь?
А давайте все-таки на "ты"? :)
Нет, не тороплюсь. Но согласись, что завязывать сроки выхода тамарина на Firefox 4 - не сильно хорошая идея. Если бы было наоборот - тамарин был бы одним из модулей FF4, и мы могли бы потестить FF4/Tamarin (в зависимости от того, что раньше вышло бы) независимо от второго продукта.
Нет, не тороплюсь. Но согласись, что завязывать сроки выхода тамарина на Firefox 4 - не сильно хорошая идея. Если бы было наоборот - тамарин был бы одним из модулей FF4, и мы могли бы потестить FF4/Tamarin (в зависимости от того, что раньше вышло бы) независимо от второго продукта.
Не хочется вас расстраивать, но разработчикам скорее нравится когтистая обезъяна ;)
Да, я тут о Tamarin'е как таковом что-то... А тема немного о другом.
На мой взгляд, Python и Ruby в Tamarin'е штука хоть и не лишняя, но и востребована не будет. По одной простой причине - даже если Mozilla Foundation и выпустит библиотеку для остальных браузеров - где сказано, что пользователи ее поставят. А завязывать клиентские скрипты только на Firefox - ну это не совсем хорошо, ИМХО.
PS. Вспомните судьбу VBS на клиентских машинах. И сравните кол-во vbs и js скриптов.
На мой взгляд, Python и Ruby в Tamarin'е штука хоть и не лишняя, но и востребована не будет. По одной простой причине - даже если Mozilla Foundation и выпустит библиотеку для остальных браузеров - где сказано, что пользователи ее поставят. А завязывать клиентские скрипты только на Firefox - ну это не совсем хорошо, ИМХО.
PS. Вспомните судьбу VBS на клиентских машинах. И сравните кол-во vbs и js скриптов.
Тем не менее, фраза "для корректной работы нужна поддержка VB Script" встречается крайне редко, а вот фраза "рекомендуется использовать файрфокс" - сплошь и рядом...
Речь идет немного о большем нежели Python/Ruby вместо JavaScript, поскольку оный сейчас удовлетворяет все потребности, кроме может быть производительности. Речь скорее идет о среде для создания веб-приложений где большая часть логики будет на клиенте (именно поэтому как мне кажется и выбрали байткод, а не интерпритацию), а писать серьезную логику js'ом конечно можно, но совсем не вкусно.
Интересно. IronPython и IronRuby - это реализации языков под платформу .NET. Соответственно, виртуальная машина и фреймворк уже есть - под виндой это будет стандартный .NET Framework, под *nix, полагаю, Mono. Хотелось бы на всё это посмотреть и опробовать в разработке. Будем ждать.
А зачем собственно браузеру подобные возможности?
Если эти языки будут использоваться в духе JS, то их также обкромсают и мы получим практически те же возможности, или я не прав? В клиенте нельзя давать языкам использовать все их возможности.
И еще не факт, что новые языки вытеснят JS.
Потом, если использовать эти языки для написания новых плагинов, то это тоже сомнительной полезности возможность. Думаю, большинству проще скачать и установить готовый плагин, другому большинству проще найти готовое решение и не тратить время.
Или я где-то не прав?
Если эти языки будут использоваться в духе JS, то их также обкромсают и мы получим практически те же возможности, или я не прав? В клиенте нельзя давать языкам использовать все их возможности.
И еще не факт, что новые языки вытеснят JS.
Потом, если использовать эти языки для написания новых плагинов, то это тоже сомнительной полезности возможность. Думаю, большинству проще скачать и установить готовый плагин, другому большинству проще найти готовое решение и не тратить время.
Или я где-то не прав?
По-идее, возможности любого скриптового языка работающего в браузере ограничены манипуляцией DOM'ом браузера. Так что, действительно непонятно зачем.
Речь идет скорее не о возможности замены js, а о клиентской, кроссплатформенной среде для исполнения приложений, то есть большая часть логики передается на клиент в виде байт-кода (именно поэтому и выбрали Iron), а с сервера получает только данные. Если рассматривать с точки зрения MVC то на сервере остается Model, а в браузере у нас и View и Controller. В общем то, о чем так давно говорили большевики.
Единственный вопрос как они добьются кроссплатформенной .NET оболочки.
Единственный вопрос как они добьются кроссплатформенной .NET оболочки.
Вот этот вопрос и меня интересует - чуть выше я его задал.
Получил минус без ответа :\
Получил минус без ответа :\
Может, здесь просто не любят слово .NET? ;)
Хехе :) Ну если так смотреть - то я же один раз сказал .NET, а потом еще *nix и Mono (по логике их должны плюсовать) => -1 +2 = +1.
Но да пёс с ней, с цифрой. Лучше бы тот минусёр разъяснил или опроверг мои догадки - а так только почвы для домыслов прибавил.
Но да пёс с ней, с цифрой. Лучше бы тот минусёр разъяснил или опроверг мои догадки - а так только почвы для домыслов прибавил.
Mono - это засланный казачок мирового империализма, так что за него тоже -1 ;)
В общем, я там ниже своё мнение отписал.
В общем, я там ниже своё мнение отписал.
Меня тоже немного удивило, почему на Java, есть жу Jython и JRuby, но наверняка какие-то причины на это были.
По ссылку, строго говоря, ничего не сказано про то, что не будет поддержки J-языков.
Речь идет только о создании механизма, позволяющего отображать байт-коды IronRuby & IronPython на Tamarin.
Речь идет только о создании механизма, позволяющего отображать байт-коды IronRuby & IronPython на Tamarin.
Поддержки Java байт-кода не будет, поскольку выбран .NET байткод, я думаю так, поскольку говорить о поддержке двух виртуальных машин, не всилах даже mozilla, хотя пройдет время, увидим.
Там, конечно, немного невнятно написано. Но речь не идет про интерпретацию .NET'овского байткода. Там написано "the project to map IronPython and IronRuby to Tamarin", что, на мой взгляд, читается как "отобразить IronPython и IronRuby на Tamarin".
Например, за счет преобразования байт-кодов.
Но вообще это всё гадание на кофейной гуще, ну его нафиг.
Например, за счет преобразования байт-кодов.
Но вообще это всё гадание на кофейной гуще, ну его нафиг.
использовать IronRuby и IronPython в рамках Tamarin можно только используя виртуальную машину в рамках которой этот код исполняется.
Да, придется подождать детальной информации.
Да, придется подождать детальной информации.
использовать IronRuby и IronPython в рамках Tamarin можно только используя виртуальную машину в рамках которой этот код исполняется.
Почему???
А в чем беда?
Есть ведь Mono. Для интерпретации (или что у них там будет? JIT'тинг?) байткода его вполне хватит.
А библиотеки, на сколько я понимаю, они в любом случае будут писать свои.
Есть ведь Mono. Для интерпретации (или что у них там будет? JIT'тинг?) байткода его вполне хватит.
А библиотеки, на сколько я понимаю, они в любом случае будут писать свои.
Беды то конечно никакой нет, вопрос исключительно в качестве реализации.
IronPython, IronRuby и Mono, скажем так еще недоделаные до конца технологии, и вопрос в том, как они заживут вместе.
Они просто сделают API к своему DOM парсеру, XSLT трансформатору, и к дополнительным ресурсам браузера.
Вообще Mozilla респект и уважуха за подобные начинания, посмотрим что из этого получиться.
IronPython, IronRuby и Mono, скажем так еще недоделаные до конца технологии, и вопрос в том, как они заживут вместе.
Они просто сделают API к своему DOM парсеру, XSLT трансформатору, и к дополнительным ресурсам браузера.
Вообще Mozilla респект и уважуха за подобные начинания, посмотрим что из этого получиться.
Ну если как очередные возможности для создания разнообразных WebOS, то да. Только почему именно Ruby и Python?
Sign up to leave a comment.
Поддержка Ruby и Python на клиенте в Firefox 4