Что такое фреймворк и для чего они нужны: Фреймворки для чайников

Начинающим программистам: что такое фреймворки и библиотеки

Когда чело­век начи­на­ет про­грам­ми­ро­вать, он узна­ёт про фрейм­вор­ки и биб­лио­те­ки. Попро­бу­ем на доступ­ных при­ме­рах объ­яс­нить, что это такое и чем они полез­ны. Будем исполь­зо­вать ана­ло­гию с построй­кой дома. Это несколь­ко упро­ща­ет реаль­ное поло­же­ние вещей, зато помо­га­ет понять раз­ни­цу.

Фреймворки

Пред­ставь­те: вам нуж­но постро­ить дом. Мож­но выбрать гото­вый типо­вой про­ект и немно­го поиг­рать с пла­ни­ров­кой, пока архи­тек­тор не про­тив и вы не тро­га­е­те капи­таль­ные сте­ны. А мож­но нари­со­вать план само­му и полу­чить имен­но тот дом, кото­рый хоти­те — даже если вы хоти­те цилин­дри­че­ский дом со вхо­дом на вто­ром эта­же.

Раз­ни­ца в том, что в типо­вом про­ек­те уже всё про­ду­ма­но: опти­маль­ное рас­по­ло­же­ние ком­му­ни­ка­ций, теп­ло­изо­ля­ция стен, спо­со­бы залив­ки фун­да­мен­та, и еще мил­ли­он вещей, кото­рые со сто­ро­ны не вид­ны. Вы полу­ча­е­те тёп­лый и уют­ный дом, но в рам­ках гото­во­го про­ек­та.

Так же рабо­та­ет фрейм­ворк. Вы исполь­зу­е­те гото­вый шаб­лон и напол­ня­е­те его сво­им кодом. Вы теря­е­те в гиб­ко­сти, зато про­грам­ма рабо­та­ет ста­биль­но: всё основ­ное фрейм­ворк берёт на себя. Под капо­том фрейм­вор­ка мил­ли­он нюан­сов: напри­мер, рабо­та с фай­ло­вой систе­мой и база­ми дан­ных, обра­бот­ка оши­бок, защи­та паро­лем. 

Без фрейм­вор­ка вам нуж­но будет обо всём думать само­сто­я­тель­но. Это даёт боль­ше сво­бо­ды, но и боль­ше ответ­ствен­но­сти. Если кри­во реа­ли­зо­ва­на авто­ри­за­ция в базу дан­ных, через эту кри­виз­ну код смо­гут взло­мать. Если не напи­са­ли обра­бот­ку оши­бок, про­грам­ма может не рабо­тать. На язы­ке стро­и­тель­ства это экви­ва­лент дома без кана­ли­за­ции или когда в сте­нах не преду­смот­ре­ли дыр­ки под розет­ки.

При­ме­ры фрейм­вор­ков:

• Bootstrap — созда­ние сай­тов с адап­тив­ной вёрст­кой. Мож­но рисо­вать кра­си­вые кноп­ки, вер­стать текст во мно­го коло­нок, включать-выключать бло­ки в зави­си­мо­сти от шири­ны экра­на, делать выпа­да­ю­щие меню и мно­гое дру­гое
• Vue.js — обес­пе­чи­ва­ет еди­но­об­ра­зие ком­по­нен­тов и модуль­ный под­ход к раз­ра­бот­ке. Мож­но созда­вать соб­ствен­ные стро­и­тель­ные бло­ки для стра­ни­цы, делать шаб­ло­ны
• Angular.JS — JavaScript фрейм­ворк от Google для дина­ми­че­ских веб-приложений, похож на Vue
• django — фрейм­ворк для Python, наце­лен­ный на ско­рость: гото­вые ком­по­нен­ты для баз дан­ных, рисо­ва­ния стра­ниц, адми­нок, окон вхо­да на сайт, шаб­ло­нов и мно­же­ства дру­гих вещей
• Ruby on Rails — тоже силь­но уско­ря­ет раз­ра­бот­ку сай­тов

Вывод: фрейм­ворк даёт ста­биль­ность и удоб­ство раз­ра­бот­ки, но огра­ни­чи­ва­ет про­грам­ми­ста сво­ей архи­тек­ту­рой.

Библиотеки

Про­дол­жа­ем стро­и­тель­ную ана­ло­гию. Допу­стим, с домом вы опре­де­ли­лись, но в нём теперь нуж­но сде­лать ремонт и про­ве­сти элек­три­ку. Это мож­но сде­лать с помо­щью молот­ка, отвёрт­ки, руч­ной дре­ли и зуби­ла, а мож­но взять спе­ци­аль­ные инстру­мен­ты — бол­гар­ку, пер­фо­ра­тор и шуру­по­вёрт. Спе­цин­стру­мен­ты — это и есть биб­лио­те­ки. С ними зада­ча реша­ет­ся быст­рее, но что­бы ими поль­зо­вать­ся, нуж­но уме­ние. Если зада­ча про­стая и с ней дей­стви­тель­но мож­но спра­вить­ся толь­ко с молот­ком и отвёрт­кой — отлич­но, тогда нам не нуж­ны биб­лио­те­ки и доста­точ­но встро­ен­ных средств язы­ка про­грам­ми­ро­ва­ния.

Если рас­ши­рить при­мер, то с помо­щью спе­цин­стру­мен­та мож­но даже постро­ить дом: бето­но­ме­шал­ка вме­сто вед­ра с лопа­той, кран вме­сто руч­ной раз­груз­ки и так далее. Полу­ча­ет­ся, что напи­сать про­грам­му мож­но с помо­щью фрейм­вор­ка, а мож­но с помо­щью биб­лио­те­ки. Биб­лио­те­ка тоже сле­дит за тем, что­бы вы сде­ла­ли как мож­но мень­ше оши­бок, но нуж­но чёт­ко знать все коман­ды и пра­ви­ла. В ито­ге вы пол­но­стью кон­тро­ли­ру­е­те про­цесс, но упро­ща­е­те себе жизнь, исполь­зуя уже гото­вые биб­лио­те­ки.

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

При­ме­ры биб­лио­тек:

• TensorFlow для Python, кото­рая погру­жа­ет вас в мир иску­ствен­но­го интел­лек­та
• Almanac Converter — для про­стой рабо­ты с дата­ми и вре­ме­нем
• WebKit — попу­ляр­ней­шая биб­лио­те­ка для рабо­ты с веб-страницами
• Scribe Java — про­стая биб­лио­те­ка для авто­ри­за­ции поль­зо­ва­те­лей

Мы сами реша­ем, как и когда вызы­вать биб­лио­теч­ные функ­ции и что с ними делать. Биб­лио­те­ка — это про­сто набор зара­нее опре­де­лён­ных функ­ций, из кото­рых, как из кир­пи­чи­ков, мож­но скла­ды­вать то, что нам нуж­но. Ещё одно инте­рес­ное свой­ство: внут­ри фрейм­вор­ка мож­но исполь­зо­вать дру­гие биб­лио­те­ки. Напри­мер, если вам нужен адап­тив­ный сайт и удоб­ная рабо­та с фор­ма­ми — исполь­зуй­те Bootstrap для адап­ти­ва как фрейм­ворк и под­клю­чи­те к нему биб­лио­те­ку jQuery.

Что теперь

В одной из буду­щих ста­тей потре­ни­ру­ем­ся на биб­лио­те­ках и фрейм­вор­ках. Не пере­клю­чай­тесь и до ско­ро­го! 

О фреймворках / Блог компании Конференции Олега Бунина (Онтико) / Хабр

В сегодняшней статье поговорим о неотъемлемой составляющей большого числа современных веб-проектов — о фреймворках.

Роман Ивлиев на примере множества проектов портала banki.ru, а также заказной разработки в студии крупных проектов Онтико. Рассмотрим следующие темы и поищем ответы на вопросы:

1. Что такое фреймворк, и зачем их пишут.
2. Почему для некоторых языков их десятки, а для некоторых — единицы.
3. В чём плюсы и минусы применения.
4. Наиболее распространённые мифы.
5. Использовать или нет — примеры из жизни.
6. Как выбрать из множества доступных вариантов, на что стоит обратить внимание.

Роман Ивлиев (Банки.ру)

Я очень давно ковыряюсь в IT и прошел путь от инженера до директора за 10 с лишним лет.

Про что мне с вами сегодня хотелось поговорить?

Зачем, собственно, пишут эти замечательные фреймворки? Почему их такое бешеное количество (кто этим занимается, тот наверняка знает, что они есть практически в любом языке)? В чем плюсы-минусы их применения? О наиболее распространенных мифах и о том, на что можно и нужно обращать внимание при их выборе.

Предупрежу — рецепта не будет, потому что это тема для вечного холивара — какой язык программирования лучше. Сначала бьемся, выбираем язык программирования, потом бьемся, выбираем фреймворк, на котором программируем.

Важный дисклеймер:

Перед тем как пробовать у себя то, о чем я вам сейчас наговорю, лучше сначала попробуйте у соседа, потому что, естественно, лучше пусть у него потом что-то болит, чем у вас.

Тем не менее, зачем пишут фреймворки? Почему их десятки, а для некоторых языков даже много десятков.

Вот картинка. Кто узнал себя? Кто-то еще и чем-то самодельным пользуется — есть конторы, которые сами чего-то наделали крутого. И я признаюсь — в каждой из контор, в которых я работал, был свой фреймворк. Причем, в Банки.ру у нас есть фреймворк, который построен на базе Битрикса. Поэтому про боль я могу говорить долго. У нас есть Битрикс образца 2008-го года, который прекрасно выполняет свои задачи, в нем очень мало осталось от Битрикса, кроме имен, классов и кучи булшита, который туда напихали за долгие годы. Но тем не менее.

Про фреймворки наверняка все слышали, что это такой каркас, который так или иначе ограничит ваше приложение, некую структуру делает, т.е. решает какие-то задачи. Зачем их вообще пишут, в чем цимус?

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

Это, наверное, топ-4, почему их пишут:

На самом деле причин больше. В первую очередь люди пытаются облегчить свою разработку, т.е. усовершенствовать, ведь со временем вы начинаете накапливать какие-то там свои наработки и, когда у вас появляется большое количество функций, их имеет смысл объединять в библиотеки. Потом оказывается, что библиотеки можно объединять в еще более толстые библиотеки, накладывать на них какие-то дополнительные штуки-дрюки, фишечки-мулечки, чтобы все это классно было.

Есть еще пара моментов, почему это делают. Например, потому что «тот, что есть, он плохой». Это на моей практике такой решительный аргумент. Говоришь: «Ппочему ты взял фреймворк А, а не Б?» — «Б — плохой». «Почему?» — «Потому что». Про это тоже чуть позже поговорим.

Есть еще один момент — а кто не начинал писать свой? На моей памяти каждый разработчик… Есть еще, кто не начинал писать свой фреймворк? Есть. Это на самом деле не стыдно, и я с большим уважением отношусь к тем людям, потому что если ты уже умеешь программировать, то писать свой фреймворк — это просто трата времени. Потому что возьми тот, который уже кто-то за тебя написал, допиши его, и это будет гораздо быстрее, эффективнее, и ты решишь те же самые задачи.

Я не знаю, может это связано немного с разницей в поколениях. Но во времена, когда я только начинал всем этим безобразием заниматься, написать свою CMS и свой фреймворк — это считалось, вообще, делом чести. Т.е. если у тебя нет своей CMS — ты лох. Если у тебя нет своего фреймворка, после того, как ты написал свою CMS — ты, вообще, лох в квадрате. Более того, время спустя люди, которые со мной выросли из того поколения, сейчас занимаются примерно тем же самым – они все равно пишут свои фреймворки. Потому что чужой — плохой, потому что тот, что есть, он плохой.

Плюсы и минусы. Казалось бы, решений вагон. Давайте будем искать.

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

Посмотрим, какие плюсы, исходя из того, для чего их пишут.

Естественно, там уже решены типовые задачи. Вам не нужно думать над тем, как записать что-то в файл, вам нужно клацнуть, вызвать метод, метод сам запишет в файл, метод сам отправит http-запрос, метод сам отправит что-нибудь, метод сам вам сконфигурирует базу данных, метод сделает, вообще, кучу всего остального другого. И то же самое, что вы, в принципе, могли сесть и запрограммировать сами, за вас уже запрограммировали другие люди. Хорошо? Почему нет, хорошо.

Можно на этом фоне ускорять разработку. Потому что ты не программируешь свои, например, 10 методов, ты берешь готовые. Если есть документация, соответственно. О документации тоже поговорим.

Есть шансы, что можно сделать что-то одинаковое. Если у вас, например, есть в компании 10 проектов, то есть ненулевая вероятность того, что решая задачу в одном проекте, пользуясь фреймворком, который задал вам тот самый каркас, вы можете потом спокойно (условно спокойно) тащить эти разработки в соседний проект. При этом вы экономите время, силы, но не экономите нервы. Почему? Не потому что он плохой, а потому что люди на самом деле разные, и фреймворк — это инструмент. Если мы рассмотрим в качестве альтернативы молоток, то кто-то молотком умеет забивать гвозди, кто-то молотком умеет отбивать пальцы — казалось бы, один и тот же инструмент, но эффект прямо противоположный. С этой штукой то же самое. Человек, опытный, человек, который знает, как этим пользоваться, спокойно решает задачу. Чаще всего, не думая о том, что все остальные люди, которые потом этим будут пользоваться, могут немного отличаться по квалификации, по отношению к жизни, религии и по всем другим причинам.

И, в принципе, можно быстрее находить людей, потому что вместо того, чтобы искать, когда у тебя большое количество задач решено сторонним решением, ты можешь найти специалиста по этому решению, и жизнь твоя станет быстрее. Человек войдет в проект быстрее.

Подразумевается, наверное, что люди, которые выкладывают фреймворки (не абы какие, а вот те, которые были на картинке в начале прещзентации) — профессионалы. На той картинке были собраны одни из самых популярных фреймворков на PHP, Python, Java и JavaScript. Вещи, которые разрабатываются почти промышленно, подразумевают, что разрабатывают их профессионалы, поэтому, когда вы это решение берете в руки, вы в целом можете быть уверены, что с вероятностью почти 100% то, что там написано, оно работает.

Минусы. Что такое фреймворк? Это груда чужого кода, которая иногда документирована, иногда не очень документирована, иногда документирована не совсем корректно. И самое главное, что не всегда понятно, как это работает. Т.е. если вы берете большой толстый фреймворк, разобраться в том, как реально в нем что-то происходит, достаточно сложно. Поэтому в ситуации, когда вы упираетесь в тормоза (как любят говорить «что-то тормозит»), то чтобы понять, что тормозит внутри вот этой коробки, нужно приложить определенные усилия. Даже если вы поймете, что в этой коробке работает не так, переписать эту коробку — это тоже определенные усилия. Потому что каждый фреймворк накладывает на разработчика некий стиль программирования. Можно взять очень крутой фреймворк, и программировать на нем настолько бездарно, что результаты вашего творчества перечеркнут все, что было заложено этими замечательными людьми-профессионалами, все их идеи.

Еще минус — надо переучиваться. Даже если вы берете фреймворки в рамках одного и того же языка программирования, то они на самом деле очень сильно друг от друга отличаются. Если взять на PHP какой-нибудь Symfony, как они внутри устроены, как нужно ими пользоваться — это совершенно разные диалоги. Когда, например, в объявлении о работе пишут, что «нам нужен программист на таком-то фреймворке» — это специально пишут. Потому что, если вы пишете на другом фреймворке, то у вас уже деформированное сознание, скорее всего. У людей, в принципе, деформируется сознание, когда они долго работают с одним и тем же. Если вы, например, долго-долго программировали на Ассемблере и умеете в голове переворачивать систему исчисления из троичной в 25-тиричную, то вряд ли вы что-то простое после этого сможете сделать. Вы уже обречены делать сложное. То же самое с фреймворком — есть очень простые, очень легкие каркасные решения, которые вот так вот, на раз-два программируются, а есть реально штуки, которые даже специалистам очень сложно заставить работать нормально.

Таким образом, вы попадаете на некий крючок, связанный со всеми предыдущими минусами. Т.е. если вы в своей компании разрабатываете огромное количество чего-то, используя один из фреймворков, то шансов перейти на другой у вас практически нет. Либо у вас очень добрый бизнес, или вы стартап, который готов жертвовать ночами, 25-ый час и т.д. Потому что по-разному все. Во многих языках, даже в той же самой Java, заложена разная идеология — там разные способы обработки данных, по-разному все это подходит. В итоге, вы становитесь заложником. По сути, так же, как с языком — если вы начали писать на PHP, то вы и будете дальше писать на PHP. Либо у вас есть сервисно-ориентированная архитектура, и суть в том же самом — вы можете брать кусками и переписывать. Пожалуйста, она вас спасет. Все остальное не спасет.

Есть мифы. Связанные с тем, что в первую очередь, человеку свойственно верить в доброе и вечное. Мало кто начнет утверждать, что «Все тлен, PHP — тлен, Perl — тлен, Go — тлен, все тлен. Common Lisp — наше все! Напишем на Common Lisp свой язык, на своем языке напишем свой фреймворк, и будем пилить на нем весело и задорно, зато все будет как «я хочу», и все другие будут просто восхищаться». Тем не менее, есть частые мифы и это из жизни, на самом деле. Это те штуки, с которыми реально пришлось столкнуться лбами. Т.е. казалось бы, разрабатывают профессионалы…

Миф 1-ый — безопасность. Даже несмотря на то, что фреймворки разрабатываются профессионалами, несмотря на то, что некоторыми из них пользуются миллионы людей, тем не менее, это открытый код. Безопасность — это бич открытого софта, потому что вы официально анонсируете патчи по безопасности, иначе как про них народ узнает? Вы берете и пишете на сайте: «Вот, мы тут нашли дырку… Пожалуйста, кто не успел защититься, кто не успел обновиться, тот попал». Разработчиков сторонних — вагон, вы можете схватить чужое решение, с какого-нибудь плохого GitHub’а, на котором лежит плохой код (наверняка такой где-нибудь есть). В принципе, из-за этого изобилия вы можете спокойно попасть в ситуацию, когда вы совершенно целенаправленно своими собственными руками в свой собственный код впихиваете чей-нибудь експлойт… Безопасность — вещь важная. Многие из вас тестируют безопасность своих приложений?

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

Классный миф про инженеров. Все считают, что если у нас все стандартизованно (все же пишут на работе стандарт, регламент), то мы легко заменим инженера. Это же классно — полный рынок инженеров на Haskell, например. Полно инженеров. Открываете HeadHunter — просто толпы инженеров на Haskell мечтают поработать в вашей компании. Это классно работает при условии, что вы только-только начали. У меня 35 инженеров, и у нас есть стандарты на разработку, еще у нас популярный фреймворк, и проект у меня уже давно начат, ему 11 лет, и я хочу сказать, что время входа человека в команду без ментора, старшего, который просто так сидит и говорит, что делать, ну, месяц. С ментором — 2 недели. И плюс еще ищешь черти сколько, потому что у меня есть то, что принято называть зоопарком. Мы пишем на PHP, у меня есть Битрикс, Symfony, двух версий каждая из того, что я назвал до этого, и еще на фронте у меня есть такой же список – штук семь, я даже сейчас все и не вспомню. Тем не менее, даже если это все хорошо работает, фиг вы быстро найдете инженера. Потому что каждым инструментом можно пользоваться так, как тебе хочется — инженер А, который программирует на каком-то Java фреймворке на Spring’е, пишет вот так, инженер Б — пишет вот так. И когда эти два парня встречаются, первое, что начинает говорить второй парень: «Нет, ну так нельзя делать, давай, я сейчас все перепишу по-быстренькому», тем самым он вышибает третьего парня, который, вообще, только пришел, он молодой. Он смотрит-смотрит на этих двух людей, и говорит: «Блин, да все же работало?».

Из этого вывод: без сноровки — овнокод, и с ним, в принципе, по большому счету сделать ничего нельзя.

Все говорят о скорости разработки: «Сейчас мы быстренько возьмем фреймворк, фреймворк классный, фреймворк быстро работает, мы по-быстренькому прикрутим, завертим, и все у нас быстренько пойдет». На самом деле все это хорошо работает при условии, что вам нужно типовое решение. Если вам нужно не типовое решение, фиг вы найдете подходящий фреймворк. Например, если вам нужно тупо отправлять файлики и что-то там делать — это хорошо, а если у вас на пути встает какое-нибудь устройство, которое перестает адекватно реагировать на http, и записывать нужно уже не в одно, а в 121 место, вам все равно придется писать все самим. И тогда вы попадаете в известную историю, когда у вас есть то, что работает, вы говорите, что это работает плохо, потому что предыдущий фреймворк плохой, постепенно на базе этого фреймворка, вы начинаете строить свой.

На самом деле, я везде немного утрирую, естественно, потому что не так все плохо, фреймворками пользуются и пишут, но боль, определенно, есть. И на самом деле все это классно, когда у вас есть специалисты. Группа лиц, собранных в одном месте, работающих над одной задачей, взявших инструмент, но не умеющих им пользоваться, все равно быстро ничего сделать не смогут. Даже если они все очень круто пишут на PHP, например, или на Phyton, или на Java, или на любом замечательном языке. Если они не очень сильно разбираются в этом фреймворке, быстро у них не получится. Более того, понять, что ты разрабатываешь хорошо на том инструменте, которым ты пользуешься, можно только спустя какое-то время. Либо если у тебя уже есть какой-то специалист по этим вопросам — сходил к нему в гости. Поэтому есть комьюнити (чуть дальше про них будем говорить), и оно реально спасает.

Еще есть миф, что многие заказчики требуют конкретный фреймворк, они свято верят в то, что написанное с фреймворком будет стандартизовано, это будет все классно работать, быстро, он легко найдет людей, там все классно. Более того, под конкретные фреймворки собирают прям команды. У Бунина Олега, который организует эти конференции, есть студия по разработке высоконагруженных проектов, и очень давно у него был фреймворк на Perl. Кто-нибудь из вас программировал на Perl? Я сам программировал на Perl. И у них тоже был свой фреймворк, который был запрограммирован на Perl. Так вот, чтоб потом поддерживать это поделие, которое он отдавал людям, те люди вынуждены были искать разработчиков на Perl, потому что Perl, как известно, язык для записи, но не для чтения. Т.е. человеку прочитать то, что написал другой Perl -разработчик, достаточно сложно. В Касперском была целая здоровая система активации на этом написана, я там проработал четыре года, но так и не научился до конца читать предыдущего автора и в некоторых случаях я шел к нему и говорил: «Что это?».

Есть еще мода. Мода — это страшная вещь, которая касается не только фреймворков, но и IT в целом. Приходит человек к знакомому IT’шнику и говорит: «Слышишь, чего там сейчас на рынке, вообще, круто?» — «На рынке круто — вот это». Он говорит: «О! Хочу вот это». Занавес. Слезы, плач, печаль и т.д.

По большому счету чуваку нужно, чтобы это все реально работало, ему больше ничего не нужно. Ему нужно, чтобы это было простое решение.

Еще есть куча несвязанных вещей, которые я выделил:

Фреймворк, естественно, плохой, потому что он что-то не может из коробки. Ну, потому что вряд ли вы найдете комбайн. Кто-нибудь читал на Хабре шикарную статью про фабрику фабрик для изготовления универсальных молотков? Вот здесь примерно то же самое. Естественно, человечество хочет сделать что-то универсальное, потом оно понимает, что что-то универсальное никому не нужно. Оно начинает делать механизм для построения чего-то универсального, потом механизм для построения построения и т.д. Это замкнутый круг.

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

программирования, практически, никогда не выживает, потому что «все уже было сделано до нас, чего этим пользоваться, нафиг надо привыкать» и т.д.

Естественно, что-то не получается. Вот именно вот «так» нельзя сделать. Это вечный холивар, когда говорят: «А вот здесь нужен active directory, а он вот так вот не через activ, а через прямые SQL-запросы, вот так вот все круто, память экономят, все здорово…». Да фигня все это. Все делают одно и то же. Плюс-минус. Есть решения специализированные, есть решения вендоровские, которые заточены под какие-то конкретные решения.

И последний пункт, это реально боль.

Я вам как менеджер говорю. Это самая большая проблема, когда у вас есть сильный инженер, который давно сидит, он уже умеет очень сильно на этом всем программировать и в конечном итоге: «Все, что вы мне предлагаете, это все фигня». И объяснить ему, почему, например, его фреймворк, не его фреймворк и т.д. — это достаточно сложно, потому что реальных критериев отбора очень много, сейчас мы по ним пробежимся.

Как это все выбирать? Конкретных рецептов нет, потому что, естественно, задач бешеное количество. Тем не менее, на что имеет смысл обращать внимание.

Это, в первую очередь, на комьюнити, и на что у вас у самих, вообще, есть силы. Комьюнити — это все open source. Я сейчас не говорю про проприетарные решения, которые тоже есть. Есть коммерческие фреймворки, они стоят гозиллион денег, их поддержка стоит гозилион денег, инженеров вы под них хрен найдете. Но, тем не менее, они есть по факту. Так же, как и коммерческие CMS. Я не беру в расчет Битрикс 24, я про что-нибудь пожирнее — голландский какой-нибудь… Есть поделие, которое Касперский какое-то время внедрял, просто миллион денег стоил. C#, который сам по себе один большой жирный фреймворк. .Net и все такое. Тем не менее, насколько это решение популярно на рынке? Если в Google по названию, которое вы для себя выбрали, вы ничего не нашли, это, конечно, здорово, классный решительный шаг, но скорее всего вам это не подойдет, потому что вы не сможете найти на это документацию, вы не сможете найти людей. Вообще, это будет большая проблема.

Как давно на рынке — это важная вещь. Вы слышали, что такое хайп? Про агрессивную рекламу. Т.е. если в Google внезапно в первых строчках вылезает какое-то решение, которое на рынке не проболталось еще и года, у которого сайт сделан в виде этих продающих сайтов, которые скролишь-скролишь-скролишь — «скачать». Эти длинные. Скорее всего, это тоже какая-то фигня. Либо это кто-то из Javascript-чуваков слепил какой-то новый супер-пупер модный фреймворк, который решает все проблемы предыдущих супер-пупер модных фреймворков, которые он же написал в предыдущей конторе, когда работал. Либо это какая-то фигня.

Ваш опыт — очень важно. Если вы до этого ничего не программировали сложного, то если вы возьметесь за вот этот дрын, которым можно и копать, и гвозди забивать, и все, то, скорее всего, вы обречены на провал.

И время. Насколько вы готовы во всем этом поковыряться. Потому что, я за другие языки не скажу, но в PHP, например, есть четкая градация фреймворков (плюс-минус) по скорости ввода человека в суть процесса. И есть такой Макаров Саша, один из разработчиков Yii, который утверждает, что у Yii вход прям чуть ли не в разы быстрее, например, чем в Symfony войти. Эта штука тоже важна, потому что вам нужно врубаться, либо вам нужно уже сейчас взять и бежать-копать.

Про «бежать и копать» есть совершенно классная штука, например, если вам очень-очень быстро-быстро нужен интернет-магазин, то его можно очень-очень быстро-быстро купить готовый. И не надо, вообще, его писать. И за время, пока вы будете его раскручивать, вы напишете свой. Тем не менее, если у вас нет времени на изучение, зачем за это, вообще, браться, зачем?

Процесс разработки. Сколько лет, вообще, планируется эту штуку поддерживать? У каждого фреймворка, вообще, у любого open source софта есть как в DNS time to live, что называется, т.е. время, которое эту штуку потенциально готовы поддерживать. Кто-то анонсирует это, кто-то не анонсирует, кто-то показывает, кто-то не показывает. Где-то есть прям четкий, как у взрослых, time line, когда «30 декабря 2016-го года выпустим вот это, потом вот это и вот это». Это признак того, что продукт качественный. Если чуваки просто пилят и ничего не говорят, то, скорее всего, этот продукт не очень качественный. Но если мы возьмем топ 5-10, они все плюс-минус одинаково анонсируются, другой вопрос, что за сроками этими никто не следит.

Автоматизация, документация, стилевые библиотеки, т.е. например, где-то прикручена поддержка Bootstrap’а из коробки, где-то поддержка Bootstrap’а из коробки не прикручена. Если вам нужно что-то сделать быстро и «на коленке», то, конечно, будет прикольнее взять то, что у вас с поддержкой Bootstrap’а, потому что она тоже уже есть, не надо будет мудохаться.

Любые другие интеграции. Есть фреймворки, которым уже понаписано груда библиотек, библиотеки готовых компонент.

По большому счету, их навалом, и есть даже целые хранилища этих навалов, где можно посмотреть, там даже есть рейтинги — можно в GitHub’е посчитать звездочки. Это то, что нужно обязательно учитывать в процессе выбора. Если вы можете, например, взять фреймворк, взять три каких-то его дополнения, прикрутить простенькую мордочку и разом решить все свои проблемы — это то, что доктор прописал (с моей точки зрения). Если вы вынуждены искать ночами, гуглить так, что Google вас уже просто банит, говорит, что вы бот, и показывает вам капчу на слово «фреймворк», например, то, скорее всего, что-то не то.

Тестирование — тоже очень важный момент. Не все фреймворки одинаково подлежат тому же юнит-тестированию. Есть фреймворки, которые поддерживают его легко и замечательно, есть такие, с которыми вы будете кривляться и проще, вообще, отдельно все написать. Есть со всякими юнит-штуками — JUnit, PHPUnit и др. — уже все это завязано. Вам уже ничего делать не надо. Это все уже есть. Если тестировать код, который вы написали, сложно, т.е. если у вас, например, для того чтобы протестировать какой-то код нужно сил приложить больше, чем его написать, зачем вам такая ерунда? Что вы с ней будете делать? Если вы, конечно, не какой-нибудь там mail.ru, например, компания, в которой здоровенный отдел тестирования, который может себе позволить много тестировать. Скорее всего, в вашем отделе тестирования только вы. Даже несмотря на то, что вы не инженер по тестированию. Сейчас с учетом всех псевдокризисов и т.д. все-таки на тестировании народ экономит, как может.

Производительность и отладка. Эти все вопросы, перед тем как что-то выбрать, надо бы посмотреть. Есть бенчмарки практически по всем языкам, по всем фреймворкам, которые показывают, что, например, пирамида Python’овская работает гораздо быстрее, чем непирамида Python’овская. Если вам это важно, то, пожалуйста, смотрите, выбирайте.

Есть ли обратная совместимость? Например, что сделали с той же Yii на PHP. Они версию 1 сделали не совсем совместимой с версией 2. Отличия не принципиальные, но тем не менее, взять и просто обновить фреймворк с версии 1 до версии 2, чтобы поиметь все плюсы версии 2, фиг получится. А, например, если вы берете какой-нибудь Symfony и программируете без деприкейтед методов, которые заранее были объявлены, то вы потом просто возьмете, накатите свежую версию и получите все плюшки.

В принципе, такая же история, как с языками программирования, когда у вас язык мигрирует. Python возьмем — «двойка» с «тройкой» что-то не очень дружат. Языки разные, протоколы разные в API этих фреймворков. Сейчас, например, модно выкидывать xml, везде вкидывать json. Т.е. ваше поделие было сделано с учетом того, что там xml, теперь бац — json.

Как с этим бороться? Понятно как — нужно, чтобы все было гибко, логично, слоисто и сервисно. Если вы хотите и планируете все это развивать долго и замечательно.

На конференции, как раз, был доклад про то, что нужно заранее все это строить и думать. Про то, что у вас может вот тут отвалиться, вот тут отвалиться.

Даже несмотря на то, что сейчас у нас в Банках.ру есть Битрикс этот замечательный, который работает, мы на него смотрим, хихикаем, но не трогаем, потому что он работает. И пусть работает. Все новое мы делаем рядом. По сути, можно взять любой язык, потому что мы сервисно-ориентированную архитектуру запилили, придумали свои протоколы, уже как бы решили, что мы на json останемся, больше ничего делать не будем, и тем не менее.

Еще классный критерий — есть ли что-то работающее на рынке с использованием этого фреймворка? Более-менее серьезное, не какой-то там чатик клана какого-нибудь в world of tanks, а что-нибудь более навороченное, какой-нибудь солидный магазин запчастей и т.п. Скорее всего, если люди эту штуку используют, то почему нет?

Более того, современные социальные сети позволяют найти человека и спросить: «Слышишь, как у вас там, вообще, дела обстоят?». Они, скорее всего, всю правду честно расскажут.

Я, например, не стесняюсь никаких «косяков» наших, и если кто-то придет и спросит, как мы решили вопрос перехода с Yii 1-го, на Yii 2-ой, я скажу, что мы отказались от Yii и перешли на Symfony. Потому что у меня есть пара сильных инженеров, которые убедили меня, что возможности, которые предоставляет Symfony (это один из PHP-фреймворков), нам более подходят, чем те, которые у нас есть. Мы очень долго с ним бодались. Вообще, вопрос появления фреймворков — это совершенно отдельная штука. Они у нас появились случайно. Заказали на out source проект и забыли спросить, на чем они его «запилят», а когда они его уже «запилили», оказалось, что они его «запилили» не на том, на чем у нас все остальное было «запилено». Но не выкидывать же, поэтому оставили. Так появился еще один фреймворк.

Критериев, на самом деле, может быть до фига. Т.е. вам нужно удобство работы с данными — обращайте на это внимание. Можно почитать, народ пишет в интернетах кучу всякого. Правда, очень много ерунды написано, поэтому лучше сравнивать несколько ресурсов.

Самое главное, что ваш критерий будет основным. То, что нужно вам. Если вам, например, вообще все не уперлось, а нужно очень быстро, очень скоро, то нужно что-нибудь со словом «react», наверное, взять и наплевать на то, что у вас нет каких-нибудь функций — вы их как-нибудь допишете.

В заключение про камушки, которые собираются.

Это как в языках программирования. Перед тем, как выбирать что-то, перед тем, как спорить, ругаться и т.д., просто садитесь и, как уважаемый коллега из Акрониса, проводите сравнительный анализ фреймворков.

Делается это по старинке — рисуется табличка, в табличке указываются критерии, которые вам нужны. Критериев может быть n, где n лучше бы было побольше.

Если у вас есть время, пусть это n будет 20, например. Сначала нужно будет посидеть, покряхтеть придумать эти 20 критериев, тем не менее, когда вы их придумаете и потом аккуратно это все отсмотрите, я вас уверяю, решение окупится, и потраченное время вам тоже окупится.

Возможность следить за обновлениями. Если уж все-таки случилось чудо, вы что-то выбрали и решили не переходить пока никуда, то лучше бы смотреть за тем, что происходит с этим поделием, потому что в ряде случаев о прекращении поддержки вы можете узнать последним. А что означает прекращение поддержки?

Прекращение поддержки чаще всего означает то, что ПО перестали патчить по безопасности. Потому что уже никто этим не занимается, всем надоело, они «забили» на это и все. То, что уже произошло с Windows XP. Вот, пожалуйста, операционная система, которая сейчас де факто работает в огромном количестве банковских структур и т.д. Я это знаю, потому что к нам люди ходят с Internet Explorer 8. IE 8 умер с сервис паком 2. И это та причина, почему мы еще хоть как-то пытаемся его поддержать, потому что он есть во многих банках. XP, кстати, был сертифицирован вместе с NT ФСБ-шниками. Вот, пожалуйста, люди жили-не тужили, никого не трогали. А тут бац — и все. Т.е. любая уязвимость XP, которая сейчас найдется, может только энтузиастами какими-то исправиться. А скорее всего, будет дырень.

Поэтому нужна стратегия. Стратегия выбора фреймворка на самом деле вот такая:

За все эти годы, сколько я кривлялся со всеми этими выборами, ничего более умного в голову не приходит.

Садишься, понимаешь свою задачку. Понимаешь, чего ты реально можешь — у тебя есть два-три-четыре инженера, которые умеют программировать.

Я вам сейчас расскажу, как мы шли к Symfony. Мы начали собирать инженеров, которые умеют программировать на Symfony. У меня сначала он был один случайно, так получилось, он не ушел. Потом их стало два, три, сейчас их стало целых пять, когда их стало пять, стало понято, что эти пять могут научить остальные 15. Когда он был один, он не мог этому научить. Сейчас мы почувствовали себя спокойно, мы попали в ситуацию, которую я показывал на одном из слайдов — мы оценили свои возможности, поняли, что да, мы можем. Мы провели этот самый сравнительный анализ, мы запустили пару пилотов.

Это тоже, кстати, классная тема — вы можете попилотить, посмотреть, погонять свои собственные бенчмарковые тесты. Берете какой-нибудь AB от Apache — самый простой апачевый бенчмарк, строите примитивное приложение из каркаса, прямо из коробки, в одну консольную командочку все это делаете, кладете на одинаковую виртуалочку, и все в вашей жизни становится хорошо.

Перспективы проекта — тоже очень важная вещь. Если вы сейчас не знаете, что с ним будет, но вам уже нужно получать profit сейчас, ну их на фиг эти фреймворки. Вы лучше сразу придумайте архитектуру, как бы вы хотели, чтоб она выглядела, а потом купите Битрикс 24 облако и все там уже запрограммируйте по-быстренькому мышкой.

Но помните, что каждый инструмент должен быть под свою задачу. Если вы начинаете решать свою задачу совершенно не тем инструментом, то, скорее всего, вы обделаетесь. И перед собой, и перед руководством. И произойдет та самая деформация сознания, про которую я говорил, только в другую сторону — вы разуверуете, вообще, в силу этих фреймворков, а на самом деле сила есть.

Там еще есть profit — важный пункт, до него нужно дойти, т.е. по кругу вот так вот ездить.

Важный момент — если говорить про нагрузку, то фреймворк — это все-таки сложная штука. Сама по себе она, конечно, удобная, гибкая, она решает свои вопросы, но если ваш проект начинает нагружаться, скорее всего, вам придется от этого всего отказываться. Скорее всего. Возможно, нет, но скорее всего, да. Потому что только на прогрев этого фреймворка у вас будет тратиться память и все такое, все эти микросервисы, про которые тоже на конференции рассказывали…

В ряде случаев это работает. Как у нас — у нас не очень большая нагрузка, хотя на самом деле, около 500 тысяч уникальных посетителей в сутки мы принимаем, и сервисная машина — это одна машина, это просто, физически один сервер. Он один умеет обслуживать достаточно… Еще есть Битрикс на семи серверах — сзади такой притаился, но это его сервера, он на них же и живет. А то, что новое — новое просто, чтоб понимать. Т.е. взяли, переписали технологию, получили прирост по производительности примерно раз этак в семь. Сейчас мы еще перейдем на PHP 7. Это о языках и версиях, и парни из Badoo говорят, что вообще прямо рай наступит. Ну, не знаю, мы проверим. При переходе с 5.3 на 5.6 рай почти наступил, т.е. мы процентов 30% поимели. Тут говорят, еще 60% поимеем.

Фреймворков столько, что времени не хватит их всех детально изучить. Как же выбрать? Какие критерии использовать? Что стоит изучить, а что стоит лишь просмотреть?

Мы продолжим изучение этой темы 6 сентября на вебинаре Романа. Прослушав этот вебинар вы сможете лучше сориентироваться в мире хайлоад-разработки, выбрать направления и последовательность развития себя, как специалиста, подготовить нужный и наиболее эффективный список мероприятий для саморазвития.

Фреймворки — больше минусов чем плюсов / Хабр

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

Сразу оговорюсь, что с автором я полностью согласен и всего лишь хотел бы добавить свои «три копейки». Сначала думал сделать это прямо в комментах под статьей, но быстро понял, что «копейки» получаются довольно объемные. Так и родился этот текст.

Сначала немного о себе

Веб разработкой я занимаюсь года так эдак с 98-го. Работал и на компании и фрилансером. Сам набирал команды. Как в реале так и в сети. Первым языком программирования был ныне благополучно почивший perl и о его безвременной кончине жалею до сих пор. Потом пришел php. Еще чуть позже ruby и началась эра фейерверков.

Большие обещания маленькие достижения

Встретил я ее с энтузиазмом. Действительно — вроде бы появился инструмент призванный существенно облегчить разработку, способный избавить от большого количества рутины. Однако энтузиазм быстро улетучился. И вот почему.

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

И это раз… и это два…

Эраст Фандорин

Моя первая претензия и к RoR, и Yii, и Symfony, и почти всем иным, с которыми пришлось познакомиться — их монстрообразность и тонны совершенно лишнего кода, который неизменно оказывается в проекте. Привыкнув за много лет работы, что код должен быть максимально чистым и лаконичным, что приложение должно быть как можно более быстрым, я в не мог согласится с тем мусором (уж извините по-другому сказать не могу), что оказывался в проектах.

Вторая претензия — попытка всех без исключения авторов фейерверков изобрести, что-то вроде своего языка программирования. Поясню о чем это я. Возьмем к примеру самую распространенную js библиотеку jQuery. При этом сразу оговорюсь, что именно ее я считаю чуть ли не единственно полезной, грамотной и еще много-много лестных эпитетов, среди подобных. Привожу jq в качестве примера только потому, что наверняка всем будет понятно о чем я. И так получить доступ к элементу по ID на нативном js можно так document.getElementById(«id»), а на jQuery так $(«#id»). То что при этом было написано на десяток символов меньше, меня не сильно впечатляет. При этом jq имеет кучу других плюсов ради которых я готов освоить новый синтаксис. Кроме того она надежна и практически никогда не конфликтует с другими библиотеками. Чего не скажешь и куче ей подобных, которые прочат на замену.

Еще раз оговорюсь — я ни в коем случае не против учить что-то новое. Но только если это новое делает мой код лучше чище и быстрее. Если же мне нужно выучить что-то ради того что бы я потом как обезьянка мог клепать однотипные сайты и ни смел сделать шаг влево шаг вправо потому что просто не знал как — увольте.

Да самое плохое, что подобный подход к программирование просто отучает думать и когда этот новый супер крутой фреймворкер дает сбой, а это, поверьте случается сразу же как только клиент попросит от вас что-то хоть чуть выходящее за рамки, горе фреймворкер (недавно узнал, что есть теперь такая профессия) впадает в ступор и начинает задавать глупые вопросы на все доступных ему форумах. Закачивается же все тем, что кто-то из программистов (не фреймворкер) лепит для него костыль и дай Бог, чтобы заказчик не провел аудит кода.

И это три…

Он же

Все выше сказанное касается не только front, но и back. Как следствие возникает вопрос — в самом начале я признал, что в ходе любой разработки приходится выполнять множество ненужных телодвижений, которые хотелось бы оптимизировать, но можно ли это делать такой ценой? А кроме того есть еще один момент, который в большей части касается разработки на Ruby.

Для реализации самых элементарных функций web приложения вам необходимо подключать отдельные gem-ы. Чтобы подкормиться к базе — mysql2, чтобы отправить mail — mail или созданный на его основе poni. И так далее и тому подобное. На первый взгляд ничего страшного в этом нет — все gem-ы в Ruby, как правило, хорошо оттестированы и проблем с ними не возникает. Но из этого правила тоже есть исключения. Например один раз целую неделю пришлось просидеть с odf-report, который никак не хотел корректно работать, а потом плюнуть и написать свой класс. Кроме того несколько напрягает, что с подключением каждого gem-a неизбежно возрастает время формирования страницы. На некоторых gem-aх совсем незначительно. А не некоторых…. Попробуйте поэкспериментировать на эту тему с уже упомянутым pony — сами убедитесь.

Извечный вопрос

И что же делать? C одной стороны разработка на «чистом» языке — однозначно не вариант, а с другой и существующие инструменты не устраивают по целому ряду причин? Выход видится в создании инструмента, который бы оптимизировал наиболее часто используемые функции и одновременно не стеснял программиста, и не навязывал ему стиль программирования который автор этого инструмента считает единственно правильным. На практике, это означает, что инструмент должен:

1. содержать минимальный набор стандартных, максимально оптимизированных функций
2. инструмент не должен заставлять программиста изучать что-то вроде нового «недоязыка» программирования полностью отключающего мозг
3. и все это, в идеале, должно быть оформлено в легкую библиотеку, не пытающуюся тягаться по объему кода с операционной системой.

Может я не прав, но пока, что в обратном меня переубедить ни кто не смог. Готов выслушать любые мнения.

Что такое фреймворк? Какие фреймворки самые популярные?

Фреймворк — база программной платформы, каркас, на котором удобно строить решение конкретной задачи. Слово — производное от английских frame и work, «рамка» и «работа». Это неологизм, который носители языка переводят как «остов» или «структура».

Фреймворк определяет архитектуру сайта, приложения или программного продукта. Логика его использования простая: вы выбираете каркас, отталкиваясь от сферы применения и особенностей конечного решения, а после этого заполняете его конкретными модулями и функциями.

Преимущества использования фреймворков

• Фреймворки удобны, потому что они обеспечивают высокую скорость и гибкость разработки. Вам не нужно создавать с нуля движок сайта или приложения. Бывает, что вручную практически писать не нужно — только навешивай готовые модули на каркас, настраивай их и интегрируй.

• Если у заказчика изменились бизнес-требования, можно добавлять и удалять модули, расширять функциональность.

• Легко вводить в команду разработки новых людей. Если они уже работали с фреймворком на одном или на нескольких проектах, то и с решением новых задач на нем легко справятся.

• Код проекта на базе фреймворка чище. Его почти не нужно рефакторить, проще отлаживать, расширять и поддерживать.

Недостатки фреймворков

• Не все фреймворки одинаково безопасны. Большая часть имеет открытый исходный код, и в нем регулярно находят уязвимости.

• При смене фреймворка придется переучиваться. Работать в рамках одного фреймворка в целом можно, но тогда ваши возможности не слишком широки.

• Осваивать новый фреймворк чаще всего сложно. И это занимает время.

Чем фреймворк отличается от библиотеки

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

Фреймворк же — это каркас, который определяет архитектуру. Он диктует, как решение будет вести себя по умолчанию. Совмещать два фреймворка в одном продукте — дело неблагодарное.

Внутри фреймворка могут находиться самые разные библиотеки. Их функции могут быть очень далеки друг от друга: к примеру, одна работает с выводом изображений, другая — с приемом оплаты.

Наконец, при использовании фреймворка он сам вызывает классы и функции пользовательского кода. Пользовательский код может реализовывать конкретное поведение, которое встраивается в абстрактный код фреймворка. Управление он получает после вызова.

Здесь же отметим: «фреймворк» не равно «CMS» (системы управления контентом вроде WordPress, которые часто используют для создания сайтов).

Популярные фреймворки

Большая часть популярных фреймворков предназначена для создания сайтов и веб-приложений. Разделить их на группы проще всего по языкам, которые используются для разработки под конкретный фреймворк.

HTML/CSS

• Bootstrap — фреймворк с адаптивной версткой, который позволяет быстро создавать стильные сайты с отзывчивым интерфейсом. Они легко подстраиваются под различные размеры окон на разных гаджетах. Фреймворк появился в 2011 году, и сегодня для него существует множество готовых стилей, шаблонов и др.

• Semantic UI — молодой фреймворк для переносимых интерфейсов. Он активно развивается, и в сети несложно найти большое количество готовых кнопок, изображений, иконок, надписей и других элементов.

PHP

• Yii — довольно старый фреймворк, но с хорошими возможностями. У него высокая производительность, есть кэширование и полная обработка ошибок, поддерживается использование jQuery и миграция с других баз данных.

• Symfony — мощный и стабильный фреймворк,интересный для крупных проектов. Гибко настраивается, включает широкий набор функций, множество полезных компонентов для настройки форм, безопасности и создания шаблонов.

• Laravel — один из самых популярных сегодня php-фреймворков: он прост в освоении и идеален для мелких и средних проектов.

Python

• Flask — фреймворк со скромным базовым набором функций, но легко расширяемый. Его удобно использовать для небольших или специфичных проектов, а также осваивать начинающим специалистам.

• Django — самый популярный Python-фреймворк, простой и функциональный. На старте хватает знаний Python на базовом уровне. Имеет стандартную структуру, поддерживает наследование шаблонов, работает с собственной CMS Django.

• Tornado — фреймворк, который эффективно решает «проблему 10 000 соединений». Успешно справляется со множеством одновременных подключений, прост в освоении и настройке.

Что такое фреймворк

Фреймворк, будучи «каркасом» для создания и сопровождения программного проекта, облегчает задачу разработчика. Существует множество фреймворков для создания сайтов и для различных языков программирования, обладающих как плюсами, так и минусами. Хорошо известные СSS-фреймворки: Foundation и Bootstrap. Из современных PHP-фреймворков можно выделить Yii, Symfony и Laravel. Они дружелюбны не только к профессионалам, но и новичкам. Популярность и широкий функционал позволяет без особого труда найти полезную информацию по этим фреймворкам.

В наше время IT-технологии не стоят на месте, каждую минуту создаются новые сайты, приложения и разного рода программные продукты. Тысячи строк кода помогают компьютеру понять человека.

Зачастую, разработчик применяет одни и те же алгоритмы в разных проектах. И было бы не целесообразно тратить уйму времени на то, чтобы раз за разом писать одно и то же. Что же может облегчить эту задачу?

Существует множество определений термина «фреймворк». Рассмотрим некоторые из них и попытаемся найти то, что их объединяет.

Framework – это программная платформа, определяющая структуру программной системы, программное обеспечение, которое облегчает поставленную перед разработчиком задачу и объединяет разные компоненты большого программного проекта. Это такая структура, включающая в себя библиотеки кода, различное программное обеспечение, которые облегчают жизнь разработчика и способствуют объединению разных составляющих большого программного проекта. Фреймворк содержит базовые программные модули. Все специфичные компоненты реализуются разработчиком на их основе.

В переводе с английского, framework означает «каркас». Действительно, если сравнить создание программного проекта со строительством дома, то фреймворк – каркас и разработчику остается лишь навесить окна и стены.

Фреймворк предлагает разработчику уже встроенные классы:

• Для работы с базой данных
• Для создания функциональных форм
• Для описания логики и др.

Все это может использоваться в большинстве ваших проектов, при этом использование и подключение будет простым благодаря таким «каркасам».

Используя фреймворки не нужно писать с нуля десятки, а то и сотни тысяч строк, тем самым достигается большая производительность. Становится проще сопровождать проект, вносить изменения и исправлять ошибки, «склеивать» компоненты в более сложные системы. Фреймворк помогает организовать структурированную архитектуру проекта, т.е. все файлы будут находиться в порядке и на нужных местах.

Плюсы фреймворков

• Разработка на фреймворке позволяет добиться простоты сопровождаемости проекта.
• Проекты легко масштабируются и модернизируются.
• Решения на фреймворках работают гораздо быстрее.
• Решения на фреймворках превосходят самописные системы по безопасности.

Минусы фреймворков

• Многие функции реализовываются индивидуально, т.к. фреймворки содержат только базовые компоненты бизнес-логики.
• Требуется понимание бизнес-процессов.

Web-разработка и фреймворки

Одна из самых популярных областей применения фреймворков – создание сайтов, web-приложений и сервисов и это естественно. Главным преимуществом фреймворка является тот факт, что зачастую веб-сайты и приложения используют стандартизированную структуру организации компонентов. И создание такой структуры становится проще, если использовать фреймворки. Практически у любого сайта есть форма для авторизации. И каждый раз «изобретать велосипед» было бы не разумным решением.

В интернете мы можем найти огромное количество фреймворков для создания сайтов и для разных языков программирования. Одни предназначены для упрощения в разработке интерфейсов, другие помогают в написании логики программного проекта.

В пример хотелось бы привести наиболее популярные фреймворки, с которыми сможет разобраться как профессиональный разработчик, так и новичок. Практически невозможно не найти какую-либо информацию по этим фреймворкам и это их огромное преимуществом.

Одним из самых знаменитых HTML/CSS/JS-фреймворков, помогающих в разработке интерфейса сайта является Foundation, который состоит из CSS файлов и нескольких плагинов JQuery(JS-фреймворк).

Главным его конкурент — Bootstrap, на котором так же написано огромное количество проектов.

Стоит отметить основные плюсы данных фреймворков:

• Удобство
• Простота для новичков
• Популярность, а значит развитое сообщество
• Функционал

Другие фреймворки облегчают написание логики сайта и web-приложения или сервиса. Например, одними из самых популярных PHP-фреймворков являются:

• Yii : прост в освоении и использовании, высокая производительность относительно других php-фреймворков и пр. возможности.
• Symfony: мощная функциональность, развитое сообщество, большое преимущества перед другими php-фреймворками в разработке сложных проектов.
• Laravel: доступность, мощность, хороший функционал.

В заключение, стоит отметить, что каждый из описанных фреймворков имеет как сильные, так и слабые стороны. Все они обладают большими возможностями, которые реализованы по-своему. У каждого разработчика свои предпочтения, поэтому выбор будет субъективен. Прежде чем решить, какой же из них лучше, разработчику стоит самому попробовать каждый из этих фреймворков.

плюсы, минусы и особенности выбора / Блог компании RUVDS.com / Хабр

Недавно на sitepen.com вышла серия статей, посвящённая фреймворкам для разработки веб-приложений. А именно, в этих материалах исследованы платформы Angular 2+, React + Redux, Vue.js, Dojo 2, Ember и Aurelia.

Сегодня мы хотим поделиться с вами переводом статьи из этой серии, в которой, подводя итоги всех публикаций, каждый из этих фреймворков анализируют по нескольким показателям. А именно, речь пойдёт о плюсах и минусах каждого из них, о том, что может ждать их в будущем, и о том, в каких обстоятельствах стоит обратить внимание на тот или иной фреймворк.

А нужен ли фреймворк?

Было бы неправильно, прежде чем говорить о фреймворках, не попытаться ответить на вопрос, вынесенный в заголовок этого раздела. В определённых кругах веб-разработчиков идея отказа от фреймворков становится всё более популярной. В частности, речь идёт о том, что веб-платформа развилась до такой степени, что разработчику не нужно дополнительных API для того, чтобы упростить создание приложений. Единственное, что мы можем сказать по этому поводу, заключается в том, что нужен фреймворк или нет — зависит от конкретной ситуации.

Хотя отказ от фреймворков — идея вполне жизнеспособная, разработка в таком стиле не лишена недостатков. Те, кто защищают преимущества использования чистого JS, те кто свыклись со Стокгольмским синдромом веб-технологий, забывают о том, что существует множество наборов быстро развивающихся API, как минимум у трёх различных технологий, с тремя очень сильно различающимися синтаксисами. Спецификации для веб идентифицируют более 12000 API. Нижеприведённая диаграмма, которая показывает, что именно из всего этого доступно в браузерах, недвусмысленно указывает на то, что между стандартами и реальностью имеется значительный разрыв.

Спецификации и браузеры (источник — Microsoft API Catalogue)

Разработка веб-приложений без использования фреймворков — это, отчасти, согласие следовать за этими платформами и не пользоваться плодами трудов команд-разработчиков фреймворков, часто работающих в тесной связи с создателями браузеров. Фактически, разработчик, отказывающийся от фреймворков, как бы говорит о веб-технологиях: «Я смогу приручить этого дикого зверя».

Предположим, вы имеете достаточный опыт и навыки для того, чтобы действительно обойтись без фреймворков. А как насчёт остальных членов вашей команды, или того, кто придёт в проект после вас? Или, может быть, вы убеждены в том, что решения, которые вы принимаете сейчас, будут актуальны всегда? Мы видели команды, которые брались за разработку без использования фреймворков. Они через некоторое время обнаруживали, что занимаются разработкой собственного фреймворка, который им необходимо будет самостоятельно поддерживать. В таких командах растут требования к поиску новых сотрудников, так как вместо того, чтобы искать людей, которые знают некие фреймворки, им нужно найти кого-то, кто очень хорошо разбирается в API веб-платформы. Причём, сотрудникам таких проектов нужны реальные глубокие знания, иначе пользы от них не будет.

Тут следует избегать ловушки, когда кажется, что все современные компании обладают одинаковыми возможностями. Конечно, существуют организации, где инновации в использовании и применении веб-технологий повышают их рыночную жизнеспособность. Например — Google, Facebook и Netflix. К большинству компаний это не относится и они должны это принять.

Angular 2+

▍Сильные стороны

Главное преимущество Angular 2+ — это его популярность. Можно говорить о том, что с ним связано имя компании Google и это влияет на то, как его воспринимают. Angular 1 быстро стал популярным так как те, кто пришёл из других сред разработки обнаружили в нём знакомый шаблон MVC для создания одностраничных приложений. После модернизации Angular 1 и перепроектирования некоторых частей фреймворка, Angular 2+ буквально выстрелил. Впечатляет число тренингов по нему, официальных и неофициальных. На рынке имеется серьёзная потребность в Angular-разработчиках. Кроме того, это — один из немногих фреймворков, рассмотренных в этом материале, у которого имеется официальный набор богатых возможностями компонентов для создания пользовательских интерфейсов.

▍Слабые стороны и возможные сложности при внедрении

Мы полагаем, что Angular сосредоточен на создании пользовательских интерфейсов одностраничных приложений и не соответствует нуждам разработчиков более крупных проектов. Это может привести к сложности поддержки проектов, если базовые принципы, на которых они основаны, не были чётко сформулированы в самом начале их разработки. На практике разработчикам приходится прибегать к чудесами изобретательности для того, чтобы заставить приложение на Angular делать то, что не является частью фреймворка. Это, кроме того, снижает интерес разработчиков к TypeScript, на котором написан фреймворк.

▍Будущее фреймворка

Недавно вышел Angular 5 и возникает ощущение, что команда Angular хорошо укладывается в весьма плотный график релизов. Похоже, что Angular продолжит развиваться благодаря непрекращающейся поддержке Google.

Как в любой большой организации, в Google есть множество людей. Снаружи взаимодействие тех, кто занимается Angular, и тех, кто работает над реализацией веб-стандартов в браузере, выглядит гармонично. Мы полагаем, что эта гармония, на самом деле, лишь видимость, и что в реальности Angular не даёт эффективных средств применения веб-компонентов и создания прогрессивных веб-приложений. По нашему мнению, стандарты, принятые в индустрии веб-разработки, вытеснят некоторые подходы, применяемые в Angular. В результате мы можем столкнуться, в среднесрочной и долгосрочной перспективах, с воздействием стандартов на то, как будут создаваться и проектироваться Angular-приложения. Это несёт в себе определённый риск.

▍Почему стоит выбрать Angular 2+?

Если вам нужно, чтобы специалистов по фреймворку было несложно найти в необходимых количествах, и чтобы знания этих специалистов можно было использовать в других областях, или вам нужно подготовить команду к работе с фреймворком и у вас есть некоторый уровень уверенности в том, что команда сможет, в короткие сроки, перейти к продуктивной работе, вы можете остановиться на Angular 2+. Однако, учитывайте, что Angular 1 (Angular.js) серьёзно отличается от современной версии фреймворка, и приложения, а также навыки и опыт разработчиков, нельзя напрямую перенести в Angular 2+.

Если архитектура вашего веб-приложения соответствует шаблону MVC, тогда вы тоже можете рассмотреть Angular 2+.

Если вам нравится подход к дизайну Google Material UX, тогда набор компонентов Angular Material — это быстрый, простой и надёжный способ всем этим воспользоваться.

React + Redux

▍Сильные стороны

Основное преимущество React и Redux заключается в их сравнительной простоте и в том, что они направлены на решение одной задачи, на разработку интерфейсов. Если задаться целью найти нечто, что делает что-то одно, но делает это хорошо, можно сказать, что обе библиотеки отлично делают то, чего от них ждут. В то время, как для кого-то подход, связанный с использованием контейнера состояния может показаться незнакомым, большинство разработчиков могут легко разобраться в этой концепции и понять преимущества архитектуры, основанной на однонаправленном потоке данных, и то, как такой подход может упростить приложения со сложными пользовательскими интерфейсами.

▍Слабые стороны и возможные сложности при внедрении

Самые большие минусы React и Redux заключаются не в особенностях реализации того, что они умеют, а в том, чего они не могут. Для того, чтобы создать сложное веб-приложение, вам понадобится много других технологий. Как только вы отойдёте от основных функций React, Redux и пары других библиотек, вы столкнётесь с множеством мнений о «правильных инструментах», с бесчисленным количеством решений и шаблонов, которые иногда легко интегрировать в приложение, а иногда — нет.

Итак, так как React и Redux — библиотеки, которые сосредоточены на решении узкого круга специализированных задач, неопытные команды могут очень легко сделать на их основе нечто неподдерживаемое, не зная о том, что решения, которые они принимают, ведут к ухудшению производительности веб-приложений или к ошибкам. Даже опытные разработчики могут столкнуться с тем, что недостаток чёткого архитектурного планирования решения или строгих правил в начале разработки могут очень неприятно сказаться на проекте в будущем.

Легко обмануть себя мнимой экономией времени и ресурсов, которая заключается в том, что использование React и Redux во всей организации смягчит проблемы с эффективностью разработки. Без тщательно проработанных соглашений и стандартизации других библиотек и шаблонов, переход на React и Redux сродни заявлению: «Мы переходим на JavaScript для того, чтобы писать приложения и повысить эффективность работы».

▍Будущее фреймворка

Facebook и разработчики React, сравнительно недавно, начали прислушиваться к мнению сообщества. Мы полагаем, это помогло Facebook понять, что компания не может больше действовать по принципам: «Мы лучше разработчиков знаем, что им нужно», и: «Верьте в наш подход» в деле развития своих проектов. Хочется надеяться, что это движение продолжится, отразится на возможностях и на направлении развития React и связанных с ним проектов.

Рассматривая React и Redux, сложно предсказать будущее. Однако, то, что эти библиотеки узкоспециализированы, очень серьёзно увеличило их распространение, большинство шаблонов React + Redux продвигают разделённую архитектуру, которая способствует лёгкому рефакторингу и простоте применения итеративного подхода в разработке. Пару лет назад все говорили о связке React + Flux, но сообщество разработчиков быстро приняло Redux. Вероятно, и другие серьёзные изменения в моделях работы или шаблонах могут быть приняты так же легко. С этой лёгкость в восприятии нового, вероятно, мы встретимся и в будущем.

▍Почему стоит выбрать React + Redux?

Если вы находитесь в ситуации, когда вы ищете скорее хорошие библиотеки, нежели некий всеобъемлющий фреймворк, тогда, вполне возможно, связка React + Redux хорошо вам подойдёт. Кроме того, тут следует реалистично смотреть на возможности вашей команды и организации, не только на этапе первоначальной разработки, но и с учётом долгосрочной поддержки приложения.

Vue.js

▍Сильные стороны

Вероятно, главный плюс этого фреймворка заключается в возможности его постепенного внедрения. Vue отличается понятной и рациональной архитектурой, которую несложно освоить и просто применять на практике.

Существует сплочённое сообщество энтузиастов и сторонние проекты, которые делают Vue.js ещё интереснее. Кроме того, разные разработки, ориентированные на Vue, довольно просто совмещать в более сложных решения при создании новых проектов.

▍Слабые стороны и возможные сложности при внедрении

Желание как-то извернуться между идеями приложений, основанных на шаблоне MVC, и приложениях, основанных на контейнерах состояния, может запутать. Кажется, что у разработчиков фреймворка есть стремление сделать всё качественно, при этом не давая преимущества одному шаблону разработки приложений перед другим. Нам кажется, что это, как минимум, сбивает с толку тех, кто ищет в Vue.js платформу для полномасштабного веб-решения, и может привести к применению разных шаблонов, что, в итоге, усложнит поддержку приложения.

Одна из главных проблем Vue.js заключается в том, что проект зависит от одного человека. Понятно, что другие фреймворки тоже от кого-то зависят, но обычно это — организации. Вокруг Vue.js сложилось обширное сообщество, тут имеется с множеством инновационных дополнительных проектов, но разработка ядра целиком лежит на плечах единственного разработчика.

Мы полагаем, что хорошо бы увидеть в Vue.js интеграцию новых стандартов, однако сейчас мы видим в нём нечто вроде шаблона веб-компонентов, но не сами веб-компоненты, то есть, речь идёт скорее о планах внедрения новых технологий, а не о том, что уже реализовано.

▍Будущее фреймворка

Хотя Vue.js широко применяется и используется в разных проектах, сложно предсказать, что будет с фреймворком в среднесрочной перспективе. Его не поддерживают напрямую коммерческие организации, таким образом, его развитие во многом зависит от желаний и возможностей его разработчиков.

Фреймворк показал определённый уровень возможностей по адаптации и переходу к новым подходам в разработке после того, как некоторые шаблоны то становились популярными, то теряли значимость. Vue и сейчас является современным и актуальным. При этом нет признаков того, что архитектура Vue.js не сможет приспособиться к появлению чего-то такого, о чём пока ещё никто и не знает.

▍Почему стоит выбрать Vue.js?

Если у вас есть старое веб-приложение, которому нужен более надёжный и современный движок, тогда Vue.js, вполне возможно, хорошо вам подойдёт. Он отличается чёткими шаблонами, и даже если команда разработчиков не очень опытна, она сможет легко отделить правильные подходы от неправильных. Хотя у Vue нет готовой к использованию стандартной библиотеки интерфейсных элементов, существует множество сторонних фреймворков, основанных на Vue, которые могут вам подойти.

Dojo 2

▍Сильные стороны

Dojo заполняет множество пробелов, которые существуют в чём-то вроде React + Redux. Речь идёт о том, что его создатели пытаются сформировать целостную среду разработки на основе шаблона реактивных компонентов, построенных на архитектуре контейнеров состояний.
При разработке Dojo 2 учитывается то, что он существует не в «безвоздушном пространстве». Он включает в себя возможности импорта и экспорта веб-компонентов и построен с учётом существования различных сценариев использования, которые надо поддерживать, но, в то же время, даёт возможности структурированного фреймворка, отличающегося определёнными особенностями. Кроме того, в основном функционале Dojo 2 большое внимание уделено модульности компонентов платформы.

Dojo 2 даёт решения для многих типичных задач, и возможности, наличие которых важно для полномасштабных веб-приложений, которым в большинстве других фреймворков особого внимания не уделяется. В частности, тут есть система интернационализации и шаблоны для обеспечения доступности приложений. Кроме того, здесь есть поддержка тем и шаблоны, которые ориентированы на аспекты разработки, выходящие за пределы TypeScript/JavaScript, например, на работу с ресурсами вроде CSS.

Dojo 2 нацелен на предоставление структурированного окружения разработки, удобного для программиста. Благодаря использованию TypeScript и различных шаблонов, он пытается дать разработчикам нечто вроде направляющих, ведущих их по пути продуктивной работы, но при этом не сковывает тех, кто точно знает, что делает. Фреймворк ориентирован на то, чтобы сделать разработку более продуктивной и безопасной. Его цель — дать командам разработчиков возможность быстро создавать более качественные веб-приложения.

▍Слабые стороны и возможные сложности при внедрении

Проект находится в процессе разработки, тянется это уже долго, что тормозит развитие Dojo 2. Он существует среди многих других, более узконаправленных фреймворков, разработчики которых, за счёт специализации, способны быстрее выпускать новые релизы.

Проблемой может стать то, что стремление к гибкости, к взаимозаменяемости компонентов, может поставить под вопрос сам смысл существования Dojo 2, не давая каких-либо внятных причин его использовать.

▍Будущее фреймворка

Будущее Dojo 2 зависит от него самого. Его разработчики, вероятнее всего, продолжат пытаться давать чёткие шаблоны и руководящие принципы для создания масштабных веб-приложений. В ходе развития стандартов создатели Dojo 2 будут стремиться включить их в фреймворк, интегрировать их в его механизмы. Скорее всего, Dojo 2 будет стремиться к открытости и модульности, в то время как команда его разработчиков не может не понимать, что им вряд ли удастся создать универсальное решение, которое всегда сможет соответствовать нуждам любых проектов.

▍Почему стоит выбрать Dojo 2?

Если вы хотите освоить гибкую и современную реактивную архитектуру веб-приложений, и при этом хотите, чтобы к вашим услугам были продуманные стандартные пути решения проблем, тогда Dojo 2 — это хороший выбор. Вместо того, чтобы собирать всё из разных кусков и придумывать некие правила для своего проекта, вы можете сосредоточиться на разработке функционала и быть уверенным в том, что то, что получится, весьма вероятно, будет готово к продакшну. Кроме того, Dojo 2 подойдёт тем, кто высоко ценит возможности TypeScript.

Ember

▍Сильные стороны

Пожалуй, Ember.js — это наиболее строго организованный фреймворк из тех, что получили распространение. В этом — его главный плюс. При разработке проектов на Ember существуют совершенно определённые правильные способы сделать что либо, которые обычно являются единственно возможными. Ember больше похож на платформу, на некий продукт, от поставщика которого можно было бы ожидать долговременную поддержку и обслуживание. Ember.js даёт продвинутую систему управления версиями своей платформы, инструменты для перехода на новые версии, и чёткие руководства и средства по обходу устаревших API. Пожалуй, Ember имеет полное право называться зрелым фреймворком.

За годы существования Ember.js показал, что его команда может поддерживать фреймворк и своевременно интегрировать в него современные стандарты, но, в то же время, не забрасывать старые браузеры.

Ember имеет чёткую и рациональную архитектуру, подходящую для разработки сложных веб-приложений.

▍Слабые стороны и возможные сложности при внедрении

Главный минус Ember заключается в том же самом, в чём кроется его главный плюс. Речь идёт о жёсткой структуре проектов, созданных с его использованием. Хотя его сообщество открыто и дружелюбно относится к предложениям по совершенствованию Ember, при разработке проектов на этом фреймворке всегда существует правильная последовательность действий, предписанная самой архитектурой фреймворка. Отход в сторону может вылиться в проблемы.

Определённые сложности может вызывать и то, что тут нет стандартного набора элементов пользовательского интерфейса, поэтому приходится пользоваться такими наборами сторонних разработчиков. Вероятно, может показаться неудобным и то, что эти наборы нельзя назвать всеобъемлющими, недостающие компоненты придётся искать или создавать самостоятельно. Так как Ember.js не регламентирует взаимодействие с DOM, вы можете оказаться в ситуации, когда в вашем проекте имеются неоднородные компоненты, из которых построен пользовательский интерфейс, которым не очень удобно управлять.

▍Будущее фреймворка

Разработчики, вносящие основной вклад в развитие Ember, являются и участниками комитета TC39, который занимается стандартизацией JavaScript. Ember.js оказал за последние несколько лет большее воздействие на JavaScript, нежели любой другой фреймворк. По нашему мнению это продолжится и в будущем, помогая развивать возможности и шаблоны JavaScript. Кроме того, это означает хорошую поддержку будущих стандартов в Ember.js.

Вряд ли Ember.js исчезнет в обозримом будущем, хотя инновации в его экосистеме, весьма вероятно, будут исходить от других проектов, связанных с ним, вроде Glimmer, который представляет собой фреймворк для построения пользовательских интерфейсов Ember.js-приложений, основанный на TypeScript.

▍Почему стоит выбрать Ember.js?

Если вы ищете зрелый, устоявшийся фреймворк, вы не ошибётесь, выбрав Ember.js. Кроме того, так как в основе Ember лежат простые и понятные механизмы и существует множество официальных и официально одобренных тренингов, из из-за того, что он основан на жёсткой конструкции, найти разработчиков, которые могут создавать Ember-приложения, вероятно, легче, чем в случае с другими фреймворками. Кроме того, вполне реально обучить большие команды тому, как разрабатывать такие приложения и обеспечить эффективное взаимодействие в таких командах.

Если вам хочется, чтобы ваша организация была уверена в том, что выбранные ей технологии всегда будут на современном уровне, и с осторожностью относитесь к возможным изменениям в платформах, тогда Ember тоже будет хорошим выбором. Вместо того, чтобы беспокоиться о том, что ранее выбранная платформа устареет или изменится до неузнаваемости, вы сможете просто заниматься разработкой своих приложений.

Aurelia

▍Сильные стороны

В Aurelia многое сделано правильно: подход к разработке, структура фреймворка и методика создания веб-приложений. Во фреймворке применено множество замечательных технических приёмов. Это — актуальная платформа, использующая современные технологии.

▍Слабые стороны и возможные сложности при внедрении

Полагаем, основная проблема, связанная с Aurelia — это нехватка разработчиков, занимающихся основным функционалом фреймворка. Такое ощущение, что здесь имеется множество идей и концепций, которые призваны решить основные недостатки существующих фреймворков, однако всё это выглядит не вполне законченно. Aurelia как будто находится в стадии разработки, как Dojo 2, но в данном случае речь идёт о фреймворке который имеет статус готового продукта.

Большие объёмы работы над Aurelia выполняются единственным разработчиком, а значит, если он не сможет уделять проекту достаточно времени или решит что-то кардинально в нём изменить, те, кто выбрал данный фреймворк для долгосрочных проектов, могут столкнуться с проблемами.

▍Будущее фреймворка

У Aurelia есть множество возможностей. Если этот фреймворк останется верен положенным в его основу принципам, он сохранит шаблоны веб-разработки, отлаженные в Angular, но будет давать их в более стандартизированном и проработанном виде. Однако, мы не знаем, в этом ли направлении будет развиваться Aurelia.

▍Почему стоит выбрать Aurelia?

Если вам близок шаблон MVC, и вы, или ваша команда, хотите работать на качество и результат, тогда вам стоит присмотреться к Aurelia. Однако, стоит отметить, что этому фреймворку не хватает более обширного сообщества, которое способно помочь его разработке и развитию.

Итоги

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

Фреймворк — это всего лишь воплощение неких шаблонов, интегрированный набор каких-то технологий, и код, который облегчает разработку и поддержку веб-приложений. Если вы — самостоятельный разработчик, лучшее, что мы можем посоветовать — попробуйте как можно больше фреймворков, которые кажутся вам подходящими. Если вы — менеджер или архитектор, пытающийся принять решение, помните о том, что список возможностей фреймворка — это лишь одна из его характеристик, и иногда больше — не значит лучше. Задайтесь целью всеобъемлюще проанализировать фреймворк, привлеките команду разработчиков, но сначала составьте список того, что важно вам и вашей организации, в особенности — того, что выходит за пределы технических характеристик.

Уважаемые читатели! Как вы думаете, каким должен быть идеальный фреймворк для веб-приложений?

Языки программирования и фреймворки, которые вам стоит изучить

В этой статье вы найдете краткий перечень новых релизов web технологий, которые мы считаем наиболее важными.

В последние несколько лет наблюдается тенденция перемещения бизнес-логики веб-приложений из back-end в front-end, и делегирования функций back-end простым API. Это делает выбор рабочего фреймворка гораздо более важным.

Еще одним значительным достижением стал выпуск браузера Edge. Этот преемник Internet Explorer имеет обновленный интерфейс и более высокую производительность. От IE его отличает то, что он характеризуется таким же коротким периодом времени между выходом обновленных версий, что и Firefox и Chrome. Это способствует развитию сообщества JavaScript-разработчиков, так как обновления JavaScript и новые веб-стандарты становятся доступны в браузерах спустя несколько недель, а не лет.

Это наконец-то случилось! YouTube перешел на HTML5, оставив в прошлом Flash-плеер. Firefox начал по умолчанию блокировать плагины Flash. Даже мощный пакет Adobe Flash был переименован в Adobe Animate и по умолчанию экспортирует содержимое в HTML5. Это открывает новые возможности для веб-платформ:

Выпущен Python 3.5, в котором реализовано большое количество новых функций, таких как Asyncio, которая предоставляет подобный Node.js цикл событий и подсказки по типам. В целом Python 3 приобретает все большую популярность, и мы настоятельно рекомендуем его вместо старого Python 2.

PHP 7 является новой версией, которая исправляет ряд проблем и вводит новые возможности (обзор). PHP 7 примерно в два раза быстрее, чем PHP 5.6, что имеет значительное влияние на крупные современные web технологии, базы кода и CMS системы, такие как WordPress и Drupal.

Мы рекомендуем PHP The Right Way, который обновлен до версии 7. А если вам нужно еще больше скорости, попробуйте HHVM, который используется Facebook.

JavaScript также получил обновления в виде стандарта ES2015 (ранее известного, как ES6). Он открывает перед нами новые захватывающие возможности и вводит некоторые дополнения к языку. Благодаря браузерам, которые следуют политике быстрых релизов, поддержка ES2015 уже сегодня находится на довольно высоком уровне. Кроме этого есть Babel.js, который поможет адаптировать код под старые браузеры.

Node.js претерпел много изменений, включая разделение сообщества Node.js и io.js, а затем повторное объединение. На сегодняшний день мы имеем активно поддерживаемый проект с большим количеством участников и двумя версиями Node — релиз LTS (долгосрочная поддержка), который обеспечивает стабильность для долго функционирующих проектов и крупных компаний, а также релиз, который позволяет быстро добавлять новые функции JavaScript.

Swift 2 — это видение компании Apple современного языка программирования, которое упрощает разработку приложений под iOS и OS X. Swift стал программным обеспечением с открытым исходным кодом и уже был импортирован на Linux. Это означает, что теперь на нем можно разрабатывать серверное и back-end программное обеспечение.

Go 1.5 внес ряд существенных изменений в архитектуру. В 2015 году он приобрел значительную популярность и был применен в некоторых ведущих стартапах и проектах с открытым исходным кодом. Сам язык является относительно простым.

TypeScript является статически типизированным языком, который компилируется в JavaScript. Он разрабатывается Microsoft и идеально интегрируется с Visual Studio и открытым редактором Visual Studio Code. По всей видимости, он станет довольно популярным основным понятием web технологий, так как готовящийся к релизу Angular 2 написан именно на нем. Статические типы обеспечивают такие преимущества, как возможность задействовать команды и работать с большими базами кода. Так что, если хотя бы один из этих факторов для вас актуален, вы должны попробовать TypeScript.

Ради развлечения можно попробовать один из функциональных языков, таких как Haskell или Clojure. Есть также интересные языки с высокой производительностью, такие как Rust и Elixir. Если вы ищете работу программиста, изучение таких языков, как Java (который в 8-й версии получил ряд интересных функций) и C# (который благодаря Visual Studio Code и .net core теперь может запускаться на различных платформах) может стать отличным вложением вашего времени.

Изучите один или несколько из этих языков программирования: Python 3, Go, PHP 7, ES2015, Node.js, Swift, TypeScript

JavaScript является важной частью веб-разработки, поэтому мы отвели ему специальный раздел. Появились два новых стандарта — Service Workers и Web Assembly, которые определяют, как теперь будут разрабатываться веб-приложения. Также вышло несколько новых версий популярных фреймворков:

Angular.js стал JavaScript-фреймворком для предприятий и крупных компаний. Angular 2 был представлен на рассмотрение разработчикам. Angular 2 гарантированно станет основным корпоративным фреймворком для многих разработчиков. Уже сейчас вы можете прочитать краткое руководство по нему.

React выпустил новые релизы и проекты, реализовавшие его в качестве библиотеки. А также новые средства разработки.

Facebook выпустил React Native, который является основой для создания мобильных приложений для Android и IOS. Он сочетает в себе оригинальный внешний интерфейс с работой React под капотом.

Polymer 1.0 позиционируется, как стабильная и готовая к работе «из коробки». Polymer базируется на Web Components, который является стандартом для упаковки HTML, JS и CSS в отдельные виджеты, которые могут быть импортированы в веб-приложения. На данный момент Web Components поддерживается только в Chrome и Opera, но Polymer делает его доступным во всех браузерах.

Также вышла новая версия Ember.js. В ней была введена модульная система, удалены устаревшие функции и оптимизирован код. Ember исповедует написание семантически корректного кода и команда поддержки фреймворка очень осторожно вводит новые функции. Если вам нужен стабильный фреймворк для технологии разработки web приложений с простой миграцией на новые версии, вы можете попробовать Ember.

Vue.js — это новая библиотека, которая предлагает адаптивные компоненты для создания пользовательских интерфейсов. Она поддерживает связывание данных, модульные компоненты и композиции. Vue похожа на React, но она не использует виртуальный DOM и работает только в браузере. За короткое время своего существования Vue.js объединила вокруг себя очень активное сообщество. Библиотека позиционируется как инструмент для создания веб-интерфейсов.

Изучите один из этих фреймворков: Angular 2, React, Ember.js, Vue.js, Polymer, Web Components, Service Workers

Bootstrap стал еще популярнее, он понемногу превращается в стандарт веб-разработки. Версия 4 версии реализована поддержка flexbox и интеграция SASS. Авторы фреймворка обещают плавный переход с версии 3.

Foundation — это еще один frontend-фреймворк, который является альтернативой Bootstrap. В версии 6 основное внимание было уделено модульной системе, чтобы можно было включать только те фрагменты, которые вам нужны, это позволит значительно сократить время загрузки.

MDL — это официальный фреймворк Google для создания элементов дизайна веб-приложений. Он имеет аналогичную цель с другим фреймворком от Google — Polymer, но является гораздо более простым в изучении и работе с ним.

CSS-препроцессоры также продолжают совершенствоваться. Less и SASS являются наиболее популярными на данный момент, их набор функций в основном сопоставим. Тем не менее, новость о том, что Bootstrap 4 переходит на SASS, дает ему небольшое преимущество перед Less.

Кроме этого появился новый инструмент PostCSS, который также заслуживает внимания. Однако мы рекомендуем его только тем разработчикам, которые уже имеют опыт работы с препроцессорами и знают, какие технологии востребованы в web.

Изучите один или несколько из них: Bootstrap, MDL, Foundation, SASS, LESS, PostCSS

В течение последних нескольких лет в веб-разработке все больше логики приложений переносится в веб-интерфейс, а back-end рассматривается только как API. Однако до сих пор остается много классических веб-приложений с генерируемым HTML, поэтому мы считаем, что изучение классических фреймворков полного стека по-прежнему важно.

В зависимости от того, какой язык вы предпочитаете, есть несколько вариантов на выбор. Если PHP, то есть Symfony, Zend, Laravel (и Lumen, его новая более компактная альтернатива для API), Slim и другие. Если Python, то Django и Flask. Если Ruby — Rails и Sinatra. Если Java — Play и Spark. Если Node.js, то Express, Hapi и Sails.js, а если Go — Revel.

AWS Lambda был выпущен еще в 2015, но только в 2016 году его концепция была окончательно установлена и готова к производству. Это сервис, который полностью устраняет back-end серверы и является бесконечно масштабируемым. Можно определить функции, которые вызываются при определенных условиях или когда посещаются определенные адреса API. Это означает, что можно получить back-end полностью без клиент серверных технологий web.

Еще одним трендом являются генераторы статических сайтов, такие как Jekyll и Octopress. Эти инструменты используют несколько исходных файлов, таких как текст и изображения, и создают готовый сайт с предварительно сформированными HTML-страницами.

Разработчики, которые раньше создавали блоги на WordPress с базой данных и панелью администрирования, теперь предпочитают генерировать HTML-страницы и загружать только статическую версию сайта. Это дает существенные преимущества в плане повышения безопасности (нет back-end, который можно взломать, и нет базы данных, которую можно похитить) и увеличения производительности. В сочетании с CDN, такими как MaxCDN и CloudFlare, клиент может запросить страницу сайта и получить ее с ближайшего сервера, что значительно сокращает время ожидания.

Изучите один из них: back-end фреймворки полного стека, AWS Lambda, генераторы статических сайтов

Мы включили в наш обзор две наиболее популярные технологии создания web сайтов. Обе написаны на PHP и просты в установке и работе. Они используют новый быстрый PHP 7.

В последние годы WordPress стал намного больше, чем просто блог-платформой. Это полноценный CMS / фреймворк, который с помощью плагинов позволяет запустить любой сайт. На рынке представлено большое количество тем для WordPress высокого качества, и многие фрилансеры зарабатывают себе на жизнь разработкой под WordPress. С помощью таких проектов как WP-API можно использовать WordPress в качестве REST API back-end.

В прошлом году вышел Drupal 8. Он был полностью переписан, особое внимание было уделено современным технологиям разработки. Теперь Drupal использует компоненты Symfony 2, пакеты Composer и движок шаблонов Twig. Миллионы сайтов работают на Drupal, это хороший вариант для разработки тяжелых порталов.

В этом году сообщество веб-разработчиков утратило часть своего энтузиазма по поводу баз данных NoSQL, и многие вернулись к реляционным базам данных, таким как Postgres и MySQL. Заметным исключением из этой тенденции являются RethinkDB и Redis.

Postgres является популярной реляционной СУБД, команда поддержки которой пристально следит за всеми инновациями в сфере разработки и постоянно совершенствует систему, добавляя новые функции. В ближайшее время ожидается выход версии 9.5. В ней будет реализована улучшенная поддержка столбцов JSONB для хранения без схемных данных (в результате чего отпадает необходимость в наличии отдельной базы данных NoSQL) и долгожданная операция upsert, которая упрощает INSERT-или-UPDATE запросы.

MySQL является самой популярной СУБД с открытым исходным кодом, применяемой в технологии web программирования. Начиная с версии 5.7, MySQL также поддерживает столбцы JSON для хранения без схемных данных. Если вы являетесь начинающим back-end разработчиком, вы в первую очередь обратите свое внимание на базы данных MySQL, которые хостинг-провайдер предварительно настроил для вас. Возможно, они будут более старой версии, и вы не сможете поработать с JSON. Но MySQL включен в популярные пакеты, такие как XAMPP и MAMP, так что вы сможете легко начать работу с системой.

Изучите одну из этих СУБД: Redis, RethinkDB, MySQL / MariaDB, PostgreSQL

Мобильные платформы постоянно развиваются, а сами смартфоны по производительности уже могут составить конкуренцию не самым мощным компьютерам. Это хорошая новость для гибридных мобильных фреймворков, так как мобильные приложения, созданные с помощью веб-технологий, теперь могут предложить оригинальный опыт взаимодействия.

В данный момент на рынке присутствуют популярные Ionic и Meteor. Недавно вышла версия Meteor 1.4, и он теперь подходит для разработки мобильных приложений. Facebook запустил React Native, который использует компоненты React в потоках JavaScript. Они также обновили свой оригинальный интерфейс, что позволило разрабатывать во многом идентичный код как под iOS, так и под Android.

Изучите один из них: Ionic, React Native, Meteor

Вышла версия 1.0 редактора Atom. Это бесплатный и мощный редактор кода, который построен с использованием современных технологий создания web сайтов. Он содержит множество пакетов и уже успел сформировать вокруг себя большое сообщество поклонников. Он интегрируется с плагинами для рефакторинга кода и имеет множество красивых тем оформления, которые можно выбрать и настроить, написав код CoffeeScript и CSS. Facebook использовал эту функцию и запустил редактор Nuclide.

Корпорация Microsoft удивила всех, выпустив свой редактор Visual Studio Code. Это компактный IDE, который поддерживает несколько языков и работает под управлением Windows, Linux и OS X. Он поддерживает функцию проверки кода IntelliSense и интегрируется с отладчиком для ASP.Net и Node.js.

NPM, менеджер пакетов Node.js, в последнее приобрел сумасшедшую популярность и стал стандартным упаковщиком для front-end и node разработчиков. Это самый легкий способ управлять зависимостями JavaScript проекта, он очень прост в работе.

Даже для разработчиков-одиночек Git стал просто незаменим. Его без серверная модель позволяет превратить любую папку в хранилище с контролем версии, которое можно залить на Bitbucket или Github и синхронизировать с компьютером.

Изучите один из них: Atom, Visual Studio Code, NPM, Git

Данная публикация представляет собой перевод статьи «The Languages And Frameworks You Should Learn In 2016» , подготовленной дружной командой проекта Интернет-технологии.ру

телеграм канал. Подпишись, будет полезно!

Что такое фреймворки? [Определение] Типы фреймворков

Как программисту вам не нужно начинать с нуля, когда у вас есть инструменты, предназначенные для помощи в ваших проектах. Фреймворки — это программное обеспечение, которое разрабатывается и используется разработчиками для создания приложений.

Что такое фреймворки?

Поскольку они часто создаются, тестируются и оптимизируются несколькими опытными инженерами-программистами и программистами, программные среды универсальны, надежны и эффективны.

Использование программной среды для разработки приложений позволяет вам сосредоточиться на высокоуровневой функциональности приложения.Это связано с тем, что обо всех низкоуровневых функциях заботится сама структура.

Почему мы используем фреймворки?

Разработка программного обеспечения — сложный процесс. Это требует выполнения множества задач, включая кодирование, проектирование и тестирование. Что касается только части кодирования, программисты должны были позаботиться о синтаксисе, объявлениях, сборке мусора, операторах, исключениях и многом другом.

Программные среды

упрощают жизнь разработчикам, позволяя им контролировать весь процесс разработки программного обеспечения или большую его часть с единой платформы.

Преимущества использования программной среды:

• Помогает в установлении лучших практик программирования и подходящем использовании шаблонов проектирования
• Код более безопасный
• Можно избежать дублирования и дублирования кода
• Помогает согласованно разрабатывать код с меньшим количеством ошибок
• Облегчает работу со сложными технологиями
• Можно создать свой программный фреймворк или внести свой вклад в фреймворк с открытым исходным кодом. Следовательно, функциональность

постоянно совершенствуется.

• Несколько сегментов кода и функций уже созданы и протестированы.Это делает приложения более надежными
• Тестирование и отладка кода намного проще и могут выполняться даже разработчиками, не владеющими кодом
• Время, необходимое для разработки приложения, значительно сокращается

Что входит в структуру?

Когда вы устанавливаете программный фреймворк, первое, о чем вам нужно позаботиться, — это системные требования. После установки и настройки фреймворка создается структура каталогов.

Например, рис.(i) иллюстрирует структуру каталогов Laravel Framework. В каждой из этих папок могут быть дополнительные каталоги. В каталогах также могут быть файлы, классы, процедуры тестирования, шаблоны и многое другое.

рис. (i)

Разница между библиотекой и фреймворком

Кто-то может предположить, что программная среда — это набор библиотек, так же как библиотеки — это набор предварительно скомпилированных подпрограмм. Однако это неверно, поскольку не все программные среды используют библиотеки или зависят от них.

Разница между библиотекой и фреймворком в том, что последний вызывает код. Напротив, код вызывает программную библиотеку. Давайте разберемся с этим на примере:

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

Когда вы используете PHP-фреймворк, такой как Laravel, отношения меняются, и поэтому программный фреймворк вызывает код приложения, написанный в фреймворке.Технически это называется инверсией управления (IoC).

Язык программирования и фреймворки

Язык программирования сообщает компьютеру, что он должен делать. Каждый язык программирования имеет синтаксис и определенный набор правил, которые необходимо соблюдать каждый раз при написании кода.

Программная среда построена на основе языка программирования. Например,

Rails, также известный как Ruby on Rails, представляет собой веб-фреймворк, построенный на основе языка программирования Ruby.

Django и Flask — это две разные веб-среды, построенные на основе языка программирования Python. Следовательно, они также известны как фреймворки Python. React и Angular — это интерфейсные веб-фреймворки, построенные на основе языка программирования JavaScript.

Типы каркасов

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

Существует множество типов программных сред, упрощающих разработку приложений для широкого диапазона областей разработки приложений. Давайте погрузимся в некоторые программные фреймворки, которые сейчас в моде:

Фреймворки веб-приложений

1. Угловой

Angular — это основанная на машинописном тексте платформа JS с открытым исходным кодом, которая упрощает создание приложений в Интернете. Angular решает проблемы разработки приложений, сочетая декларативные шаблоны, внедрение зависимостей, сквозные инструменты и многое другое.

Angular дает разработчикам возможность создавать приложения, которые работают в Интернете, на мобильных устройствах и на компьютерах.

Популярная платформа JavaScript используется в общедоступных приложениях и на сайтах, таких как Google Cloud Platform и AdWords, а также во многих внутренних инструментах Google.

Некоторые популярные веб-сайты, разработанные с использованием AngularJS:

• Netflix
• Paypal
• Upwork
• Youtube
• Джанго

Django — это бесплатная среда веб-приложений с открытым исходным кодом, написанная на Python.Django, созданный командой опытных разработчиков, занимается веб-разработкой, чтобы разработчики могли сосредоточиться на написании приложений, не изобретая велосипед.

Крупные организации активно используют Django в своей разработке. Вот некоторые популярные веб-сайты, разработанные с использованием Django:

• Disqus
• Instagram
• Mozilla
• Pinterest

2. Laravel

Laravel — это среда веб-приложений на основе PHP с выразительным элегантным синтаксисом.Фреймворк с открытым исходным кодом и следует шаблону проектирования модель-представление-контроллер, который является надежным и простым для понимания.

Согласно Google Trends, Laravel занял позицию самого мощного фреймворка PHP, который предлагает стандартизированную платформу с множеством функций для высокопроизводительной разработки веб-приложений PHP.

Некоторые популярные веб-сайты, разработанные с использованием Laravel:

• Alison.com
• Barchart.com
• Районный кредитор
• Ходьба по миру

Рамки DataScience

1.Apache Spark

Apache Spark — это единый аналитический движок для крупномасштабной обработки данных. Вы можете быстро писать приложения на Java, Scala, Python, R и SQL с помощью Apache Spark.

Более 3000 компаний используют Apache Spark, в том числе такие ведущие игроки, как:

• Amazon
• Cisco
• Блоки данных
• Hortonworks
• Microsoft
• Оракул
• Verizon
• Visa

2. PyTorch

PyTorch — это среда машинного обучения с открытым исходным кодом, которая ускоряет процесс от исследования и создания прототипа до производственного развертывания.

Первоначально разработанный исследовательской группой Facebook по искусственному интеллекту, PyTorch может использоваться как с Python, так и с C ++. PyTorch используется для компьютерного зрения и обработки естественного языка (NLP). Некоторые популярные веб-сайты, разработанные с использованием PyTorch:

• Comcast
• Exelon
• Trifo
• Quadient

3. TensorFlow

TensorFlow — это комплексная среда с открытым исходным кодом для машинного обучения (ML). Он имеет всеобъемлющую гибкую экосистему инструментов, библиотек и ресурсов сообщества, которая позволяет исследователям погрузиться в ML, а разработчикам быстро создавать и развертывать приложения на основе ML.

Три типичных приложения для TensorFlow:

• Сверточные нейронные сети (CNN) для распознавания и обработки изображений.
• Крупномасштабные линейные модели для анализа данных и простых поведенческих прогнозов.
• Модели от последовательности к последовательности (Seq2Seq) для функций, связанных с человеческим языком.

Ознакомьтесь с этими лучшими учебниками и курсами по науке о данных.

Фреймворки мобильной разработки

1. Ионный

Ionic — это бесплатный набор инструментов мобильного пользовательского интерфейса с открытым исходным кодом для разработки высококачественных кроссплатформенных нативных приложений для Android, iOS и Интернета — все из единой базы кода.

Ionic — это платформа разработки для всего жизненного цикла приложения, которая позволяет командам создавать более качественные и быстрые приложения. Вот некоторые из популярных приложений, разработанных с использованием Ionic:

• MarketWatch
• McDonald’s Türkiye
• Pacifica

3. Xamarin

Xamarin — это бесплатная платформа разработки приложений с открытым исходным кодом для создания приложений Android, iOS с помощью .NET и C #. Xamarin является частью платформы .NET, в которой активно участвует более 60 000 участников из более чем 3700 компаний.

Вот некоторые из популярных приложений, разработанных с использованием Xamarin:

• Заявки клиентов авиакомпании Alaska Airlines
• CA Mobile для мобильного банкинга
• Novarum DX, медицинское приложение

4. Флаттер

Flutter — это набор инструментов пользовательского интерфейса Google для создания красивых, скомпилированных в исходном коде приложений для мобильных устройств, Интернета и настольных компьютеров на основе единой базы кода. Он имеет выразительный и гибкий пользовательский интерфейс и обеспечивает высокую производительность на платформах iOS и Android.

Вот некоторые из популярных приложений, разработанных с использованием Flutter:

• Alibaba (электронная торговля)
• Криптография
• Google Реклама (утилита)

Совет перед началом работы с программными фреймворками

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

Если вы еще не являетесь опытным программистом, важно понимать код, на котором работает фреймворк. Эти знания упростят вам задачу, когда вы столкнетесь со сложными проблемами, и сделают вас опытным разработчиком в целом.

Многие фронтенд-разработчики вносят свой вклад в платформы с открытым исходным кодом для поддержки всего сообщества разработчиков. Например, разработчики в Google создают AngularJS и Polymer, которые бесплатно доступны всем интерфейсным разработчикам.

Многие разработчики поддерживают интерфейсное сообщество, также внося свой вклад в библиотеки с открытым исходным кодом.

Заключение

Итоговое предложение для программистов, которые хотят использовать программные среды для разработки приложений, — это изучить новую структуру или язык программирования, исходя из потребности в приложениях, которые должны быть разработаны.

Кроме того, проанализируйте такие области, как интерфейсная часть, серверная часть, управление облаком и мобильные технологии, потенциальную долю рынка технологии, устойчивость и многое другое, и разберитесь в функциях технологии, прежде чем принять решение о регистрации в ней.

.

Что такое фреймворк? | Upwork

Понимание библиотек и фреймворков с открытым исходным кодом

Фреймворки похожи на реактивные пакеты для языков разработки: они повышают производительность, расширяют возможности и предлагают библиотеки ярлыков кодирования, чтобы разработчики не создавали вручную веб-приложения с нуля . Фреймворки — это не просто связанные фрагменты кода; они предлагают такие функции, как модели, API-интерфейсы и другие элементы, для оптимизации разработки динамических, многофункциональных веб-приложений.И хотя одни фреймворки предлагают более жесткий подход к разработке, другие допускают большую гибкость процесса — разработчики могут выбирать, исходя из потребностей проекта или своего собственного стиля работы.

Ключевые вынос : Когда вы делаете бутерброд, гораздо проще купить готовый нарезанный хлеб в магазине, чем испечь его с нуля. Фреймворки — это кусок хлеба вашего сайта, они ускоряют процесс.

Основные функции сред веб-приложений

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

Чтобы получить представление о том, насколько комплексна разработка с помощью фреймворка, они могут включать:

• Библиотеки : совместно используемые, многократно используемые фрагменты низкоуровневого кода на каждом языке, например, «жемчужины» Ruby on Rails
• API, , которые облегчают доступ к серверной части базы данных.
• Scaffolding: — метод, применяемый некоторыми фреймворками MVC, который усиливает доступ к базе данных.Это означает более мощные сайты с лучшим использованием базы данных.
• AJAX: Некоторые фреймворки JavaScript встраиваются в более крупные фреймворки, что позволяет использовать быструю технологию AJAX в функциональности сайта.
• Кэширование, , которое сокращает рабочую нагрузку на сервер
• Безопасность, через фреймворки аутентификации и авторизации
• Компиляторы, или Just-in-Time компиляторы

Типы фреймворков

Для создания большинство приложений серверной части, включая веб-службы, веб-приложения и программное обеспечение.

Программные рамки: Программные рамки — это многократно используемая среда, являющаяся частью более крупной программной платформы. Они специально предназначены для облегчения разработки программных приложений и включают компоненты, такие как библиотеки кода, вспомогательные программы, компиляторы, наборы инструментов и специальные API-интерфейсы, которые упрощают поток данных.

Инфраструктура веб-приложений — это программная среда, используемая для оптимизации разработки веб-приложений и веб-сайтов, веб-сервисов и веб-ресурсов.Популярным типом инфраструктуры веб-приложений является архитектура Model-View Controller (MVC) , названная так в честь способа разделения кода каждого компонента приложения на модули.

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

Python

• Фреймворк Django: универсальный фреймворк Python, предназначенный для быстрой разработки в быстро меняющихся средах, который хорошо работает с реляционными базами данных.
• Flask: Микро-фреймворк Python с минималистичным подходом, но сам по себе надежный. Он идеально подходит для автономных приложений и быстрого прототипирования.
• Pyramid: Ранее «Pylons», фреймворк, обеспечивающий большую гибкость с интеграцией NoSQL. Он отлично подходит для разработки API-интерфейсов, прототипирования и крупных веб-приложений, например систем управления контентом.
• Tornado: — событийный неблокирующий веб-сервер Python и фреймворк веб-приложений для большого объема трафика.
• Bottle: простой и легкий микро-фреймворк

Ruby

• Ruby on Rails : фреймворк Ruby, наполненный «драгоценными камнями», библиотеками кода Ruby, отлично подходит для приложений, управляемых данными
• Sinatra: Микро-фреймворк Ruby

PHP-фреймворки

• CodeIgniter: самая популярная PHP-фреймворк в стиле MVC, предназначенная для бизнеса, путешествий и покупок, с богатым набором библиотек
• Zend framework : фреймворк MVC для покупок и бизнеса
• CakePHP: второй по популярности фреймворк PHP, адаптированный для бизнеса, шоппинга и индустрии развлечений
• FuelPHP
• фреймворк Laravel: Этот фреймворк с отличной поддержкой интегрированного тестирования помогает быстро выпускать чистые приложения.
• Drupal, Joomla! : Фреймворки CMS, написанные на PHP

PERL5

• Catalyst: фреймворк веб-приложений с открытым исходным кодом на Perl
• Symfony
• Обмен: сервер веб-приложений электронной коммерции с открытым исходным кодом и платформа на Perl
• Maypole: Perl-среда веб-приложений для MVC-ориентированных приложений

JavaScript

• AngularJS: надежная среда JavaScript
• jQuery : библиотека JavaScript, на которой другие.Созданы JS-фреймворки. jQuery Mobile — альтернатива мобильному приложению.
• EmberJS: более «самоуверенный» фреймворк, чем Angular
• Node.JS : внутренняя платформа разработки JavaScript и среда выполнения для создания серверного программного обеспечения и приложений.
• Backbone.js: фреймворк в стиле MV, совместимый с Ruby on Rails
• MeteorJS: комбинация Angular и Node.js для мобильных приложений
• ExpressJS : внутренний фреймворк JavaScript, который запускается на узле.js platform
• Koa.js : новый фреймворк JavaScript промежуточного программного обеспечения, являющийся развитием ExpressJS
• ReactJS: фреймворк пользовательского интерфейса (UI) и его мобильная версия, React Native

Java

• Apache Click: компонентно-ориентированная среда веб-приложений
• Grails
• Oracle ADF: среда для корпоративных приложений
• Веб-службы Java

Язык разметки Cold Fusion

CSS

• Pure.css
• LESS & Sass: Пре-компиляторы CSS

C

C ++

C # + VB.NET

ASP.NET — это веб-приложение, разработанное Microsoft с многочисленными внешними Shoots:

• DotNetNuke: система управления контентом (CMS) на основе технологии .NET
• OpenRasta: платформа, ориентированная на платформу .NET
• MonoRail: инфраструктура веб-приложений, построенная на платформе ASP.NET

Objective-C & Swift

• Cocoa, Apple API, который состоит из трех библиотек Objective-C и Cocoa Touch, Apple UI framework для мобильных приложений iOS

Mobile Frameworks

• Bootstrap: Twitter для мобильных- первый фреймворк с комбинацией HTML, CSS, JavaScript
• Sencha Touch
• Cocoa + CocoaTouch
• jQuery Mobile + Backbone.js
• Kendo
• AngularJS + Ionic
• React Native

.

Что такое фреймворк? — CodeProject

Предисловие

Чем лучше? Более умные программисты или более безопасная среда программирования? это толчок для этой статьи. После того, как я снова встал на ноги, сказав, что .NET и MFC не являются фреймворками, Пол Уотсон задал один из двух очевидных вопросов — «что такое фреймворк?» (другой очевидный вопрос: «Если .NET и MFC не являются фреймворками, тогда что они такое?») Вопрос Пола отличный (и, я думаю, лучший из двух), и он привел меня к этому дорога в попытке положить мои деньги там, где я говорю.Итак, начнем. Я хотел бы услышать ваше мнение о том, согласны вы или не согласны с моим анализом, какие области вы хотели бы изучить более подробно и считаете ли вы, что это соответствует вашему собственному опыту. Я постарался сделать эту статью краткой (разве это не долгожданное изменение?) И оставлю ее на усмотрение читателей, чтобы определить, есть ли что-нибудь, требующее доработки.

Введение

С моей точки зрения, фреймворк выполняет несколько функций:

• упрощает работу со сложными технологиями
• объединяет несколько отдельных объектов / компонентов во что-то более полезное
• он заставляет команду (или только меня) реализовывать код таким образом, чтобы способствовать последовательному кодированию, меньшему количеству ошибок и более гибким приложениям.
• каждый может легко протестировать и отладить код, даже код, который они не писали

Если я посмотрю на этот список расплывчатых требований к платформе, я придумываю набор конкретных классификаций, которые определяют структуру:

• обертки.Обертка:
  • упрощает интерфейс с технологией
  • уменьшает / устраняет повторяющиеся задачи
  • увеличивает гибкость приложения за счет абстракции
  • часто можно использовать повторно независимо от проектных соображений высокого уровня.
• архитектуры. Архитектура:
  • управляет набором дискретных объектов
  • реализует набор конкретных элементов дизайна
• методологии: Методология:
  • обеспечивает соблюдение последовательного подхода к проектированию
  • отделяет объектные зависимости
  • часто можно использовать повторно независимо от требований приложения.

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

Фреймворк …

А обертка

Обертка — это способ переупаковки функции или набора функций (связанных или нет) для достижения одной или нескольких из следующих целей (возможно, неполных):

• Упрощение использования
• Согласованность в интерфейсе
• Расширение основных функций
• Сбор дискретных процессов в логическую ассоциацию (объект)

Легко прийти к идее, что все является оболочкой, как если бы сказать «все относительно» (что неверно, потому что это утверждение само по себе является абсолютным) , но если задуматься, не все является оберткой.Большинство MFC и .NET являются оболочками и являются основными API. Некоторые из них смехотворны, предоставляя классы, которые просто переносят сообщения во встроенные методы. Другие обертки более сложные. Например, я написал оболочку для COM-объекта Visio, которая берет на себя всю тяжелую работу по использованию примитивных функций Visio (примитивных в смысле «фундаментальных», в отличие от «плохо реализованных») для выполнения базовых вещей, таких как drop фигур, соединять фигуры и читать коллекцию фигур.

Но затем вы попадаете в реализацию, которая действительно предоставляет новые функции.Да, он использует другие объекты, другие API-интерфейсы и даже другие оболочки, но сам по себе он не является оболочкой, потому что он делает что-то совершенно новое, а не просто добавляет, вычитает или управляет коллекцией существующей работы. Оболочка изменяет существующее поведение. Там много кода, который создает новое поведение (таким образом, подпадая под действие

Архитектура

Архитектура — это стиль, включающий определенные элементы дизайна. Очевидно, у фреймворка должен быть дизайн.Его архитектура отделена от набора реализуемых оболочек и от применения конкретной методологии реализации. Классы просмотра документов MFC — это архитектура. По сути, архитектура реализует ассоциации между объектами — наследование, контейнер, прокси, коллекция и т. Д. Архитектуры имеют интересный атрибут, который, если они вам не нравятся, обычно можно игнорировать или заменять (по крайней мере, в начале проект). Архитектуры могут быть полезны и полезны, потому что они создают повторно используемую структуру (набор объектов), которая обеспечивает некоторые расширенные функции, но как только вы начнете их использовать, вы в значительной степени застрянете с ними, если не проведете серьезный рефакторинг.

Методология

Давайте посмотрим на это слово:

• Метод — способ что-то сделать
• -ология — «научным» способом — разработанная, последовательная, воспроизводимая, проверяемая, проверенная

или, если вы хотите найти ее в словаре: Свод практик, процедур и правил, используемых тем, кто работает в дисциплине.

Хорошо, мы все работали с методологиями проектирования, но не так много людей работали с фреймворком, реализующим определенную методологию.Я не думаю, что утверждение, что MFC — это методология (с исключениями), — это правильный способ думать о классах. В то время как класс определяет видимость, интерфейс и использование наследования, и их, наряду с синтаксисом языка, безусловно, можно классифицировать как «совокупность практик, процедур и правил», говоря, что класс или набор классов является методологией. как сказать, что пучок листьев образует дерево. Методология заполняет поддерживающую структуру. Реализация отображения сообщений MFC — это методология? В основном да.Хотя я рассматриваю его в первую очередь как архитектуру, которая обертывает базовый API, и вам не нужно использовать его, если вы этого не хотите, в некоторых случаях вы практически не можете избежать его использования, особенно когда вы хотите определить специализированные обработчики сообщений. Вы должны использовать метод, который реализует MFC, чтобы указать и переопределить реализацию базового класса. И поскольку это проблема всего приложения, она лучше подходит для определения методологии, чем оболочка (которая есть) или архитектура (которая есть).Итак, вещи могут быть нечеткими, и иногда может казаться, что они раскалываются, но это не умаляет ценности рассмотрения методологии как классификации.

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

Паттерны проектирования

Шаблоны проектирования — это и архитектуры, и методологии. Структурные паттерны больше напоминают архитектуру, тогда как творческие и поведенческие паттерны больше представляют собой методологии, потому что их использование требует определенного метода взаимодействия. Как бы вы ни реализовали, скажем, поведенческие шаблоны, все ваше приложение должно придерживаться этой реализации. Однако я скажу одно — шаблоны проектирования относятся к категории, которую я бы назвал «облегченными методологиями».Они не обязательно жестко относятся к тому, как компоненты и объекты взаимодействуют друг с другом.

Тяжелые каркасы

Уровень автоматизации приложений, о котором я писал (вы действительно не думали, что я напишу о фреймворках без упоминания AAL, не так ли?) — это то, что я бы назвал тяжелым фреймворком. Он строго обеспечивает (в разумных пределах возможного) управление компонентами, взаимодействие с данными, использование внешних файлов XML для определений графического интерфейса пользователя, функциональное программирование на основе сценариев и т. Д.Вы все можете сказать, что это чрезмерно, но я не могу согласиться. Подобные фреймворки нужны нам для повышения качества, согласованности и удобства использования. Более того, тяжеловесная структура может (и это доказано) позволяет даже начинающим программистам быть продуктивными в крупномасштабных разработках с минимальным руководством. Почему? Потому что фреймворк не дает много места для того, чтобы облажаться. Даже как опытному программисту это помогает мне и от ошибок (например, от использования ярлыков)!

Мысли о фреймворках

Скорее черно-белое, не так ли?

В какой-то момент фреймворк превращается во все три просто по необходимости.Невозможно реализовать методологию без реализации оболочек и архитектуры. Как и любой другой вид программирования, абстрактные концепции не обязательно переводятся непосредственно в конкретную реализацию, и то же самое верно для представления обертка-архитектура-методология. Но все же полезно рассмотреть эти две темы по отдельности, чтобы, когда пришло время реализации, мы могли принимать более обоснованные решения относительно целей реализуемой инфраструктуры. Например, проблема повторного использования обертки vs.Архитектура и методология отличаются, потому что фокус повторного использования отличается. Для оболочек основное внимание повторного использования уделяется процессу, тогда как для архитектуры это ассоциации между объектами, тогда как для методологии основное внимание повторного использования уделяется взаимодействиям между объектами.

Почему структура должна применять методологию?

Что ж, я хотел избежать аналогий с архитектурой и зданиями, но это кажется очень хорошим местом для одного, но я уверен, что вы сможете понять остальное, что я могу сказать! Так зачем это говорить? Ну, иногда важно изложить мысль на бумаге, чтобы она стала более конкретной (каламбур не предназначен).Если у вас есть только обертки, вашей команде (или только вам) остается создавать приложение в соответствии с их опытом (или отсутствием такового). В конце концов (если вы дойдете до конца), у вас есть набор различных стилей, подходов и решений, которые не имеют единообразия. Это сложно отлаживать, сложно поддерживать и сложно расширять. И когда вы закончите, вы почти наверняка не захотите повторять этот опыт. С другой стороны, структура, обеспечивающая применение методологии, сообщает каждому программисту, как делать важные вещи, такие как взаимодействие с другими объектами / компонентами / технологиями, как управлять данными и сохранять их, а также как избежать пересечения уровней приложения (в качестве примеров).Полученное приложение легко отлаживать, поддерживать и очень гибко.

Обзоры кода

Проверка кода

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

Модульное тестирование

Если ваша методология включает в себя модульное тестирование (и, таким образом, основу для поддержки этой методологии), проблема соответствия требованиям становится превентивной — модульные тесты в первую очередь предотвращают заболевание кода. Тем не менее, модульные тесты могут во многом напоминать новую идею использования магнитов для лечения артрита — они могут быть совершенно бесполезными. И я не собираюсь здесь писать о хороших модульных тестах — вы можете прочитать мои статьи о модульном тестировании, если вам интересно.

Гибкие методы

Хорошо, щекотливая тема с очень самоуверенными людьми во всех лагерях.Итак, я собираюсь обойти проблему и сказать только, что гибкие методы больше говорят о том, как управлять проектом, чем о том, как проектировать объекты или реализовывать реальный код. Вот почему, на мой взгляд, они не сильно помогают. Я обнаружил, что практически каждая работа, заказчик или статья требуют уникального подхода. Не существует метода «резак для печенья» для работы с клиентом, выяснения того, что нужно делать приложению, и управления процессом внедрения. Однако существует возможность значительного повторного использования того, как спроектировано каждое приложение, а также фреймворк и оболочки, которые используются для сокращения времени реализации.С другой стороны, гибкие методы действительно хороши как идеи, которые вы можете использовать для работы с клиентом или другими людьми в компании.

А как насчет творчества?

Этот аргумент (который, хотите верьте, хотите нет, я слышал много раз) не имеет для меня никакой критики. Двухлетний ребенок может проявлять творческие способности с красками и холстом, но вы не получите Мона Лизу. Опытный художник использует метод, который позволяет ему направить свои творческие силы на создание своих работ в рамках выбранного метода.Даже у Джексона Поллока был метод к своим картинам, хотя они действительно немного похожи на то, что сделал бы двухлетний ребенок. Дело в том, что хорошая методология на самом деле освобождает вас от рутинной задачи по выяснению основных вещей, поэтому вы можете применить свое творчество в улучшении дизайна пользовательского интерфейса, улучшенных функциях, более плавном взаимодействии с пользователем с помощью потоков и т. Д. В результате получается нечто эстетичное. радовать пользователя. Как программист, я могу сразу сказать вам, когда у продукта не было хорошей методологии фреймворка, потому что он неуклюжий, неуклюжий, грубый по производительности и, скорее всего, глючный (и самый большой показатель из всех — он был доставлен годом позже. чем обещал).Вы слушаете, Microsoft?

Пример: архитектура просмотра документов

Что нужно для того, чтобы архитектура представления документов стала настоящей структурой? На мой взгляд, для этого потребуется автоматическая связь между элементами управления графическим интерфейсом и документом. Программисту нужно только указать такие вопросы, как время жизни данных, элемент управления, представляющий данные, и документ (или документы!), Содержащий данные. Затем структура будет обрабатывать все проблемы с сохранением, преобразование данных между представлением данных в документе и представлением данных в представлении, и будет делать это без какого-либо кодирования.Реализация представления документа на этом уровне обертывает преобразование данных, предоставляет архитектуру для связывания данных с документами и обеспечивает соблюдение методологии, реализуя и скрывая связь между элементом управления GUI и документом.

Что говорит остальной мир?

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

Звучит как архитектура и набор оберток. ОК, 2 из 3.

Каркас приложения, в который разработчики вставляют свой код и который предоставляет большинство общих функций. — E. Gamma и др., «Шаблоны проектирования», Addison-Wesley, 1995

Что ж, теперь это радикально другое определение, и, по моему мнению, оно определенно включает идею методологии, хотя бы по той причине, что «скелет» должен определять, как разработчики подключают свой код и как они взаимодействуют с общими функциями. предоставлен «скелетом».Здесь подразумевается (но не обязательно), как код взаимодействует между собой.

Набор классов, который определяет модель взаимодействия между объектами… — Moduleco (конечно, они полностью разрушают его в дополнительных определениях)

Хорошо, это подпадает под категорию методологии, потому что она явно определяет стиль взаимодействия между объектами, но не учитывает оболочку и архитектурные аспекты.

• Обширная интегрированная библиотека классов
• Вся архитектура — это единица повторного использования
• Определяет логику управления и взаимодействия классов в архитектуре приложения.
• Снижает «собачью работу» за счет некоторой гибкости

— Software Engineering Associates, Inc

Хм.Хорошо, это включает в себя три вещи, о которых я говорю: оболочки (интегрированная библиотека классов), архитектура (вся архитектура) и методология (определяет логику управления и взаимодействия классов). Хотя, возможно, это не совсем то, что имели в виду авторы, особенно когда читали, что они думают о шаблоне проектирования, но вы никогда не узнаете.

На данный момент мы увидели:

• строительных блоков
• скелет
• модель взаимодействия
• все вышеперечисленное (вроде).

Честно говоря, я не уверен, что существует действительно хорошее определение. Но на самом деле больше всего мне нравится от авторов Design Patterns :

.

«Когда вы используете инструментарий, вы пишете основное тело приложения и вызываете код, который хотите использовать повторно. Когда вы используете фреймворк, вы повторно используете основное тело и пишете код, который он вызывает».

«В результате вы можете не только быстрее создавать приложения, но и иметь похожую структуру.Их легче поддерживать, и они кажутся более последовательными пользователям. С другой стороны, вы теряете некоторую свободу творчества, поскольку многие дизайнерские решения были приняты за вас ».

«Если приложения сложно спроектировать, а наборы инструментов сложнее, то фреймворки сложнее всего … Любое существенное изменение дизайна фреймворка значительно уменьшит его преимущества, поскольку основной вклад фреймворка в приложение — это архитектура, которую он определяет, поэтому крайне важно, чтобы структура была как можно более гибкой и расширяемой.»

Это формально не описывает идею структуры, состоящей из оболочек, архитектуры и методологии, но, безусловно, все это есть между строк. И он дает другое определение того, чем на самом деле является большинство MFC и .NET — инструментальных средств, а не фреймворков. Каков ответ на другой вопрос — что такое MFC и .NET, если не фреймворки?

Заключение

Размышляя о том, что такое фреймворк, я думаю, что в качестве вводной темы я сделал довольно хороший анализ предмета.Возможно, то, о чем я говорю, отличается от фреймворка, но, на мой взгляд, фреймворк должен быть именно таким и должен. Есть много разных идей относительно того, что такое фреймворк, так что теперь у вас есть и моя.

.

15 лучших CSS-фреймворков для разработчиков в 2020 году

Веб-разработчики тратили много времени на создание красивого CSS. Благодаря фреймворкам CSS теперь у нас есть лучший, более быстрый и эффективный способ создания адаптивных веб-сайтов и веб-приложений.

Вы все еще ищете лучший фреймворк CSS? Вы хотите знать, какой фреймворк вам следует попробовать? В этой статье мы собрали 15 лучших CSS-фреймворков 2020 года для вашего вдохновения.

Как работают фреймворки CSS?

CSS framework дает веб-разработчикам базовую структуру, которая включает сетку, интерактивные шаблоны пользовательского интерфейса, веб-типографику, всплывающие подсказки, кнопки, элементы форм, значки.Эта структура помогает веб-разработчикам быстро и эффективно приступить к разработке веб-сайта или веб-приложений.

Это означает, что разработчики могут освободиться от необходимости начинать все с нуля. CSS framework создаст для них прочную основу. Кроме того, разработчики могут повторно использовать код во всех проектах, над которыми они работают.

Зачем фронтенд-разработчику CSS-фреймворк?

У CSS-фреймворков есть свои недостатки. Так что нужно понимать, нужен он вам или нет.Вот несколько веских аргументов в пользу использования фреймворков:

• Чтобы быстрее создать веб-сайт / веб-приложение

Вы можете сэкономить время, имея прочную основу, на которую можно положиться. Фреймворки CSS предоставляют веб-разработчикам то, что они могут использовать и настраивать (при необходимости).

А для тех, у кого ограниченные навыки программирования, использование фреймворка CSS — единственный способ создать надежный продукт.

• Для проверки гипотезы проекта

Вы можете создать решение и протестировать его со своими пользователями.Гораздо быстрее и проще создать прототип или каркас с фреймворком, чем делать это с нуля.

PS ： Дизайнеры также могут создавать прототипы / каркасы, используя инструмент быстрого прототипирования.

• Вы можете найти CSS-фреймворк для своих конкретных нужд

Есть много отличных фреймворков, из которых вы можете выбрать. Иногда люди отказываются от использования CSS-фреймворка, потому что не могут найти подходящий вариант. Если вам сложно найти фреймворк для ваших конкретных нужд, вам следует проверить наш список из 15 фреймворков CSS.

Какие фреймворки CSS самые лучшие?

Здесь мы собрали 15 лучших CSS-фреймворков. Мы надеемся, что они вам понравятся, а самое главное, вы найдете лучший вариант для своих нужд.

1. Bootstrap — наиболее широко используемый бесплатный фреймворк CSS с открытым исходным кодом.

Bootstrap — один из самых популярных фреймворков CSS. Текущая версия этой платформы — Bootstrap 4, выпущенная в 2018 году. В этом выпуске были представлены многие важные функции, такие как новые цветовые схемы, новые модификаторы, новые служебные классы и т. Д.

Кроме того, версия 4 Bootstrap построена с использованием SASS, а это означает, что Bootstrap теперь поддерживается как LESS, так и SASS.

Как Bootstrap может помочь веб-разработчикам в создании служебной инфраструктуры?

1) Мощный адаптивный дизайн

Bootstrap обеспечивает адаптивный дизайн с помощью своей сеточной системы. Его легко использовать, и вы можете быстро создать адаптивную сетку, которая будет хорошо работать во всех браузерах. Ваш дизайн будет отлично смотреться на всех экранах и разрешениях.

2) Встроенные библиотеки ресурсов

Bootstrap предоставляет большие библиотеки для внешних разработчиков, например макеты веб-сайтов, шаблоны веб-сайтов, темы Bootstrap, панели администратора и огромную коллекцию компонентов пользовательского интерфейса.

Компоненты включают кнопки, формы, карточки, индикаторы выполнения, предупреждения. Это предварительно созданные компоненты, которые могут сэкономить разработчикам продукта много времени.

3) Низкая кривая обучения

Фреймворк Bootstrap хорош для начинающих веб-пользователей.Используя этот инструмент, вы можете присоединиться к области фронтенд-разработки. Есть много полезной документации и руководств, на которые вы можете положиться, когда у вас возникнут вопросы.

4) Быстрое создание прототипов

Использование готовых к использованию компонентов — один из самых быстрых способов имитации или прототипирования решения. Благодаря переменным и миксинам, адаптивной системе сеток, богатым компонентам и многим другим мощным инструментам вы можете легко создавать прототипы.

Дополнительные возможности Bootstrap ：

• Использует Flexbox
• Хорошая документация
• Включает компоненты HTML и JavaScript

2.Foundation — самый продвинутый в мире адаптивный интерфейсный фреймворк.

Foundation и Bootstrap — это широко используемые CSS-фреймворки. Но Foundation — это гораздо более сложная структура. Он очень гибкий и легко настраиваемый.

Это полезный инструмент для создания адаптивных веб-сайтов и веб-приложений, особенно для предприятий. Facebook, eBay, Mozilla, Adobe, HP, Cisco и Disney используют Foundation в своих продуктах.

Что делает Foundation отличным фреймворком CSS?

1) Создание адаптивного дизайна

Подобно Bootstrap, Foundation также является очень гибкой интерфейсной структурой, которая помогает веб-разработчикам создавать адаптивные веб-сайты, приложения и электронные письма, которые отлично смотрятся на любом устройстве.

2) Мощный фреймворк электронной почты

Помимо веб-сайтов и приложений, Foundation также можно использовать для создания великолепных адаптивных электронных писем в формате HTML. Вы можете создавать электронные письма в формате HTML с помощью Foundation для электронных писем . Нет необходимости использовать сложную разметку таблиц или другие вещи. Это отличный помощник для компаний электронного маркетинга.

3) Поддержка обучения онлайн-семинарам

Foundation может быть большим подспорьем, если вы знаете, как его использовать, но достичь в нем продвинутого уровня может быть сложно.Вот почему Zurb (компания, которая разработала Foundation) открыла онлайн-семинар по обучению и профессиональному консультированию, чтобы научить вас и вашу команду ценным навыкам. Но обучение платное.

4) Простота настройки

Foundation намного гибче, чем Bootstrap. Интерфейсный разработчик имеет полный контроль над пользовательскими интерфейсами. Однако из-за этого новичкам может быть сложно начать с Foundation.

Дополнительные возможности Foundation:

• Вертикальный макет временной шкалы
• Адаптивные HTML-шаблоны и компоненты пользовательского интерфейса
• Полезные инструменты, которые могут решить многие проблемы внешнего интерфейса

3.Pure — Облегченный фреймворк CSS

Pure — это легкий и отзывчивый фреймворк CSS, созданный Yahoo в 2014 году. Он построен с использованием Normalize.css и помогает создавать адаптивные макеты с использованием его сеток и меню. Pure по умолчанию адаптивен и, в отличие от Bootstrap, не позволяет создавать фиксированные макеты.

Дополнительные возможности Skeleton:

• Создан для мобильных устройств
• Легко освоить

4. Bulma — бесплатная CSS-структура с открытым исходным кодом на основе Flexbox

Bulma является бесплатной и открытой -source CSS framework на основе модели макета Flexbox.Это легкий, отзывчивый, чистый CSS и ориентированный на мобильные устройства.

Все эти функции сделали Bulma одним из самых популярных фреймворков CSS наряду с Bootstrap и Foundation. У Bulma более 150 000 пользователей, больше, чем у Фонда.

1) Читаемые и мемориальные имена классов

Bulma предоставляет разработчикам удобочитаемые имена классов CSS и готовые компоненты для создания мобильных интерфейсов. Распознать и запомнить имена классов CSS невероятно легко, потому что все они названы логически.

2) Чистый CSS, без JavaScript

Bulma, созданная на чистом CSS. Всякий раз, когда вы используете фреймворк, вам нужен только один файл .css, а .js не требуется. Кроме того, разработчики могут легко добавить индивидуальный вид для всех компонентов с помощью классов-модификаторов и переменных.

3) Сообщество

У Булмы большая община. Их поклонники могут общаться друг с другом, задавать вопросы и получать ответы.

4) Легко учиться

Низкая кривая обучения — еще одно преимущество Bulma.Это отличный фреймворк для новичков.

Дополнительные возможности Bulma:

5. Семантический пользовательский интерфейс — среда разработки, использующая удобный для человека HTML

Семантический пользовательский интерфейс — это адаптивная интерфейсная среда, использующая удобный для человека HTML. Вы можете создавать красивые, адаптивные макеты с более чем 3000 тематических переменных и более чем 50 компонентами пользовательского интерфейса.

Он также интегрирован со многими сторонними библиотеками, включая React, Angular, Meteor, Ember и многими другими фреймворками. Все это помогает вам организовать слой пользовательского интерфейса вместе с логикой приложения.

1) Дружественные имена классов

Наиболее значительным преимуществом семантического пользовательского интерфейса является его «удобный для человека HTML». Это означает, что вы можете писать код на естественном языке. Хотя это требует некоторого обучения, имена классов очень удобочитаемы и дружелюбны.

2) Красивые макеты

Семантический интерфейс имеет 3000+ тематических переменных, и все они столь же отзывчивы. По сравнению с Bootstrap 4 все макеты, созданные в Semantic, по умолчанию более красивы.

Дополнительные возможности Semantic UI:

• Краткий HTML

• Интуитивно понятный Javascript

6.UI kit — легкий и модульный интерфейсный фреймворк для создания быстрых и мощных веб-интерфейсов.

UI Kit — это облегченный фреймворк для проектирования CSS и веб-интерфейса, который предлагает почти все функции других фреймворков.

Вы можете создавать простые, понятные и модульные веб-интерфейсы с набором значков SVG, множеством компонентов, быстродействием, унифицированными стилями и параметрами настройки. Кроме того, вы также можете разрабатывать сложные макеты на основе Flexbox с помощью UI Kit, используя простой HTML.

Что отличает наборы пользовательского интерфейса от других фреймворков CSS?

1) Минимализм

Наборы пользовательского интерфейса могут помочь веб-разработчикам создавать понятные и современные интерфейсы.Он предлагает мощные функции, но когда дело доходит до дизайна, он становится очень чистым.

2) Полезные компоненты пользовательского интерфейса

Наборы пользовательского интерфейса содержат предварительно созданные компоненты, такие как Accordion, Alert, Drop, Iconnav, анимацию, заполнение и т. Д. Каждый компонент показывает шаблон использования, параметры и методы компонентов.

Другие особенности наборов пользовательского интерфейса:

7. Материализация CSS — современная адаптивная интерфейсная среда на основе Material Design.

Materialize CSS — это адаптивная интерфейсная среда, созданная Google в 2014 году.Это правильное решение для всех, кто хочет создавать веб-сайты или веб-приложения для Android, потому что оно поставляется с готовыми классами и компонентами. Вы можете быстро начать использовать его начальные шаблоны.

Есть две причины, по которым вы можете захотеть использовать Materialize в качестве одного из языков дизайна.

1) Вы любите материальный дизайн

Все мы знаем, что материальный дизайн является важным компонентом продуктов Google. Вот почему Materialize CSS стал одним из самых популярных языков дизайна.

Итак, если вы новичок или интересуетесь материальным дизайном, Materialise CSS — это то, что вы не должны пропустить.

2) Вы знаете, как работает Bootstrap

Materialize CSS использует формат сетки из 12 столбцов Bootstrap, поэтому вы можете быстро создавать адаптивные макеты страниц. Вы начнете работать еще быстрее, имея базовые знания о проекте Bootstrap.

Дополнительные возможности Materialise CSS:

• Мобильные меню

• Совместимость с Sass

8.Миллиграмма — минималистичный фреймворк CSS

Миллиграмм — один из самых легких фреймворков CSS, который может помочь вам создавать быстрые и чистые веб-сайты. Вес решения — 2 КБ (в сжатом виде).

Но, несмотря на небольшой размер, Milligram поставляется с полным набором инструментов веб-разработки. Разработчики также могут использовать все функции, предлагаемые спецификацией CSS3 с Milligram. Они могут добавить миллиграмму много мощности и сделать его одним из трех лучших доступных фреймворков.

Дополнительные возможности Milligram ：

• На основе сетки Flexbox

• Темы супер дизайна

9.Skeleton — мертвенно простой и отзывчивый шаблон

Skeleton — это минимально адаптивный CSS-фреймворк, который содержит всего 400 строк исходного кода. Несмотря на относительно небольшой размер, он предлагает множество опций (сетки, типографика, кнопки, формы, списки, таблицы, код и т. Д.), Которые позволяют создавать сложные веб-сайты.

Когда лучше всего использовать каркас Skeleton?

Если вы занимаетесь небольшим проектом или вам не нужно использовать все возможности более крупных фреймворков, то Skeleton — ваш лучший выбор.Skeleton содержит ограниченное количество стандартных HTML-элементов, но этого достаточно для начала.

Дополнительные возможности Skeleton:

10. Tailwind CSS — CSS-фреймворк, ориентированный на служебные программы

Tailwind CSS — это низкоуровневый CSS-фреймворк с широкими возможностями настройки. В отличие от Bootstrap, который создает пользовательские интерфейсы общего вида, Tailwind позволяет настраивать дизайн и создавать уникальный внешний вид.

Как Tailwind может помочь вам быстро создавать нестандартные конструкции?

1) Простота настройки

Tailwind написан на PostCSS и настроен на JavaScript.У вас будет полный контроль над реальным языком программирования, который может настроить внешний вид вашего пользовательского интерфейса — поиграйте с цветами, размерами границ, весами шрифтов, утилитами интервалов, точками останова, тенями и другими элементами и свойствами.

Например, если вы хотите создать кнопки с помощью Tailwind, вот как они будут выглядеть:

Pill:

Outline:

3D:

2) Utility classes

Вместо этого Из предварительно стилизованных компонентов пользовательского интерфейса Tailwind фокусируется на служебных классах, которые позволяют создавать истинное ощущение настраиваемых веб-сайтов.Такие веб-сайты передают ваш уникальный внешний вид.

Но Thildwindis будет сложно использовать, если у вас нет опыта работы с служебными классами и ничего не известно об атомарном CSS.

Дополнительные возможности Thildwind:

• Удобство для компонентов
• Поставляется с адаптивными параметрами

11. Spectre — легкий, отзывчивый и современный фреймворк CSS

Spectre.css — отличный фреймворк, который может помочь вам в этом более быстрая и расширяемая разработка с элегантно оформленными элементами, красивой типографикой и готовыми компонентами.

Кроме того, компоненты представляют собой чистый CSS, поэтому для их использования не требуется какой-либо язык JavaScript.

Дополнительные возможности Spectre:

• Макет на основе Flexbox
• Макет для мобильных устройств
• Изменен с помощью компилятора Sass и Scss

12. База — адаптивная структура CSS

База — это адаптивная структура CSS, которая имеет легкий и минимальный код. Он простой, чистый, минималистичный, но мощный. Веб-разработчики и дизайнеры могут создавать адаптивные веб-сайты и веб-приложения на его прочной основе.

Кроме того, он ориентирован на мобильные устройства и отлично работает во всех современных браузерах, включая IE 10+.

Дополнительные функции на базе:

• Построен на основе новейшего Normalize.css
• Разделение на независимые модули

13. CSS для пикника — легкая и красивая библиотека

Picnic — еще одна легкая библиотека CSS с размером менее 10 КБ (в сжатом виде). Он предоставляет вам чистые CSS и интерактивные компоненты, включая сетку, формы, вкладки, всплывающие подсказки и предупреждения.Библиотека поможет вам создать отзывчивый веб-сайт и красивые веб-приложения.

Дополнительные возможности Panic CSS:

• Написано на Sass / SCSS
• Включает переменные и классы
• Красота HTML по умолчанию

14. Горчичный пользовательский интерфейс — стартовая структура CSS

Ищу структуру CSS для начинающих? Попробуйте Mustard UI. Это легкий CSS-фреймворк с открытым исходным кодом, специально разработанный для новичков. Вы можете начать с основных строительных блоков, потому что он разделен на модули.

Он также предоставляет компоненты для создания внешнего интерфейса. Эти компоненты представляют собой сетки, кнопки, таблицы, формы и карточки на основе flexbox.

Дополнительные возможности интерфейса Mustard:

• Менее 6 КБ при сжатии с помощью gzip
• Хорошо документировано
• Использует Open Sans в качестве шрифта по умолчанию

15. Dead Simple Grid — адаптивная микросхема сетки CSS

Dead Simple Grid — полезный инструмент, содержащий всего 250 байт кода CSS и всего два класса.Его нельзя рассматривать как законченный фреймворк CSS, но он удобен, когда веб-разработчики хотят использовать систему сеток.

Он также поддерживает все основные браузеры, начиная с IE 8, обеспечивая мобильную разметку с одним столбцом для старых браузеров.

Дополнительные возможности Dead Simple Grid:

• Плавные колонны с фиксированными желобами
• Поддерживает бесконечное вложение
• Построен с прогрессивным улучшением
• Мобильные концепции в первую очередь

Больше гибких CSS-фреймворков для вас

Susy

Susy — это облегченный движок с сеточной компоновкой.Он разработан для упрощения и уточнения адаптивных макетов сетки. Вы можете использовать Susy с float, flexbox, таблицами или любым другим методом CSS.

Animate.css

Animate.css — отличный фреймворк, который позволяет добавлять CSS-анимацию. К ним относятся bounce, flash, pulse, rubberBand, shake, swing, tada, wobble, jello, heartBeat, bounceIn и т. Д. Вы можете проверить 30 интересных примеров анимации CSS для некоторого вдохновения.

Paper CSS

Paper CSS — это НЕформальный CSS-фреймворк.Он был построен с использованием LESS и развернут на одной странице index.html до того, как стать открытым исходным кодом.

NES.css

NES.css — это CSS-фреймворк в стиле NES (8-битный). Он предоставляет только компоненты, поэтому вам нужно будет определить свой собственный макет.

Tent CSS

Tent CSS — это простой и надежный CSS-фреймворк. Он предназначен для использования в качестве основы для создания веб-сайтов. Это чистый CSS, поэтому вы можете создавать веб-сайты без зависимостей от Javascript.

Simple Grid

Simple Grid — это легкая CSS-сетка с 12 столбцами, которая поможет вам быстро создавать адаптивные веб-сайты.

FQA:

1. Является ли Bootstrap хорошим фреймворком (фреймворком CSS)?

Конечно, есть. Bootstrap — это широко используемые CSS-фреймворки. Если вас интересует Bootstrap, попробуйте Bootstrap 4. Он может помочь вам создавать веб-сайты и веб-приложения даже лучше и быстрее, чем Bootstrap 3.

2. Bootstrap лучше, чем чистый CSS?

Чистый CSS и Bootstrap имеют свои плюсы и минусы. Большинство веб-разработчиков используют оба. Согласно ответам на изучение Bootstrap и использование CSS , вот типичный способ, которым следуют разработчики:

• Изучите CSS
• Изучите Bootstrap
• Изучите код Bootstrap, вы изучите некоторые основы макета, и на самом деле есть много интересных трюков
• Напишите свой CSS

3.Flexbox — это фреймворк?

Flexbox — это режим макета, а не фреймворк. В этой статье мы говорили о CSS3 Flexible Box или flexbox.

4. Является ли HTML фреймворком?

HTML (язык гипертекстовой разметки) — это стандартный язык разметки для документов, предназначенных для отображения в веб-браузере. Это не каркас.

В конце

Мы надеемся, что вы захотите опробовать некоторые фреймворки, которыми мы поделились с вами сегодня. Мы пропустили какие-то рамки? Сообщите нам об этом!

.