Comments 73
Поздравляю! Вам удалось-таки вернуться в 2007 год!
Какая жесть. Зачем пытаться привести один язык к другому? Лучше использовать Yii (или Rails, от которого Yii и пошел) и радоваться жизни.
Какая же жесть когда люди даже вникнуть не пытаются.
Это не перевод одного языка в дорогому, а заимствование архитектуры и подход фреймворка Yii для реализации приложений на js на фронте, беке в едином стиле.
Конечно сомнительно дальнейшее развитие проекта сообществом, и в целом его использование, но идея прикольная :)
Jii проектируется с учётом того, что он должен работать везде где можно — браузер, сервер, phonegap, node-webkit и т.п.
Это не перевод одного языка в дорогому, а заимствование архитектуры и подход фреймворка Yii для реализации приложений на js на фронте, беке в едином стиле.
Конечно сомнительно дальнейшее развитие проекта сообществом, и в целом его использование, но идея прикольная :)
Я имел ввиду, что есть другие фреймворки, которые были разработаны учитывая особенности JS. И, по моему скромному мнению, использовать их будет логичнее.
заимствование архитектуры и подход фреймворка Yii для реализации приложений на js на фронтеВот уж чего точно не стоит делать — там другие проблемы, нужны другие подходы. Да и решений (самых разных) хватает.
Когда нужно сделать какое-либо реалтайм приложение, с комет-сервером или демонами — то PHP уже лучше не использовать. Да, можно использовать множество других языков программирования буть то Ruby/Python/Go/… Но если есть знания только JavaScript (а они сейчас у большинства должны быть, frontend никто не отменял), то можно начать использовать Node.js, а когда есть еще и похожий на ранее используемый в PHP фреймворк — это большой плюс, в этом основная идея.
И если Вы владеете хорошо другим ЯП, который решает данные задачи — то скорее всего и не стоит переходить на Node.js с Jii, статья не для вас просто.
И если Вы владеете хорошо другим ЯП, который решает данные задачи — то скорее всего и не стоит переходить на Node.js с Jii, статья не для вас просто.
>а они сейчас у большинства должны быть
У большинства кого, простите? Тех кто занимается frontend? Ну да, логично наверное. Но не все же им занимаются и даже не большинство
У большинства кого, простите? Тех кто занимается frontend? Ну да, логично наверное. Но не все же им занимаются и даже не большинство
Да, я про frontend. Мне кажется любому веб-разработчику приходилось хоть немного, но сталкиваться с JavaScript.
По вашему бекенд разработчиков на js не бывает? nodejs под современные задачи куда более лучше ложится нежели любой другой язык(тул).
А фронт сейчас если не больше, то как минимум ровня по значимости в проекте. Так как его стеки юзаются не только в браузере и сейчас все же уже не те, требования как раньше. Сейчас все хотят себе spa и прочие приложухи.
А фронт сейчас если не больше, то как минимум ровня по значимости в проекте. Так как его стеки юзаются не только в браузере и сейчас все же уже не те, требования как раньше. Сейчас все хотят себе spa и прочие приложухи.
>По вашему бекенд разработчиков на js не бывает?
Бывает конечно, но в оригинале написано именно «у большинства». Я позволю себе даже не бегая за реальными цифрами сделать утверждение, что большинство программистов (даже не разделяя фронт и бэк) — не js программисты и многие с ним если сталкивались, то разве что на уровне какого-нибудь простого скрипта или вообще добавление небольшого куска jquery на страницу.
По этому мне утверждение о том, что большинство почему-то должно знать и уметь js показалось странным.
Бывает конечно, но в оригинале написано именно «у большинства». Я позволю себе даже не бегая за реальными цифрами сделать утверждение, что большинство программистов (даже не разделяя фронт и бэк) — не js программисты и многие с ним если сталкивались, то разве что на уровне какого-нибудь простого скрипта или вообще добавление небольшого куска jquery на страницу.
По этому мне утверждение о том, что большинство почему-то должно знать и уметь js показалось странным.
Да, спасибо. В таком свете это кажется вполне логичным. Но все-таки :)
Идея отличная! Обязательно попробую его в своих проектах.
Транслирование ES6 в более ранние редакции стандарта можно сделать через Babel.
При разработке вы можете использовать node-babel, а перед публикацией пакета в npm выполнять соответствующий таск в секции scripts.prepublish. Пример по ссылке.
В ES5 тоже нет специального синтаксиса неймспейсов, и что? ES6 есть модули — используйте их!
Геттеры и сеттеры появились еще в ES5, что изменилось?
Надуманно.
Не придется.
При разработке вы можете использовать node-babel, а перед публикацией пакета в npm выполнять соответствующий таск в секции scripts.prepublish. Пример по ссылке.
В es6 нет неймспейсов, а они нужны для повторения фич Yii. Их можно имплементировать через модули, но это будет костыль. Менять один костыль на другой — нет смысла.
В ES5 тоже нет специального синтаксиса неймспейсов, и что? ES6 есть модули — используйте их!
В ES6 захочется использовать геттеры и сеттеры, но они не поддерживаются старыми браузерами, как говорилось выше
Геттеры и сеттеры появились еще в ES5, что изменилось?
Многие разработчики не знают формата es6/coffeescript/typescript и это будет дополнительный порог вхождения
Надуманно.
Сложность работы с кодом разных форматов (ES5 и ES6). Не всегда есть возможность в существующем проекте поменять весь код на es6, а наследовать es6 классы все равно нужно, и все равно прийдется использовать Jii.defineClass() для создания классов — костыль не уходит.
Не придется.
Сложность работы с кодом разных форматов (ES5 и ES6).
Вы так говорите как будто это разные языки а не расширение существующего. И вы уверены что уже не используете не ведая о том некоторый ES6 плюшки? А если таки не используете то уверены ли что хорошо делаете?
JavaScript фреймворк с архитектурой от Yii 2
А тут пожалуй кроется главная проблема.
> JavaScript фреймворк с архитектурой от Yii 2
Но зачем???
Но зачем???
Ну нравится человеку — пусть пишет :)
Ребят, я не один такой, кому пришла в голову такая идея. Вы просто другого мнения, проходите мимо :)
Согласен. У меня к проекту только один вопрос — даже Yii2 еще очень сырой, хотя я его и использую, просто потому что первый всё равно уходит. А с JII большой вопрос — будет ли когда-то достаточно развитый код, и достаточная экосистема, чтобы стоило им пользоваться. А так — была бы отличная идея.
Yii2 уже не сырой, мы его в нескольких проектах в продакшене используем и багов критичных не замечал. Jii еще только начал развиваться, но у него большое будущее. Я жду когда появится какой-нить заказ (проект) большой, на котором можно будет его освоить, тогда и баги всплывут и поддерживать хочешь или нет — прийдется.
Я тоже его использую. И тоже не вижу критичных багов. Но по степени его развитости он сильно уступает первому.
Документация слабовата, пул расширений еще недостаточно развит, даже просто ответов на разные ситуации в гугле меньше… Всё это в разы меньше. Меня устраивает уровень развития экосистемы первого. Количество специалистов, документации, документации сторонних разработчиков, кучи примеров, кучи расширений и т.п. Но новые проекты на нем писать нерационально. Поэтому приходится начинать работать на втором, мирясь с недостатками и надеясь что экосистема быстро доростет.
У вас же стадия в разы хуже. Ничего личного, но одному такую задачу не поднять. Я тоже когда-то думал, что необходимость поддержки большого проекта поможет сохранить фреймворк. Закончилось переездом проекта под юии2)
Пока-что было интересно почитать, будем надеяться что пару человек в команду к вам присоединится, а тогда уже может и лавина пойдет. Но тут или выгорит или не выгорит…
Документация слабовата, пул расширений еще недостаточно развит, даже просто ответов на разные ситуации в гугле меньше… Всё это в разы меньше. Меня устраивает уровень развития экосистемы первого. Количество специалистов, документации, документации сторонних разработчиков, кучи примеров, кучи расширений и т.п. Но новые проекты на нем писать нерационально. Поэтому приходится начинать работать на втором, мирясь с недостатками и надеясь что экосистема быстро доростет.
У вас же стадия в разы хуже. Ничего личного, но одному такую задачу не поднять. Я тоже когда-то думал, что необходимость поддержки большого проекта поможет сохранить фреймворк. Закончилось переездом проекта под юии2)
Пока-что было интересно почитать, будем надеяться что пару человек в команду к вам присоединится, а тогда уже может и лавина пойдет. Но тут или выгорит или не выгорит…
Один человек уже присоединился, надеюсь не последний :)
Но ведь вопрос действительно интересный!
Почему, к примеру, не Jymfony или Jaravel, или Jend в конце концов?)
Есть какое-то логическое объяснение, кроме «вы другого мнения, проходите мимо»?
Почему, к примеру, не Jymfony или Jaravel, или Jend в конце концов?)
Есть какое-то логическое объяснение, кроме «вы другого мнения, проходите мимо»?
Просто потому что я хорошо знал Yii. Jii вырос не из идеи «клонировать какой-нить фреймворк», а из потребности сделать какую-то архитектуру в одном из проектов, и писалось нечто похожее на Yii и только потом это все выросло в отдельный проект и переписано с нуля. Немного истории тут.
Скорее почему. Когда люди меняют один язык на другой, они стараются писать старыми методами в новом/другом языке. Я тоже так делал, но быстро прошло.
Проходит, когда есть что-то взамен. Я вот не видел в Node.js нормального Query Builder и Active Record (во всяком случае в то время, когда его писал, сейчас — не знаю, подскажите), которые можно было бы сравнить по функционалу с Yii.
Yii ведь тоже много чего взял с других фреймворков и других языков программирования, но от этого ведь он хуже не стал :)
Yii ведь тоже много чего взял с других фреймворков и других языков программирования, но от этого ведь он хуже не стал :)
У каждого свои понятия «нормальности». Я пользуюсь mongoose, как и многие другие JS разработчики. Некоторые хвалят Sequelize.
Да, Sequelize — хорошая альтернатива. Раньше тоже его видел, но он был не такой богатый вроде.
Ну а mongoose — это только монгодб, иногда нужны реляционные БД.
Ну а mongoose — это только монгодб, иногда нужны реляционные БД.
Sequelize хорошая штука, но это не QueryBuilder. Если нужно мало-мальски не тривиальный запрос сделать, то он уже становится бессильным. Приходится для этих целей использовать squel.
У Вас из ORM только первая ссылка, остальное — клиенты БД (драйвера).
Признаюсь, было лень искать именно ORM, гуглил исключительно по названию баз данных, поэтому исправляюсь:
— www.npmjs.com/package/orm (MySQL & MariaDB, PostgreSQL, Amazon Redshift, SQLite, MongoDB)
— www.npmjs.com/package/oracle-orm (Oracle)
— bookshelfjs.org (PostgreSQL, MySQL & SQLite3)
— docs.sequelizejs.com/en/latest (PostgreSQL, MySQL, MariaDB, SQLite & MSSQL)
Чем ваше решение лучше?
— www.npmjs.com/package/orm (MySQL & MariaDB, PostgreSQL, Amazon Redshift, SQLite, MongoDB)
— www.npmjs.com/package/oracle-orm (Oracle)
— bookshelfjs.org (PostgreSQL, MySQL & SQLite3)
— docs.sequelizejs.com/en/latest (PostgreSQL, MySQL, MariaDB, SQLite & MSSQL)
Чем ваше решение лучше?
bookshelf ранее не видел, про sequelizejs уже писал.
Да оно и не обязано быть на голову выше, альтернатива — это ж ведь всегда хорошо. :)
Просто кому-то (как, например мне) будет легче использовать ORM с уже ранее известным API.
bookshelf, кстати, даже чем-то схож с Jii
Да оно и не обязано быть на голову выше, альтернатива — это ж ведь всегда хорошо. :)
Просто кому-то (как, например мне) будет легче использовать ORM с уже ранее известным API.
bookshelf, кстати, даже чем-то схож с Jii
Совместимость со знакомым АПИ это большой плюс. Очень большой.
Недавно обсуждали в одном проекте переход на другой фреймворк.
Предложенный сеньором набор технологий был бы идеальным. Ситуация в проекте позволяет менять технологию ибо в существующих подпроектах или перенос на другой фремворк или глобальный рефакторинг или такая стадия разработки что легко можно поменять.
Идею мы завернули чисто потому что хоть разрабов можно подтянуть на нужный пул технологий, но это требует времени, и дальнейшая поддержка будет дорогая. Новые спецы дороги, хороший спец по нужным технологиям у нас только один, в случае его уходя будут проблемы… в общем завернули мы этот план. На юии2 я могу сесть и писать сам. Даже менеджер наш кое-что может сделать в юии2, потому как в свое время я его начинал учить на верстальщика, и CRUD-приложения он говнокодил под юии2 исправно…
А вот если бы Jii уже была бы стабильной и с экосистемой и предложение перехода было бы на него, то такой вопрос бы даже не вставал бы — перешли бы не задумываясь. И не потому что юии2 идеальный фреймворк. Нет. Просто он ХОРОШИЙ и ЗНАКОМЫЙ. Всё.
Недавно обсуждали в одном проекте переход на другой фреймворк.
Предложенный сеньором набор технологий был бы идеальным. Ситуация в проекте позволяет менять технологию ибо в существующих подпроектах или перенос на другой фремворк или глобальный рефакторинг или такая стадия разработки что легко можно поменять.
Идею мы завернули чисто потому что хоть разрабов можно подтянуть на нужный пул технологий, но это требует времени, и дальнейшая поддержка будет дорогая. Новые спецы дороги, хороший спец по нужным технологиям у нас только один, в случае его уходя будут проблемы… в общем завернули мы этот план. На юии2 я могу сесть и писать сам. Даже менеджер наш кое-что может сделать в юии2, потому как в свое время я его начинал учить на верстальщика, и CRUD-приложения он говнокодил под юии2 исправно…
А вот если бы Jii уже была бы стабильной и с экосистемой и предложение перехода было бы на него, то такой вопрос бы даже не вставал бы — перешли бы не задумываясь. И не потому что юии2 идеальный фреймворк. Нет. Просто он ХОРОШИЙ и ЗНАКОМЫЙ. Всё.
Есть ещё классный www.npmjs.com/package/waterline — у него фишка что кроме обычных SQL баз данных, поддерживает ещё и MongoDB.
В Jii в будущем тоже планируется, по аналогии с yii2-mongodb, может быть даже кто-нить возмется реализовывать
Мне Waterline не понравился багами.
Вы бы ещё “jsNuke” на яваскрипте запилили с соответствующей архитектурой phpNuke'а.
Juke
phpNuke так страшен, что даже шутить про него опасно? (:
Я уже понял свою ошибку.
WIKI:
Мне уже страшно стало o_O
Написана на PHP с использованием СУБД MySQL (последние версии (6.5 и позднее) поддерживают также соединения с такими базами данных, как PostgreSQL, Microsoft SQL Server, MS Access, Oracle, DB2, SQLite). Данная возможность появилась после подключения популярного форума phpBB к php-Nuke в виде модуля.
Мне уже страшно стало o_O
Да сколько моно уже плодить эти JS фреймворки.
Чем обусловлен выбор when, а не github.com/petkaantonov/bluebird?
Правильный вопрос зачем вообще промисы и уж тем более полифилы, если сегодня они уже нативно поддерживаются.
Имплементацию производительности выбирал исходя из производительности. Промисы нативно далеко не везде есть, when их реализует по спецификации es6 — поэтому когда в node появятся промисы — будут они использоваться
«V8 native promises are freakishly slow. If you require any type of performance while using Promises then I'd recommend bluebird.» написал один из основных контрибьюторов Node.js ;) github.com/joyent/node/issues/14384
Юзаю на серьезном проекте. Штука что нада. И шторм понимает неймспейсы. Советую!
Спецы по es6, вам слово — toster.ru/q/276621 :)
Sign up to leave a comment.
Jii — JavaScript фреймворк с архитектурой от Yii 2