Pull to refresh

Comments 72

UFO just landed and posted this here
Список состоит из 5 фреймворков, какой бы из них вы заменили на Knockout?)
Меня больше удивляет, почему в каждый такой «обзор» за уши тащат реакт.

Пожалуйста, раскройте мысль, почему "за уши"?

Ну какие-то двойные стандарты получаются. Как в обзорах, так фреймворки, а как начинается стандартное нытье, так «ну вот, реакт — это же месиво из библиотек, хочу все из коробки». Поэтому и за уши.

Меня больше удивляет появление в списке "одного из самых популярных фреймворков — Meteor", по которому целых… 0 вакансий на рынке труда.

Тоже удивило, когда метеор вообще из фулл-стэк тусовки.
По поводу вакансий думал, что не все так плохо…

Вы сами же и ответили: все зависит от того чем мерить эту "популярность". Я например для себя такой список составил:


Самые популярные js-фреймворки и библиотеки

image


Достаточно объективно? Очевидно — нет. Все эти списки публикуются ради публикации, ни грана полезной информации в них, но тем не менее они существуют. Меня вот это больше удивляет.

todomvc — вообще суперский фреймворк. Всем рекомендую.

UFO just landed and posted this here
Почему-то многие считают его «немодным» и «тормознутым».
У меня от него только положительные впечатления, особенно когда из всех фич новомодных фреймворков тебе нужны только двухсторнний байндинг данных и observables/computed поля. Конечно, когда с помощью его пытаются рендерить сложные иерархические формы с таблицами по несколько тысяч записей, то это становиться больно, но не думаю что у ангуляра или реакта ситуация намного лучше.
UFO just landed and posted this here
UFO just landed and posted this here
Уже лет 5 сижу в нокауте и мое мнение: на нем можно делать все что захочешь. Берешь его, еще webpack с его ES2015 и получаешь реактивный и очень легко поддерживаемый фронт, с которым за несколько часов может разобраться любой нормальный программист не имеющий опыта с js и/или с вышеуказанными кучами, которыми даже не пользуются их создатели.

Из пяти "фреймворков", настоящих только два — Meteor и Ember. Остальные даже не знаю как сюда попали.

в списке присутствуют библиотеки, если это очень принципиально могу добавить в название «обзор фреймворков и библиотек»
А почему Angular не попадает под ваше определение фреймворка, если не секрет?

Потому что фронтенд это не только формочки, но и данные (и их связи). В Angular 2 уже появился встроенный универсальный способ организации модели данных? (на сколько я помню нет, могу ошибаться. Поправьте если что)

Фреймворк — это когда ваш код является модулем для стороннего, а библиотека — когда сторонний код является модулем для вашего. Все остальные деления по объему функционала — субъективщина.

Так Вы про "мое определение фреймворка" и спрашивали =)
В "моем определении", если нет встроенного способа работы с данными (в довесок ко всему остальному) — значит не фреймворк.


Но все же, появился ли универсальный способ организации модели данных в Angular 2?

Для меня ваше определение звучит примерно как «всё что меньше 42 — не число» :)

Что вы подразумеваете под «работать с данными»? Angular предоставляет двусторонний биндинг для любых javascript-объектов, поэтому какой-то отдельный слой работы с данными нет необходимости встраивать в ядро фреймворка. Второй версией еще толком не попользовался, но в первой все потребности работы с данными покрывались чудесным lo-dash.

Я имею в виду слой бизнес-логики, реализующий предметную область, а также отвечающий за персистентность, например как Model в Backbone — описал модель, накидал туда логики (например валидация) и вызвал model->save().


Если, например, нужно смоделировать связи между объектами и т.д.


Какой у AngularJS стандартный способ решения таких задач?

Какой у AngularJS стандартный способ решения таких задач?

Получил JSON с сервера, просунул его в шаблон, наложил фильтры.

Если писать на Typescript, то — описал модель в виде interface, объявил сервис-репозиторий для работы с ней, накидал туда логики и вызвал $http.put(...).

Никакого встроенного способа построения моделей а-ля ActiveRecord в ангуляре нет. Наверняка кто-то умный написал стороннюю реализацию (и не одну), но у до сих пор не было в ней потребности.
Напишу немного по подробней.
Фреймворк — это каркас программного приложения, имеющий определенную структуру и оставляющий места для внедрения своего кода, определяющего конкретное поведение приложения. Например такие места как создание конкретных моделей, конкретной логики и определенного отображения в случае MVC структуры фреймворка. Библиотека — это программный код, функции и классы которого могут быть использованы в структуре другого приложения.
Вы про ember-data? Я утверждать не буду, но вроде как этот пакет отдельно ставится?
Ну, насколько я помню, из него родился js-data, который прекрасно сочетается с чем угодно, разве не так? Мне кажется, возможность взять лучшие кусочки и собрать из них то, что действительно требуется для решения задачи — это действительно удобно.
UFO just landed and posted this here
На самом деле точно так же, как и в гугле ангуляр не используется :)
UFO just landed and posted this here
Аналогично, реакт используется активно в инстаграме в качестве react native, но это уже совсем другая история…
UFO just landed and posted this here
Неплохо бы к обзору добавить популярные сайты, использующие тот или иной фреймворк.
Например, по моей личной классификации один из самых тормознутых сайтов это Твиттер, один из самых бестолковых (да и тоже не без тормозов) это Фейсбук. Чтобы знать что не нужно использовать, чтобы не уподобляться этим сайтам.
А вот например ВКонтакте и Хабр — очень даже шустрые. Полезно знать какие фреймворки там применяются и применяются ли вообще.
UFO just landed and posted this here
UFO just landed and posted this here
А Meteor тут что делает?! React за уши притащили, а этого-то за что?:)
Всё, конечно, можно назвать фреймворком, даже так, всё что НАД javascript можно назвать фреймворком. Но Meteor всё-таки — клиент-серверная платформа в первую очередь, не забывайте, что её можно писать на тех же React, Angular, а может и на всех вышеперечисленных.

Meteor как раз фреймворк, но не фронтенд, а гибридный. Из коробки он для рендеринга на фронтенде предлагает Blaze. Но конечно под слово "платформа" тоже подходит =)

Ну явно не про Blaze речь идёт, иначе автор хотя бы намекнула:)
Подходит — да, а попробуйте присовокупить это к одному из вышеуказанных фреймворков и ничего не получится.
И кстати вот (с meteor.com), хотя это всё равно не добавляет ясности:
Meteor is a complete platform for building web and mobile apps in pure JavaScript.

Сейчас, Meteor больше как платформа, и команда Meteor рекомендует использовать React на фронте, так же как и Apollo, ведь в новой версии Meteor будет предлагаться Apollo в качестве Data

Было бы куда интересней узнать, что в этих фреймворках/библиотеках общее и устоявшееся — что съедобного, наконец, получилось из кипящей каши современного JS.

"Недавно JavaScript занят место среди лучших языков для изучения по версии IBM в 2017 году".

reactjs.net это не сайт реакта, это сайт его бинда к дотнету.
Сайт реакта — https://facebook.github.io/react/
эта ссылка в статье и была: https://facebook.github.io/react/
там в конце таблица с левой ссылкой
UFO just landed and posted this here
UFO just landed and posted this here
TypeScript

Для любого большого долгоживущего проекта это огромный плюс, ибо писать jsdoc, запоминать, вручную проверять типы и/или надеяться что ide это всё поймет — странно. Кроме того, TypeScript этот по сути тот же js, но с сахаром для контроля типов, поэтому если имели дело с js и с любым типизированным языком сложностей с ним вообще никаких. Но кстати можно и без него, на чистом js.


Фреймворки диктуют свои правила там, где мне нужно иное.

Обычно это тоже хорошо, особенно если разработчиков много. Создавать же свои "реализации MVC" и прочего в 2017 году немного странно (неужели кто-то еще не наигрался?)


С webpack можно вообще забыть о них.

Angular2 судя по документации прекрасно дружит с webpack-ом https://angular.io/docs/ts/latest/guide/webpack.html


Особенно если backend написан на другом языке.

Нет тут вообще никаких проблем, более того, по наблюдением за апворком, обычно проекты на angular-е используют разные beck-end-ы (php, java, .net, ноду и т.п.), а тот же react в > 90% идет только с нодой...

UFO just landed and posted this here

Попробуйте лучше $mol, где статическая типизация почти не вызывает боли .

TypeScript лёгкий, когда с ним уже чуть-чуть поработал или есть кого спросить, с наскоку же понять, как написать свой *.d.ts для непокрытой сообществом библиотеки мне показалось несколько сложно. Тем не менее я всецело за TypeScript.


Между "своей реализацией MVC" и приколоченной гвоздями не лучшей реализации чего-то там существует разница. Совсем новичку, может и чудесно, когда его за ручку водят по "лучшим практикам", но ничуть не реже получается, что приходится бороться с тем, что тебе дали, вместо того чтобы взять то, что тебе подходит. Не вижу ничего плохого в том, чтобы иметь возможность, в зависимости от задачи и предпочтений команды выбирать между Baobab, MobX, Redux. Мне кажется, это именно то, что входит в понятие свободы.


а тот же react в > 90% идет только с нодой...

Причина совсем не в том, что React хочет NodeJS-бэкенд, а в том, что с React совсем не сложно получить серверный рендеринг, это у всех на слуху, и чего бы не спросить тогда с разработчика сразу и эту фичу?
Ну, а так, действительно, бэкенд никак не ограничивает, можно хоть Angular, хоть React

Очередная подборка из названий, про которые и так все знают

Причем статья с заголовком типа «Рейтинг JS библиотке и фреймворков» залетает несколько раз в месяц. Походу это закончится, пока каждый не напишет свой личный обзор и своё мнение.
А ещё лучще, когда эта статья — перевод.
Как по мне, то у ангуляра куда выше порог входа для разработчика. Писать логику на форке html несколько непривычно, а еще и самому этот форк развивать… а реакт-уэй предлагает, если не влаваться в детали, старый добрый сбор html в коде.

Неправда. Смена мышления на однонаправленный поток данных занимает время. В Ангуляре же все достаточно стандартно для шаблонизатора

Какой однонаправленный поток? Разве он является обязательным для использования React? Разве обычно он не форсится Flux/Redux?

Нет, не обязателен. Но без него можно использовать только для каких-то мелких компонентов/приложений

Я использую для среднекрупного приложения с двунаправленным потоком данных — компоненты получают стор(ы) или сразу сущности из них в свойствах и сами его(их) сущности изменяют в, грубо, хэндлерах дом-событий. Инфраструктура обеспечивает реактивный ререндеринг всех компонентов, которых изменение коснулось.
> Пример разработки игры на Angular2.
Это был эксперимент (хоть и закончился он относительно успешно), который показал, что как-раз для игр лучше использовать другой инструмент.

По поводу Метеора — сейчас это скорее бекэнд платформа с поддержкой реакта, ангуляра и blaze, который уже подотмирает.Основная фишка метеора сейчас это Apollo — реализация фейсбуковского GraphQL.
Для метеора также есть поддержка Vue.

UFO just landed and posted this here
Инетересно узнать мнение людей, которые уже имели дело со многими фреймворками. Допустим если я хочу писать бэкэнд не на javascript, но фронтенд чтобы был написан на одном из подобных фреймворков или библиотек. Я так понимаю тогда взамидействие идет через API сайта а шаблонная система сайта меняется на вид шаблонов используемого js фреймворка (либо может есть другие способы взаимодействия js фреймворков с сайтом, не заменяющие шаблоны к примеру?). Также хотелось бы, чтобы осталась рабочей система серверного рендера шаблонов, чтобы была возможность сделать сайт рабочим для людей с отключенным javascript. То есть имея включенный js мы видим более плавное обновление контента и прочие плюшки подобных фреймворков, а при отключении js у нас остается возможность переходить по ссылкам и смотреть сайт как в старые добрые времена :) Извиняюсь за возможно глупый вопрос, но я уже кучу времени изучаю данную тему и мне до сих пор очень сложно выбрать то, что подходило бы мне.
UFO just landed and posted this here

Смотрите в сторону prerender.io, позволяющего на сервере рендерить клиентские приложения. Соответственно, писать их можно на любом фреймворке. Париться с изоморфным рендерингом не вижу смысла.

Sign up to leave a comment.

Articles