MaxKorz: для NodeJS единственные отличия в средах, с которыми я сталкивался, это разрядность ОС и самой ноды (при работе с более-менее большими числами заметно), больше никаких, иногда ещё бывают проблемы с компиляцией нативных модулей, но это не особенности ЯП, а особенности среды выполнения кода и решаются не при помощи знаний ЯП. И если вы не знаете как работает какая-то конструкция в ЯП или паттерны проектирования, то никакие знания о том что есть какая-то редкая особенность в каком-то браузере с какой-то версией вам это знание ЯП не восполнит и отсутствие такого знания не оправдает.
Всё же нужно различать ЯП и среды. Если бы знание сред выполнения кода являлись частью "хорошего знания ЯП", то не было бы отдельных вакансий типа "NodeJS разработчик" или "Frontend разработчик", а были бы они с названиями "JS разработчик" и нанимая такого человека с хорошими знаниями ЯП работодатель бы думал, что он умеет писать хорошо и быстро приложения под любую среду. Но вы же сами понимаете, что это не так :)
Я могу сказать точно, что у меня хорошие знания JS, но знания в NodeJS намного перевешивают по объёму и качеству знания по фронтэндовым направлениям. Можно ли сказать, что если человек не знает как работает поиск элемента в DOM в сафари или линксе (есть такой браузер, весьма специфичный), что он плохо знает ЯП или знает ЯП хуже, чем человек, который знает об этих особенностях? Ответ: НЕТ! Потому, что это не является частью ЯП.
Пишу на JS уже много лет и не понимаю почему знания того как работают браузеры относят к знаниям по JS (языка программирования), ведь браузеры и их API не являются частью этого языка программирования. Мне всё таки кажется, что в вопросе "глубокие знания JS" нужно относить именно JS, а не все среды где этот JS может выполняться. А то как работать с DOM или CSS в браузерах - это уже знания по frontend-у, а не по JS.
Если исходить из логики, которую описал MaxKorz, то JS разработчик серверных приложений никогда не будет знать JS хорошо, т.к. ему абсолютно наплевать как работать с DOM в браузере.
Я сторонник того, чтобы писать код понятно, а не оптимально. Если есть ситуация, когда код написан локонично и понятно, но работает на 10% медленнее, чем если его оптимизировать, сделав при этом не очень понятным и местами не очевидным, то я выберу первый вариант. Хотя бывают, конечно, ситуации, когда и код получается оптимизировать и читабельность сохранить, так же как и бывают случаи, когда без оптимизации через потерю читабельности не обойтись, но бывают они очень редко, во всяком случае в моей практике. Всё таки нужно исходить из позиции, что не только ты один должен понимать как и что работает, для этого, собственно, паттерны проектирования приложения и придумали.
Насчёт того, что кто-то выше писал, что нужно ещё знать современные библиотеки - это тоже к знаниям языка программирования, о котором автор вопроса спрашивает, имеет мало отношения (за исключением того, что бОльшая часть из них написана на JS), тем более в JS, где этих библиотек/модулей, которые решают примерно одни и те же задачи как у дурака фантиков.
А в общем, полностью согласен с автором данного ответа :)
HoHsi: поддержка local storage есть уже с 8-го осла caniuse.com/#search=localstorage Сейчас 2015 год же :)
Вы слишком сильно усложняете задачу...
Пользователь регистрируется, вы сетите в БД пароль зашифрованный каким-нибудь из не обратимых алгоритмов хэширования (md5, sha1, но лучше bcrypt). Если будете использовать bcrypt, то там есть метод для генерации соли. Получившийся хэш и записываете в БД. Далее при авторизации можно сравнить пароль, который пришёл от пользователя с хэшем записанным в БД, если проверка пройдёт успешно - выписать токен.
В качестве токена можно использовать JWT (например, вот этот). В JWT записывается информация, которая позволит вам идентифицировать пользователя и какая-нибудь дополнительная информация для ваших нужд, плюс есть подпись, которая позволяет определить подлинность присланного JWT.
Вообще посмотрите Passport с локальной стратегией (LocalStrategy) и всё должно стать понятно.
>> Оказалось, что на 20 часов в неделю в гибком графике студенты мало кому нужны :(
>> при виде этих жалких 30к забью
Ну и запросы у студентов нынче...
Опыта нет, знаний особо тоже никто не видел, хочет на пол-ставки и 30к в месяц.
Отсюда вопрос: А где и на каких условиях вы работали раньше?
Делаю в точности как в этом мануале, но не получается по домену роутинг настроить... Вот по ip адресу работает хорошо, но мне желательно бы по домену всё таки :)
vasIvas: вы вообще знаете как работает гит?
Чтобы получить доступ к репозиторию нужно сгенерировать сертификат со своей стороны и публичную часть этого сертификата прописать в аккаунте гитхаба/битбакета/гитлаба.
В гите нельзя что-то сохранить или что-то с него скачать, с ним можно синхронизироваться, его можно склонировать (читай как синхронизировать).
Дмитрий Энтелис: Не понятно, потоки или процессы=( Захлёбываться начинает 1 поток демона, а для решения проблемы вы запускаете несколько демонов. Но это я придираюсь :)
Вообще можно запустить несколько инстансов приложения на PHP, так что проблемы и там и тут будут одинаковыми.
А проблемы с отсутствием нативной поддержки транзакций у noSQL систем можно решить, это, конечно, будет не такое тотально безопасное решение как транзакции, но всё же работать будет.
Дмитрий: Причём тут Java?))) Что вы называете мордной?) Фронтентд?) Вообще best practice в ноде это: backend RESTful Web API на ноде (читай как почти frontend) + frontend на AngularJS.
А вообще, как напишешь - то и получишь)
Дмитрий Энтелис: так нода и так однопоточная. А транзакции должны быть внутри СУБД, а не внутри кода, иначе это будет жуткий костыль. А вообще я имел ввиду случай, когда вместо РСУБД используется НРСУБД, например, mongodb. В последнем случае всё придётся писать в коде, но это уже будет не такой страшный велосипед, т.к. он не будет дублировать реализованный функционал РСУБД...
Что за бред?
Разве загрузка каталога, личного кабинета и пр. не обмен данными клиент-сервер?
На самом деле правильного ответа тут нет. Оба языки хороши, у обоих есть свои плюсы и минусы. Всё реализуемо на обоих платформах. Выбирайте из того, что лучше знаете, в чём больше уверены.
Я бы, например, выбрал Node.js, хотя довольно долго писал на PHP. В нашем проекте мы недавно биллинг написали на ноде и ничего, нормально. Кода получилось меньше, чем если бы мы писали его на PHP. Под ноду есть отличные fullstack генераторы, например, https://www.npmjs.org/package/generator-angular-fu...
По моим ощущениям, нода удобнее, чем PHP :)
Уже начали делать)))
Удобная вещь, да, особенно с yo генераторами. Там фулстек для Node.js + MongoDB + Mongoose + Angular.js. А главное - с ним всё быстро делается)
@qmax на вкус и цвет :)
Мне кажется тут дело привычки. Я пользовался svn, после него сразу перешёл на git, и последний показался проще, даже без GUI. Потом пытался пользоваться mercurial и понял, что больше ничем не хочу пользоваться кроме как гитом :)
@butteff не всю. На самом деле там дефолтная глубина есть и она равна не дуотригинтиллиону. Для того, чтобы работало "без сервера" нужно bare репу создавать. Вот там будет вообще все объекты/диффы храниться.
