Как обосновать выбор стека технологий?

Question

[Pudjak]

На защите диплома скорее всего будет такой вопрос, почему выбрал именно эти технологии.
У меня чистый JS и PHP с фреймворком Laravel. Реальная причина-потому что кроме них ни в чём не разбираюсь (да и в них так себе). Но это, как и "больше документации, чем у других/популярнее", как аргумент не подходит.
Так вот, как можно обосновать выбор чистого JS для фронта, а не с фреймворком какимнитьVue/React там? Ну и PHP с фреймворком для бэка. За 3-4 предложения кратко так, чтобы уже дальше не могли до этого докапываться.

Comments

[Сергей Сергей]

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

[Илья]

Сергей Сергей,

Хотя, в экономическом разделе можно показать расчёт труда для знатока фреймворка и ванильного эстета, естественно, в пользу второго.

Ведь это просто ошибка про второго, или нет?)

[no_one_safe]

Так и говорите: я владею этими инструментами лучше прочих. В этом ничего постыдного нет.

[Сергей Сергей]

Илья, это бюрократическая хитрость, чтобы решить проблему вопрошающего.

Answer 1

[ThunderCat]

У меня чистый JS и PHP с фреймворком Laravel.

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

Если у вас на фронтенде нет огромного функционала по манипулированию ДОМ, это не СПА и нет смысла тянуть еще 10 библиотек ради 200 строчек кода - чистый жс лучший выбор. Плюсы - хорошо поддерживается, любой специалист среднего уровня может поддерживать, нет необходимости в дополнительных библиотеках, которые ведут к дополнительной зависимости от чужой кодовой базы, нет необходимости следить за последними изменениями в чужой библиотеке, не тянутся лишние файлы.

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

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

Comments

[Pudjak]

Ну про JS да, можно сказать, что на клиенте не будет всяких сложностей и нет необходимости использовать фреймворк.
А почему именно PHP, а не какой-нибудь там питон или джава, или на чём там ещё бек делают?
Про Ларавел да, слишком общее получается. У меня проект веб-приложение информационная система, может тут получится что сказать, что Laravel для такого больше других PHP-фреймворков подойдёт)

[ThunderCat]

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

[Pudjak]

ThunderCat, так ну мне тут в другом месте написали: "у php и бд свои производительности. Ты ждешь пока фронт отправит запрос на бек, бек его обрабатывает (в твоем случае php), потом передает на бд, бд его обрабатывает, бек отправляет на фронт"
То есть оно же все поочереди выходит, то есть быстродействие языка и фреймворка получается влияет?

[ThunderCat]

Pudjak, Вам так то конечно все верно написали, только вот есть нюансы )

Ты ждешь пока фронт отправит запрос на бек(это вообще к скорости работы стека отношения не имеет, все зависит от интернета и машины пользователя), бек его обрабатывает (в твоем случае php)(условно это займет 0,02сек с роутингом, контроллером и экшеном), потом передает на бд(вообще можно пренебречь), бд его обрабатывает(вот тут может быть условно от 0,01 до 1-2+ секунд, в зависимости от запроса), бек отправляет на фронт(пусть еще 0,02).

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

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

Именно из-за того что оно все по очереди, язык 90% простаивает в ожидании данных от бд. И даже написанное на ассемблере приложение выиграет вам пусть 50% от тех 10% что работает язык, общий прирост получится поднять на 5%. Это при том что стоимость разработки и поддержки поднимется в разы. За эти деньги можно разово вложиться в железо (допустим взять второй сервер чтобы работал параллельно) и увеличить производительность в 2 раза за в 10 раз меньшую сумму.

Answer 2

[true]

Laravel трудно оправдать

про фреймворки на js много статей и на хабре, что они это плохой выбор

на бэкенде надо было так же сделать на чистом языке плюс sqlite

а тут у тебя противоречие получается
ты на клиенте правильно поступил, а на бэкенде затупил

Comments

[Pudjak]

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

[true]

пхп это хороший выбор
это самый распространенный язык на бэкенде

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

[ThunderCat]

на бэкенде надо было так же сделать на чистом языке плюс sqlite

Откуда такие выводы без понимания что вообще за проект?

[Pudjak]

ThunderCat, ну если вкратце, то просто куча разных выводимых на страницы таблиц с данными из БД и куча разных форм с внесением данных в эти таблицы.

[true]

Pudjak, всё это можно было сделать без фреймворка

[Pudjak]

true, ну можно то можно, но сделал то уже с фреймворком, за 2 месяца теперь переделывать что ли?)

[true]

Pudjak, просто найди все плюсы этого фреймворка и раздуй их ))