на чем лучше писать веб приложение
Языки программирования и технологии для веб-разработки
Карьера в области веб-разработки является прибыльной, захватывающей и требующей готовности к постоянным изменениям. Для этого требуется определенный набор хорошо отработанных навыков и знание языков, которые вам нужно будет обновлять год за годом. В свою очередь, каждый день Вы сможете создавать действительно классные веб-материалы, и в конце каждого месяца вы будете получать хорошую зарплату. Неплохо, да?
В последние годы, когда сеть продолжает развиваться, появилось несколько различных потоков веб-разработки:
Независимо от того, какой путь вы выбрали, вы все равно должны понимать каждую сторону, чтобы правильно выполнять свою работу.
Итак, вот 10 лучших языков программирования для веб-разработки, как на стороне клиента, так и на стороне сервера.
CSS / HTML
JavaScript
Язык интерфейса, используемый для создания и разработки веб-сайтов, настольных приложений и игр. JavaScript работает во всех браузерах и может работать с программами, которые не размещены в Интернете. Он поддерживает как функциональные, так и объектно-ориентированные стили программирования, и в основном, это ваш подход к созданию потрясающих пользовательских интерфейсов и веб-сайтов / приложений / игр, которые выглядят супер круто. Понимание JavaScript важно, даже если ваше сердце настроено на развитие серверной части. Компоненты, структуры данных и алгоритмы JavaScript применяются практически к любому другому языку.
Python
Java, разработанная в 1990-х годах и по-прежнему наиболее востребованная, является золотым стандартом в области веб-разработки во всем мире, во всех областях. Она ориентирована на объекты и работает на любой платформе, что делает ее чрезвычайно универсальной. Если вы хотите, чтобы ваш safe можно было использовать практически во всех технологических компаниях в мире, то непременно выбирайте Java. Интересный факт: Java изначально предназначался для интерактивного телевидения, но вскоре его создатели поняли, что она слишком далеко опережает свое время для этой конкретной отрасли. Остальное уже история.
На чем писать веб приложения с GUI как в desktop app?
Средний 3 комментария
и так. «массовый веб» и «тяжелый интерпрайз» :
примеры: вконтактик, форумы, и 99% всех веб сайтов.
типичные технологии: php, одноглазый змей-питон, js, чудо руби, и все прочее и тд.
2. интерпрайз интранет
. и различные АРМ с веб-интерфейсом в локальной сети и сложной бизнес логикой
характерные признаки: не слишком большое число пользователей (несколько сотен, максимум пара тысяч), сложная логика бизнес процессов и сложная логика работы формы, высокие требования к надежности.
быстро-меняющиеся процессы предприятия, меняюшиеся раждые полгода регламенты, постоянный рефакторинг под давлением постоянно меняющейся обстановки.
примеры: СЭД (системы документооборота), арм различных госструктур, арм различных операторов, и тд.
у нас есть свои домашние заготовки, но, повторюсь, мы пока их не выпускаем на массовый рынок, предлагать не буду. погодите полгодика, и все будет.
Не решает и даже не пытается) И Rest считает не костылями, а вполне себе полноценным подходом. Посмотрите мой ответ. Тем, кому реально хочется писать под веб так же, как и под десктоп, следует использовать ASP.NET WebForms.
Если есть опыт написания под десктоп на WinForms или Wpf, то обработчики вида
void btn_Click(Object sender, EventArgs e) < >
будут близкими и родными.
Прочитал, но так и не понял, чем современный подход на REST принципиально не подходит для написания
СЭД (системы документооборота), арм различных госструктур, арм различных операторов, и тд.
90% последователей этих технологий не понимают даже основ проблем разработки больших систем на языках с динамической типизацией
REST сервисы вполне можно писать на языках со статической типизацией, C# или Java. Никто использовать js для сервера не заставляет. Клиентскую часть вполне можно писать на вышеупомянутом TypeScript. Тот же Angular его активно использует.
одна только попытка использовать stateless подход и тяжелый толстожЁпый js грозит вам переработками такого масштаба
я вижу перспективу в использовании web-socket, но опять же, промышленных наработок и фреймворков нет.
Как нет, в ASP.NET давно написана обертка для них, SignalR. Пользуйтесь на здоровье.
mletov, я не про обертки над вебсокетами.
я про то, что нет промышленных решений, которые используют вебсокеты для работы с гуи, максимально сближая веб интерфейс и бакенд. идеальным я виже технологию, которая управляет веб интерфейсом по принципам мало отличающимся от того, как например Qt работают со своими формами.
Прочитал, но так и не понял, чем современный подход на REST принципиально не подходит для написания
СЭД (системы документооборота), арм различных госструктур, арм различных операторов, и тд.
а это и не объясняется в самом тексте )
в общем случае, есть несколько моментов, каждый из которых может быть и можно рассматривать как мало значимые, особенно на малых проектах (все так живут, действительно), но вместе они приводят сложные проекты к серьезным проблемам :
вы можете пытаться модерировать и отслеживать эти зависимости, и наверное даже это некоторое время у вас будет получаться, но это затраты времени, которые сильно замедляют любые работы по модификации системы.
вот и получается, что современные массовые подходы к веб-разработке мало пригодны для сложных бизнес-систем.
но вот нет хороших промышленных решений работающих по этим принципам. есть c++/qt и их трансляция формы в веб. есть java и jsf, в варианте какого нибудь там primefaces, вроде как есть vaadin, но как я понимаю, это фактически перекомпиляция java в js с полной отгрузкой приложения клиенту (что малопригодно в ситуации недоверия клиенту).
Как разработать веб-приложение за 8 шагов
Если вы всерьез подумываете о разработке своего веб-приложения, сначала ответьте на два вопроса:
Первое — веб-приложение всегда разрабатывается для решения конкретной задачи, как правило, одной. Оно должно быстро реагировать на изменения, и чем проще и меньше время реакции, тем более веб-приложение жизнеспособно.
Второе — есть по меньшей мере 6 путей к разработке веб-приложения, самым современным из которых является реализация фронтенда как single page application, где контакт с бэкендом реализуется через REST API. Данный путь к созданию веб-приложения достигается за 8 шагов.
1. Работа с бизнес-логикой бэкенда
Есть два способа такой работы: вы можете сгруппировать бизнес-логику бэкенда в одном сервисе (монолитная логика) или реализовать каждый ее компонент в отдельном микросервисе. Работая с небольшим проектом, используйте первый способ, а при работе с крупным проектом идеально подойдет второй.
2. Выбор языка программирования
Если вам менее важна производительность веб-приложения, пишите на Python (фреймворки Django, Flask), Node JS (фреймворки Express JS, Koa JS, Gatsby JS), Ruby (фреймворки Ruby on Rails, Grape). Если в приоритете скорость приложения — используйте Golang (фреймворки Gingonic, Beego, Revel). Еще вы можете использовать популярный язык программирования от Microsoft — C#, который произносится как «си шарп». Он разработан в качестве языка прикладного уровня для CLR. С# вобрал в себя многое от C++, Модула, Delphi, Smalltalk и Java, но разница состоит в том, что С# исключает модели, которые зарекомендовали себя как проблемные при разработке ПС. К примеру, C# в отличие от C++ не поддерживает множественное наследование классов, но допускает множественную реализацию интерфейсов. Главное, какой бы язык вы не выбрали, кодить на том, который вы хорошо знаете.
3. Реализация бизнес-логики
Сперва ориентируйтесь на паттерн MVC, а когда поймете, что бизнес-логика начинает усложняться, используйте presenter и interactor. Но помните, что presenter и interactor находится на разных уровнях и выполняют различные смысловые и функциональные нагрузки.
Presenter обрабатывают события от пользовательского интерфейса (UI) и выполняют роль callback из внутренних уровней (Interactors). Presenters легко тестировать и их задача состоит в том, чтобы получить информацию от веб-приложения и преобразовать ее для перемещения presenters на экран с помощью представления (View).
Interactor по факту вмещают бизнес-логику веб-приложения, то есть проверку условий и обработку информации. Interactor работают фоном и перемещают события и информацию на верхний уровень, presenters, c помощью callback.
4. QA-тестирование бэкенда
Тестирование нужно обязательно делать для того, чтобы знать, правильно ли работает бизнес-логика вашего веб-приложения, а также для того чтобы не проверять постоянно «вручную» работоспособность кода. Используйте автоматическое тестирование для модулей и библиотек, соответствия UI/UX и API. Пропишите несколько вариантов тестирования. Разработайте roadmap для платформы, чтобы управлять испытаниями для всех типов тестирования. Обязательно сделайте подключение инструментов отслеживания текущего покрытия кода, чтобы убедиться в том, что ваше веб-приложение не «виснет» и работает без багов и перебоев.
5. Добавление поддержки сваггера
Swagger – это «умная» документация RESTful web-API. По сути, это фреймворк для спецификации REST API, дающий возможность не только просматривать спецификацию в интерактивном режиме, но и отправлять запросы, именуемые Swagger UI. А теперь на счет веб-приложения.
Предположим, вы уже начали разработку фронтенда вашего веб-приложения. Как вам понять, какие параметры и запросы отправлять на сервер? Заглядывать в код бэкенда? Поверьте, это не лучший выход.
Рекомендую вам добавить поддержку сваггера, при этом очень здорово, если сваггер еще и поддерживает генерацию через тесты. Таким образом, он поможет вам документировать API.
6. Работа с бизнес-логикой фронтенда
Сложность работы с бизнес-логикой фронтенда заключается в том, что тут очень много фреймворков. Обычно в современном програмировании используются Angular, React, Vue. У них у всех есть как свои достоинства, так и свои недостатки. Но я рекомендую вам выбирать для работы с фронтендом React, так как он легче, проще и более гибкий.
7. QA-тестирование фронтенда
Фронтенд тестируют двумя основными видами тестов — на логику и на отображение. Тесты на логику проверяют логическую реализацию функций и классов. Тесты на отображение отвечают за то, чтобы наполнение демонстрировалось пользователю в том виде, который вы задумали, прописывая фронтенд. Для осуществления QA-тестирования фронтенда используйте такие фреймворки, как Mocha, Chai, Jest, Ava, Enzyme, Jest — они самые ходовые, простые в эксплуатации и наиболее понятные из всех.
8. Мониторинг качества веб-приложения
Когда вы завершили седьмой этап, ваше веб-приложение, можно сказать, готово. Ну, или оно находится на финальной стадии готовности — 98%. Что вам нужно знать по итогу? Естественно, первое, что нужно, — это понять, насколько качественно реализовано приложение, как оно будет работать и на какое время хватит его износостойкости. В этом вам поможет Lighthouse — автоматизированный инструмент с открытым исходным кодом для мониторинга качества вашего веб-приложения. Lighthouse проводит системный аудит производительности и доступности веб-приложения для понимания обычного пользователя.
Собранные с помощью Lighthouse данные помогут вам в дальнейшем в случае надобности дорабатывать ваше веб-приложение, изменять в нем какие-то детали или же добавлять и оптимизировать новые функции.
Имейте в виду, что, начав разработку веб-приложения, вам нужно будет изучить все «подводные камни» каждого этапа, а также запастись терпением, потому как сама разработка может занять у вас несколько дней, а вот тестирование и доработка с устранением багов может затянуться и на многие месяцы. Будьте ко всему готовы и помните про первые и самые важные два вопроса: всегда ставьте конкретную задачу, которую должно решать ваше приложение, перед тем, как начать разработку, и выбирайте самый удобный и легкий для вас способ разработки, в котором вы хорошо ориентируетесь. Ведь разработка веб-приложения — это именно тот случай, когда надо идти путем наименьшего сопротивления.
Самые популярные языки программирования бэкенда: для чего они подходят лучше всего и какие компании их используют
Что такое бэкенд, на Хабре рассказывать не нужно, поэтому сразу переходим к сути статьи. В ней рассказывается о наиболее подходящих для бэкенда языках программирования. Кроме того, автор рассказывает о задачах, для решения которых эти языки идеально подходят и компаниях, которые используют их у себя.
Сложно сосчитать количество статей на Хабре, которые имеют отношение к этому языку. Это один из самых популярных языков программирования, который используется более 20 лет.
Универсальным он является благодаря виртуальной машине Java (Java Virtual Machine, JVM). Она позволяет коду на Java одинаково работать на всех совместимых платформах. JVM — своеобразная прослойка, в которой Java-программа преобразуется в код, который может выполняться на любой машине.
Несмотря на то, что Java чрезвычайно популярна среди разработчиков ПО, она сложнее для новичка, чем, скажем, Python. Тем не менее, у Java огромное сообщество, которое даст ответ практически на любой вопрос новичка или профессионала.
Что вы можете делать на Java
На PHP работает около 78.2% всех веб-сайтов. Язык впервые был представлен в 1995 году, когда для создания динамических сайтов существовало не так много возможностей.
Поскольку это динамически типизированный язык, для одной проблемы можно найти сразу несколько решений. Правда, это одновременно означает и то, что один и тот же участок когда может вести себя по-разному в зависимости от конкретной ситуации, что делает программы на PHP сложно масштабируемыми и в некоторых случаях медленными.
79.1% сайтов, о бэкенде которых известно, используют PHP
Компании, которые используют PHP
А сколько получает PHP-разработчик?
.NET (C#, VB)
Основа языка — архитектурный шаблон MVC (Model-View-Controller). В этой схеме контроллер принимает запросы пользователя и взаимодействует с моделью для обработки данных. Потом результат уже передается в представление, отображаясь в виде интерфейса веб-страницы.
C# — высокоуровневый язык программирования, на котором можно писать софт, независимый от архитектуры процессора конкретного компьютера.
C# популярен среди разработчиков благодаря некоторым преимуществам С++. При этом на нем проще писать код, избегая ошибок, которые характерны для того же С++.
Это язык программирования, который использует графический пользовательский интерфейс для работы с кодом. Это простой язык для начинающих благодаря несложному синтаксису. В целом, чаще всего он используется для прототипирования.
Недостаток VB — большой объем памяти, который необходим для установки и запуска инструментов разработки.
Ruby on Rails — веб-фреймворк на языке программирования Ruby. У него есть целый набор готовых инструментов, которые дают возможность быстро выполнять базовые задачи.
Это лаконичный язык, который не требует много года для бэкенда. Так что разработчики могут быстро создавать и запускать приложения. Также он идеален для прототипирования — примерно так же, как и Python. В начале 2000-х популярность Ruby выросла, но затем снизилась.
Достоинство Ruby в том, что это открытый язык, так что он может быть модифицирован и дополнен.
Python
За последние несколько лет он стал чрезвычайно популярным языком программирования. Язык универсален и используется как для веб-разработки, так и для создания настольных приложений. В интернете есть огромное количество различной информации об этом язык, так что он неплохо подходит для начинающих.
Более того, синтаксис языка простой и понятный, по сравнению с другими бэкенд-языками. Те, кто программирует на Питоне, говорит о коде, как об «элегантном», «читаемом» и «красивом».
Что можно делать на Python
JavaScript
Этот язык можно использовать как для фронтенда, так и для бэкенда. Это отличный язык для новичков. В нем относительно простые настройки, а код можно писать прямо в браузере.
Правда, именно из-за гибкости языка скрипты, написанные на нем, порой работают очень медленно. Кроме того, их сложно как поддерживать, так и масштабировать, как и в случае с другими динамически типизированными языками.
При этом сообщество у языка просто огромное, в Сети большое количество материалов для изучения.
Что можно делать на JavaScript
Языки, на которых пишут разработчики, принявшие участие в опросе Stack Overflow
Комментарий эксперта
Даниил Пилипенко, директор центра подбора IT-специалистов SymbioWay и евангелист бэкенд-направления онлайн-университета Skillbox, дополнил перевод экспертным мнением о востребованности самой специальности “бэкенд-разработчик”.
Спрос на разработчиков последние 20 лет продолжает постоянно расти: каждый год количество вакансий разработчиков увеличивается примерно на 15%. При этом количество самих программистов растет не более, чем на 5% ежегодно. Это приводит к постоянному росту дефицита и, соответственно, зарплат этих специалистов.
Найти хороших и сильных разработчиков становится всё сложнее. Если вы решили создать какой-то проект, лучше выбирать наиболее популярные в настоящее время технологии и языки программирования.
Часто встречаю проекты, на которых в качестве основных технологий выбирают что-нибудь очень редкое вроде Go, Erlang или Flutter, и потом месяцами не могут найти разработчиков.
Как уже было сказано в статье, самые распространённые сейчас языки для backend-разработки — это Java (для крупных решений), PHP (для веб-сайтов) и Python (для небольших веб-решений и научных задач). В случае выбора этих технологий вы сможете относительно быстро находить сильных специалистов, расширять команду и заменять тех, кто выгорел или ушёл. Благодаря этому ваш проект сможет не только появиться на свет, но и вырасти.
Как разработать хорошее веб-приложение и избежать ошибок — отвечают эксперты
Авторизуйтесь
Как разработать хорошее веб-приложение и избежать ошибок — отвечают эксперты
В разработке веб-приложений много моментов, понимание которых приходит только с опытом, поэтому выгодно учиться у тех, кто уже наступил на все возможные грабли и выработал наиболее эффективные способы разработки. Мы попросили экспертов поделиться своим мнением о том, как подойти к разработке веб-приложений. Их ответы публикуем ниже.
технический директор «БюроБюро»
Когда вы выводите на рынок высоконагруженный сервис, лучше всегда использовать клиент-серверную архитектуру, потому что с монолитным решением вы рано или поздно упрётесь в потолок, а ваше веб-приложение быстро начнёт напоминать франкенштейновского монстра, в котором все компоненты переписаны и привинчены не самым очевидным образом. Помимо этого, клиент-серверная архитектура в будущем позволит проще при необходимости подключать микросервисы, тем самым двигаясь в сторону микросервисной архитектуры.
В первую очередь необходимо ответить на вопрос, что будет с вашим проектом через год и через три года. Сформулированные цели определяют архитектуру проекта, но в любом случае всегда с самого начала важно заложить масштабируемость, безопасность, гибкость, скорость в работе с продуктом и скорость доработок, высокую отказоустойчивость, быстродействие системы, простоту интеграций со сторонними приложениями и сервисами.
В своей работе мы используем платформу собственной разработки BuroData Platform и следующий технологический стек:
разработчик IT-компании MediaSoft
Чтобы написать идеальное веб-приложение, вы должны знать всё о своем коде. Для этого идеально подойдёт самописный фреймворк, потому что только так вы будете в курсе всех подводных камней проекта. После этой фразы я получил леща от менеджера.
Чтобы написать хорошее приложение, его надо написать. Буквально — в блокноте, в формате основных идей о том, как оно должно работать и из каких логических частей состоять. Это не про «контроллер берёт данные из модели и отправляет на отрисовку». Это про то, какие логические части есть в приложении и как они друг с другом общаются.
Не советую бездумно гнаться за всем «модным и молодёжным»: не можете объяснить, зачем вам GraphQL и какие у него преимущества перед простым REST API из трёх запросов, — не используйте. Кажется, это очевидно, но я сам не раз попадал в эту ловушку. Подход «открыть awesome-лист и поставить всё» тоже не лучшее решение: наличие огромного количества сторонних зависимостей не делает проект круче.
Вопрос «какой фреймворк/ОРМ/админку использовать» решается просто: выбирайте тот инструмент, который лучше всего знаете. Ничего не знаете и не умеете — берите то, с чем быстрее и проще разобраться, где меньше всего «уличной магии». Например, из списка Yii/Laravel/Symfony я выберу Laravel. Из админок выберу AdminLTE, потому что она «ну вроде норм и работает». Ни один из авторов этих проектов до сих пор не заплатил мне за рекламу.
Я агностик и считаю, что нельзя создать идеальную архитектуру, которая не будет нуждаться в переделывании: никакие методологии не защищают вас от переписывания. Поэтому пишите так, чтобы ваше веб-приложение работало хорошо, пишите на том, что решает поставленную задачу. Не бойтесь написать лишнее и затем смело отрезайте ненужное: по-другому никак.
директор по развитию бизнеса в DAR
Веб-приложения непрерывно завоевывают всё большую популярность и в значительной мере вытесняют классические. Их высокая гибкость, широкий выбор языков программирования и независимость от операционной системы клиента легко объясняют такой успех. Сама идея клиент-серверных приложений, будучи уже весьма зрелой, в очередной раз захватила мир программного обеспечения.
Так как же писать такое приложение правильно? Разумеется, однозначного, а тем более единственно верного ответа на этот вопрос не существует. Различные организации, группы и индивидуальные программисты склоняются к своим, отвечающим их требованиям и предпочтениям методам и подходам. Кроме того, существуют устоявшиеся в силу тех или иных причин и широко применяемые решения, которые, так или иначе, справляются с поставленными задачами.
Не секрет, что при написании веб-приложения, помимо очевидной реализации требуемой функциональности, необходимо добиваться максимальной эффективности. Конечно, для скромных частных проектов это не особенно важно, но для крупных коммерческих проектов — жизненно необходимо. Давайте заглянем глубже.
Термин «эффективность» сам по себе достаточно широк, но мы в рамках нашего контекста определим его следующим образом: чем быстрее исполняются функции приложения и чем меньше аппаратных ресурсов они при этом потребляют, тем приложение эффективнее. Исходя из такой трактовки и нужно подходить к выбору средств и инструментов для создания нужного веб-приложения.
В каждом индивидуальном случае этот выбор должен делаться с учётом специфики конкретной задачи, но можно выделить и ряд общих рекомендаций, к которым мы пришли после достаточно обширного опыта работы по общепринятому образцу.
Итак, общеизвестно, что наиболее важным этапом создания любого ПО является проектирование его архитектуры. Здесь учитываются все требования и особенности и принимаются стратегические решения. Когда общая структура приложения определена, можно говорить о выборе подхода к её реализации, необходимости встраивания механизмов контроля, возможности расширения и масштабирования.
Говоря о контроле и тестируемости, уместно будет вспомнить известную истину, что возможность проверить работу приложения в различных условиях и с разнообразным набором данных — бесценна и не всегда достижима. Тем не менее, различные логи и механизмы оповещения, срабатывающие по определённым условиям, способны значительно облегчить тестирование и отладку.
Однако самой, наверное, неожиданной рекомендацией будет избегать любых сторонних библиотек и фреймворков всегда, когда это возможно. Это относится как к клиентской части приложения, так и к серверной. Приложение должно быть максимально компактным и потреблять минимальное количество ресурсов. Например, использование очень популярной библиотеки jQuery (или ей подобных) значительно замедляет работу клиентской части и требует немало ресурсов, что совершенно не обязательно. Абсолютно всё, что нужно, можно написать просто на JavaScript, а более быстрая загрузка и работа клиентской части будет высоко оценена заказчиком.
То же относится и к серверной части, а особенно к построению API для взаимодействия между ними. Для этой цели вполне достаточно использования устоявшихся протоколов CGI или WebSocket там, где это нужно. Различные фреймворки типа ORM несколько облегчают работу программиста ценой снижения эффективности приложения, да ещё и добавляют зависимость от этих библиотек и привносят в систему все их недоработки.
Гораздо эффективнее написать все необходимые сервисы самостоятельно на выбранном языке. Это радикально поднимет эффективность системы, ведь она не будет содержать лишнего кода, а тот код, который будет написан специально для реализации конкретной функциональности, будет исполняться намного эффективнее кода общего назначения.
Да, собственно написание приложения по таким принципам сложнее и чаще всего дольше, чем при использовании библиотек общего назначения, но ведь оно пишется один раз, а работает годами. Нам представляется разумным создание именно индивидуально ориентированных приложений (подобно индивидуальному пошиву костюма). Именно такой подход позволяет создавать быстрые надёжные эффективные приложения, которые, при должном уровне исполнения, значительно превзойдут системы общего назначения.