Comments 49
Вы бы не ставили в одном ряду «NodeJS, AngularJS». Первое — это платформа, второе — фреймворк, к тому же клиентский.
Писать в 2013 году про canvas тоже как-то странно.
Писать в 2013 году про canvas тоже как-то странно.
Мне понравился обзор, упорядочил знания в голове и кое-что новое. Спасибо
Хороший обзор, спасибо. Отдельная благодарность за Head Tracking — даже не знал о такой технологии
На первое место стоит выделить тренд использования JavaScript для разработки приложений как на клиенте (браузер), так и на сервере. Несколько лет назад это было экзотикой, но сейчас есть богатый выбор фреймворков для разработки, и похоже что это пришло надолго.
Почти пару десятков лет назад это не было экзотикой. Web-server от покойной Netscape под названием Netscape Enterprise Server умел выполнять server-side JS. Это даже было отражено в документации по JavaScript 1.5
Между «было» и «повсеместно использовалось» — большая пропасть.
Вы сильно переоцениваете распространение NodeJS. Повсеместно используется PHP, Java, Python, Client-side JS. Все остальное — маргинальные технологии по ареалу распространения
Возможно, но… Вы знаете, я тоже так думал. Пока не попал на Frontend DEV Conf '13 в Минске. После конференции, где часов 6 подряд куча докладчиков рассказывала только о клиент-серверном javascript и мозг начал конкретно закипать, мне стало казаться что он повсюду, даже в водопроводном кране :-D
Одно то, что в развитие технологии активно включился Гугль, уже говорит о многом.
Одно то, что в развитие технологии активно включился Гугль, уже говорит о многом.
Вы судите по модным дев-тусовкам о повсеместности распространения языка? Лучше мне назовите 10 успешных проектов на NodeJS
:)
:)
Без понятия, не мой профиль. Если вам так это важно — то я с вами соглашусь. А ребята с InfoWorld's 2012 — просто лохи, неразобравшись впаяли Technology of the Year Award winner. :-D
UFO just landed and posted this here
Посмотрел там и там. Осталось впечатление, что все это мелочевка.
Вот только давайте без маркетинговых слоганов про гибкость и универсальность… :)
У всех языков или технологий есть сильные и слабые стороны. Кроме красивостей самого языка есть еще такие вещи как стоимость владения, стоимость ошибки, стоимость модификации. Событийная модель NodeJS — не самая легкая для понимания, это я говорю как человек, который последние 6 лет пишет в «событийном стиле».
Вот только давайте без маркетинговых слоганов про гибкость и универсальность… :)
У всех языков или технологий есть сильные и слабые стороны. Кроме красивостей самого языка есть еще такие вещи как стоимость владения, стоимость ошибки, стоимость модификации. Событийная модель NodeJS — не самая легкая для понимания, это я говорю как человек, который последние 6 лет пишет в «событийном стиле».
Яндекс Авто, MySpace, Trello
MySpace то тут причем?
Trello — там серверная часть простая и представляет собой обычную REST апишку. Ничего сильно сложного или большого. Так что тут как раз таки Node.js еще подходит.
Такая же картина и с Яндес Авто.
Node.js идеален в случаях когда нужно отдавать данные быстро. Если же писать сайты в классическом стиле, когда все рендрится на сервере, я бы не хотел его использовать.
Trello — там серверная часть простая и представляет собой обычную REST апишку. Ничего сильно сложного или большого. Так что тут как раз таки Node.js еще подходит.
Такая же картина и с Яндес Авто.
Node.js идеален в случаях когда нужно отдавать данные быстро. Если же писать сайты в классическом стиле, когда все рендрится на сервере, я бы не хотел его использовать.
expressjs.com/applications.html там он первый в спике, новый myspace сделан на nodejs + expressjs
Большие проекты на Node.jS довольно редки, обычно это либо что-то маленькое (не сильно большие апишки, демоны, обработчики очередей, комет-сервера), либо разработчики решили рискнуть.
UFO just landed and posted this here
Нельзя мерять по одной задаче успешность технологии. Если ваша задача решилась на NodeJS идеально, это не значит, что на ней можно решать все остальные задачи.
Например, если вам придется сделать систему оценки платежеспособности компаний, а также рисков и кредитоспособности, то там уже будет пофиг на чем писать, так как основная проблема будет в выборе хранилища данных, к примеру Oracle или MSSQL. Вся бизнес-логика будет написана на разновидностях SQL, а кто «фронт» будет отдавать, ну как-то все равно уже.
Каждому языку — свое собственное применение. Нужно знать и понимать все плюсы и минусы, чтобы потом не было мучительно больно.
Например, если вам придется сделать систему оценки платежеспособности компаний, а также рисков и кредитоспособности, то там уже будет пофиг на чем писать, так как основная проблема будет в выборе хранилища данных, к примеру Oracle или MSSQL. Вся бизнес-логика будет написана на разновидностях SQL, а кто «фронт» будет отдавать, ну как-то все равно уже.
Каждому языку — свое собственное применение. Нужно знать и понимать все плюсы и минусы, чтобы потом не было мучительно больно.
UFO just landed and posted this here
Никто не говорит, что вы не можете выбрать. Весь вопрос в том, сколько будет стоить ваше решение. Oracle не детская базейка для микробложиков и сайтиков, это целая экосистема, в которой есть сотни готовых решений, которые сэкономят вам деньги на изобретение велосипедов. Например, такая фича как Transaction Guard, которая позволяет предотвращать двойную вставку данных в базу, если это происходит в слишком короткий промежуток времени, позволит вам на уровне базы не заморачиваться с такой ситуацией. И таких примеров можно набрать сотни, тысячи.
При выборе технологий все забывают про стоимость владения. Программы пишутся не на один раз, а на довольно длительный промежуток времени. Дешево разрабатывать не значит дешево поддерживать, зачастую это прямо противоположные вещи, при сверхдешевой стоимости первичной разработки получается сверхдорогая поддержка.
И не надо меряться временем, сколько лет вы в программинге, это плохой аргумент. Так вот, вы выбрали идеальное для себя решение, и я не буду оспаривать ваш выбор. Мое возражение было к тому, что не для всех задач оно применимо. Загрузите пол террабайта данных в MongoDB, при этом это не тупые ключ-значение, а древовидные структуры, и попробуйте потом из них сделать выборки, например, посчитать среднюю кредитоспособность различных слоев населения по их предыдущей кредитной истории. Я уверен, что Oracle с этим справится на ура, при этом мне не потребуется более одного дня работы специалиста. Вы можете гарантировать, что MongoDB+NodeJS справятся с этой задачей?
При выборе технологий все забывают про стоимость владения. Программы пишутся не на один раз, а на довольно длительный промежуток времени. Дешево разрабатывать не значит дешево поддерживать, зачастую это прямо противоположные вещи, при сверхдешевой стоимости первичной разработки получается сверхдорогая поддержка.
И не надо меряться временем, сколько лет вы в программинге, это плохой аргумент. Так вот, вы выбрали идеальное для себя решение, и я не буду оспаривать ваш выбор. Мое возражение было к тому, что не для всех задач оно применимо. Загрузите пол террабайта данных в MongoDB, при этом это не тупые ключ-значение, а древовидные структуры, и попробуйте потом из них сделать выборки, например, посчитать среднюю кредитоспособность различных слоев населения по их предыдущей кредитной истории. Я уверен, что Oracle с этим справится на ура, при этом мне не потребуется более одного дня работы специалиста. Вы можете гарантировать, что MongoDB+NodeJS справятся с этой задачей?
На первое место стоит выделить тренд использования JavaScript для разработки приложений как на клиенте (браузер), так и на сервере. Несколько лет назад это было экзотикойЭто никогда не было экзотикой.
У Netscape был сервер, у которого в качестве языка был JS, он был экзотикой, да, но у Микрософт, в ASP одним из языков программирования был JScript (вторым — VBScript). За границей ASP был более чем популярен (в связи с чем мне и пришлось делать сайты на этой технологии), в нашем отечестве тоже встречался нередко (сайты, где «расширение» урла было .asp — как раз либо на JScript, либо на VBScript).
Еще по контролю качества кода: www.nczonline.net/blog/2013/07/16/introducing-eslint/
Еще было бы здорово увидеть на хабре сравнительный обзор тулов для тестирования и моков.
Еще было бы здорово увидеть на хабре сравнительный обзор тулов для тестирования и моков.
В среднем для одинаковых действий при использовании CoffeScript требуется в 2 раза меньше строк, чем на чистом JavaScript.
Внезапно. А можно уточнить, откуда взялась эта цифра и что здесь называется «средним»?
Возможно «в 2 раза меньше» — это немножко преувеличение, но вот «в полтора» — вполне. Во всяком случае приложения на Backbone действительно становятся намного короче.
> Во всяком случае приложения на Backbone действительно становятся намного короче.
Вы сейчас написали следующее: любое приложение можно сделать в полтора раза короче, если выделить дублирующийся код и основные паттерны во фреймворк.
Я вам больше скажу: если использовать не фреймворк общего назначения, а прямо под проект его написать — может, и в два, и в три раза меньше получиться.
Я только не понимаю, какое это имеет отношение к декларируему сокращению количества строк кода при использовании CoffeeScript. Что там за золотые пули-то такие?
Вы сейчас написали следующее: любое приложение можно сделать в полтора раза короче, если выделить дублирующийся код и основные паттерны во фреймворк.
Я вам больше скажу: если использовать не фреймворк общего назначения, а прямо под проект его написать — может, и в два, и в три раза меньше получиться.
Я только не понимаю, какое это имеет отношение к декларируему сокращению количества строк кода при использовании CoffeeScript. Что там за золотые пули-то такие?
Конечно можно. Из википедии, которая в свою очередь ссылается на пример, на главной странице оф.сайта. Брутальное сравнение кол-ва символов даёт 440 против 817.
Люди, вы хоть посмотрели на Unreal в браузере?
Да вообще офигеть. Жаль, там врагов нету.
BananaBread — тут они есть
BananaBread is a 3D first person shooter that runs on the web. It takes the Cube 2: Sauerbraten engine, which is written in C++ and OpenGL, and compiles it using Emscripten into JavaScript and WebGL so that it can run in modern browsers using standards-based web APIs and without the need for plugins.
Mozilla (makers of Firefox) created this project for several reasons. First, to serve as a testcase for running a demanding 3D game in browsers
…
BananaBread is a 3D first person shooter that runs on the web. It takes the Cube 2: Sauerbraten engine, which is written in C++ and OpenGL, and compiles it using Emscripten into JavaScript and WebGL so that it can run in modern browsers using standards-based web APIs and without the need for plugins.
Mozilla (makers of Firefox) created this project for several reasons. First, to serve as a testcase for running a demanding 3D game in browsers
…
«JS Video Codec». ORBX не совсем кодек + проприетарный.
В своей статье «Today I Saw The Future» Брендан Эйх в комментариях отвечает на вопрос о лицензии:
«The first point I made in bold is that downloadable codecs do not need to be freely licensed. IPR even if only defensive patents may be in play. But none of this taints the browser. This is a net win, along with the watermarking-not-DRM idea. It beats the H.264 and DRM alternative!»
а также прямо указывает что «ORBX.js, a downloadable HD codec written in JS and WebGL».
Таки кодек.
«The first point I made in bold is that downloadable codecs do not need to be freely licensed. IPR even if only defensive patents may be in play. But none of this taints the browser. This is a net win, along with the watermarking-not-DRM idea. It beats the H.264 and DRM alternative!»
а также прямо указывает что «ORBX.js, a downloadable HD codec written in JS and WebGL».
Таки кодек.
>JS Shells (песочницы)
Указали jsbin.com и jsfiddle.net/ — и не указали jsperf.com/ — крайне интересный проект.
Указали jsbin.com и jsfiddle.net/ — и не указали jsperf.com/ — крайне интересный проект.
Тут немного другая специализация — оценка производительности кода: «jsPerf aims to provide an easy way to create and share test cases, comparing the performance of different JavaScript snippets by running benchmarks. But even if you don’t add tests yourself, you can still use it as a JavaScript performance knowledge base.»
Но, я думаю, стоит добавить в статью ссылку. Спасибо.
Но, я думаю, стоит добавить в статью ссылку. Спасибо.
Стоит добавить test runner Karma (бывший Testacular) с неплохими встроенными средствами анализа покрытия кода.
Sign up to leave a comment.
Интересные аспекты развития JavaScript и веб-технологий 2013-го года