.NET Fest: полная программа конференции на сайте. Присоединяйся к самому большому .NET ивенту
×Закрыть

Давайте поговоримо про ES2015+ OOP-фреймворки під Node.js

Щось давно вже не було срачу стосовно Node.js, аж скучати вже почав. Тому, як говориться, let’s get ready to rumble.

Як я бачу зараз тему у світлі останніх нововведень ES2015 + TypeScript: для Node.js повинні з’явитись нові фреймворки, які дозволять створювати великі проекти, більші, ніж на PHP.

Чому так? Ну, по-перше, TypeScript це прямо мега-мега круто! Він дозволяє дуже суттєво зменшувати кількість помилок у коді. А чим менше помилок, тим більший проект можна будувати.

Про те, що TypeScript це НЕ мага-круто, може говорити лише той, хто його не використовував, або той, хто поколупав його пару годин, зачепився за якусь шараховатість у вигляді відсутності TypeScript-бібліотек, або у неможливості написати TS-вираз з потрібною сігнатурою і т.д., і пішов далі незадоволений.

Я і сам його почав неохоче використовувати, бо Angular 2+ написаний на ньому, ну і не були явними ті переваги, які надає TS. Спочатку я думав, що статична перевірка TS зводиться до перевірки найпростіших типів, таких як string, number і boolean. Але насправді, звичайно ж, це лише мікро-частина з того, що вміє TS...

Коротше, TypeScript дає ті будівельні лі́си, які дозволяють будувати справді великі проекти, зокрема і під Node.js. Можна навіть уточнити, що проекту, типу «гостьова книга» (тобто самому елементарному), теж не завадить використання TS.

Йдемо далі.

Які асоціації існують до тепер у розробників, які згадують про Node.js-фреймворки? — Правильно — мікросервіси, чати, вебсокети... щось таке, що працює досить швидко, але створювати на ньому масштабні монолітні проекти досить стрьомно, бо... оті колбек-хели. Якщо побудувати великий проект, спробуй тоді відловити помилки.

На дво́рі зараз ES2015+ з дуже суттєвим покращенням якості розробки на JavaScript. Так говорять багато хто, зокрема й розробники Angular. Я щільно перейшов на розробку JavaScript, коли вже можна було використовувати усі переваги ES2015+ (мабуть десь у 2014 році). Перед цим я програмував на PHP, чого гріха таїти.

Тож із ES2015 + TypeScript для мене було звично використовувати ООП з класами, абстрактними класами, інтерфейсами, модифікаторами доступа, наслідуваннями... Promises для мене були чимось таким, що завжди було у JavaScript =).

Які зараз є Node.js-фреймворки, які йдуть в ногу з часом?

Ну, звичайно ж це Koa, але в ньому я побачив лише переведення старої схеми, з використанням middleware, до коду, з використанням промісів, генераторів. Ну і сам Koa майже нічого не робить, окрім надання інтерфейсу цих самих middleware. Там хоч і є один клас Application, але, здається, Koa не спроектований щоб на ньому можна було на повну використовувати ООП і будувати складні проекти.

Express.js, як говорить нам документація, теж не глобально віддзеркалив нововедення ES2015+.

Пошук по ключовим словам «nodejs oop framework» теж не густо видає релевантні варіанти.

Ну і на останок, чому я думаю що на Node.js-фреймворках можна будувати значно більші проекти, ніж на PHP. Справа в тому, що якщо проект великий, швидше за все, він розбитий на модулі, кожен із яких ініціалізує свою конфігурацію. А що таке багато коду для ініціалізації в контексті PHP? — Правильно, він її буде робити за кожним запитом, в кращому разі він делегує ініціалізацію на Dependency Injector, але все одно це не зрівняти з Node.js-фреймворками, які усю ініціалізацію (на рівні application) роблять єдиний раз при старті...

Виходячи з вищезазначеного, думаю час вже створити нарешті сучасний Node.js-ООП-фреймворк. Я вже попи́сую свій, але ще рановато його представляти.

Цікаво почути думку форумців на ДОУ. Може вже є такі фреймворки, чи може вони теж пишуть свій лісапет.

LinkedIn

Лучшие комментарии пропустить

еще раз для свидетелей любителей ООП на JS.
тот самый middleware — это синтаксический сахар над функциональной композицией, учитывающий класс типа aka flatMap или монадический bind в более общем случае, под капотом которого — еще более универсальный CPS.

итак. во-первых, middleware — это 1:1 хаскеллевская do-нотация для блондинок. не удивляет ли вас, что всесильный express — это по сути

main = runServer XXXX $
do middleware1 >>= middleware2 $ do
... (и пошла-поехала get «/:word»)

?

т.е. именно простой пайп асинхронной обработке входящих данных?

сознательно ли или случайно весь JS-девелопмент стремиться к двум вещам — декларативности (этот ваш Hapi или тот же JSX) и функциональности (иммутабельность, композиционность, stateless-архитектура — Immutable.JS, React Stateless components, RxJS, Redux, Flux и прочее).

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

пожалуйста, не надо ООП-монолитов на NodeJS. мне ж с вами потом это и рефакторить.

NodeJS не вытеснит ни Java, ни С#, JS не съест веб-разработку. NodeJS — прекрасный нишевый инструмент у которого очень большое и светлое будущее в своей уютненькой зоне микросервисной архитектуры.

Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Дійшли руки до написання restify-ts-seed, тобто прикладу використання мого форку відомого веб-сервера restify (під Node.js). Старий-добрий restify і зараз скачують більше 200 тис. разів за місяць.

Може комусь буде цікаво поколупатись під кінець робочого дня =).

А, ще забув написати як запускати, зараз допишу в readme:

git clone https://github.com/restify-ts/restify-ts-seed.git
cd restify-ts-seed
npm i
npm run compile
npm start

О, колега підтягнувся: Очередная node.js-библиотека....

Швидкодія дійсно дуже велика, але пам’ять тече. Ще поки не дивився що вона вміє, але має розмір мабуть ще менший, ніж у Koa, мабуть і вміє вона стільки ж... хоча, треба глянути.

Мда, схоже що ця «бібліотека» складається із додаткового прошарку промісів між Node.js веб-сервером і кодом application... і все =). Дуже схоже на те, що уся робота цієї бібліотеки полягає у сповільненні рідного нодівського веб-сервака десь на 300-400 req/sec, ну і плюс — витік пам’яті. При тестах на ab -n 50000 localhost:3000/, споживання пам’яті збільшилось удвічі, а повторний запуск цього ж теста додав ще 20 МБ і досяг майже 90 МБ (тоді як рідний нодівський сервак споживає десь під сорок мегабайт)...

еще раз для свидетелей любителей ООП на JS.
тот самый middleware — это синтаксический сахар над функциональной композицией, учитывающий класс типа aka flatMap или монадический bind в более общем случае, под капотом которого — еще более универсальный CPS.

итак. во-первых, middleware — это 1:1 хаскеллевская do-нотация для блондинок. не удивляет ли вас, что всесильный express — это по сути

main = runServer XXXX $
do middleware1 >>= middleware2 $ do
... (и пошла-поехала get «/:word»)

?

т.е. именно простой пайп асинхронной обработке входящих данных?

сознательно ли или случайно весь JS-девелопмент стремиться к двум вещам — декларативности (этот ваш Hapi или тот же JSX) и функциональности (иммутабельность, композиционность, stateless-архитектура — Immutable.JS, React Stateless components, RxJS, Redux, Flux и прочее).

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

пожалуйста, не надо ООП-монолитов на NodeJS. мне ж с вами потом это и рефакторить.

NodeJS не вытеснит ни Java, ни С#, JS не съест веб-разработку. NodeJS — прекрасный нишевый инструмент у которого очень большое и светлое будущее в своей уютненькой зоне микросервисной архитектуры.

Кхм, що тут можна коментувати... Давайте від високопарної абстракції повернемось на Землю і поговоримо про щось більш конкретне. Із конкретного я побачив лише прохання із «не надо ООП монолитов». Поясніть, будь-ласка, що не так із монолітами? (якщо мова не йде про розподілену систему на декількох машинах)

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

ага я вот тоже уже вижу как занимаюсь дебагом NodeJS какого то крупного екомерс проекта написанно типа на ооп на 50к файлов

При 50к файлів — це якраз наврядчи ООП...

magento 2 for example
лично моё скромное мнение, я совсем не много столкнулся с нодой, и ничего не утверждаю, но мне кажется что ахилесова пята для больших проектов на ноде как раз вот дебагинг, работа с ошибками etc

Мабуть основні страшилки стосовно ноди пов’язані з колбек-хелом, який й читати важко, й дебажити. Думаю що навіть архітектура middleware виникла якраз через цей самий колбек-хел.

Проблему колбек-хела вирішили за допомогою Promise у ES2015. Разом з Promise вирішилась і проблема з дебагом. Плюс — зараз є досить популярною бібліотека кастомних помилок VError, яка дозволяє скріпляти трейси різних помилок в один трейс, так що вже не загубиться жодна помилка.

Для дебага не такі й складні правила.

Я ж і кажу, що ES2015 + TypeScript вирішують більшість старих проблемних моментів Node.js.

кстати, рекомендую напосмотреть:
Adonis js — частично Laravel на ноде, но от индусов
Think js — от китайцев

но с ES2015, генераторами, асинками и т.д.

loopback.io позиціонується себе як enterprise nodejs framework
а ще є Sails.js як альтернатива

Так, раніше я приглядався і до loopback, і до sails.

loopback платний (здається безкоштовною є лише урізана версія), причому, на скільки я зрозумів, він монструозно-великий, через що й неповороткий. На початок 2016 року, у них ще не було версії під CentOS 7, це при тому, що пройшло більше, ніж два роки після виходу CentOS 7 (на той момент). І взагалі, їхній підхід із CLI-tools під будь-що — на любителя...

Sails.js помітно повільніший за Express.js й також не ООП, хоча й MVC.

loopback платний

Він повністю open-source, і немає ніякої урізаної версії

й також не ООП

яка різниця як написаний він всередині, хто Вам заважає писати в ООП-стилі самому використовуючи його. ES6/Тайпскріпт ніхто не відміняв

яка різниця як написаний він всередині, хто Вам заважає писати в ООП-стилі самому використовуючи його. ES6/Тайпскріпт ніхто не відміняв

Різниця прямо дуже суттєва. Якщо так питаєте, схоже ви не програмували в ООП-стилі, не використовували DI, не писали модульних тестів під таку архітектуру і т.д.

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

Як може ООП-архітектура зарадити? Гляньте цей код:

@Injectable()
class HelloWorldController
{
  constructor(bodyParser: BodyParser, db: MySQL, log: Logger)
  {
    // Тут вже працюємо із кожним параметром як із інстансом указаних класів
  }
  
  run(req: Request, res: Response)
  {
    res.send('Hello World!');
  }
}

const server = new Server();

server.get('/', HelloWorldController, 'run');

// Насправді ці провайдери можна додати єдиний раз на головній сторінці,
// без необхідності їх дублювати для кожного контролера
server.addProvidersPerServer(BodyParser, MySQL, Logger);

Що ми тут бачимо? — Усі необхідні залежності цього контролера указані в конструкторі (за виключенням Request, Response). Чітко видно, що вони виконують певну роботу і ця робота не порушить роботи будь-якого іншого контролера.

Якщо якась із залежностей, перерелічена у конструкторі, має купу своїх залежностей — нас це не цікавить, бо ми спираємось, що називається, на інтерфейс, а не на конкретну реалізацію. Іншими словами, у нашому випадку — нас цікавить лише API вже готових об’єктів класів BodyParser, MySQL, Logger. Ми не піклуємось про те що вони у своїх конструкторах мають якість там свої залежності...

З такою архітектурою можна будувати хоч дві, хоч п’ять сотень контролерів, і код буде читабельним, тестабельним, а тому його можна буде легко підтримувати.

в принципі, для того, шоб дотримуватись solid, зовсім необов’язково писати в джава-стилі з класами і інтерфейсами

В JS для юнит тестов DI не особо нужен как бы www.npmjs.com/package/proxyquireify

Добре, DI не потрібен для модульних тестів. Що скажете про пів сотні middleware, про залежності між ними, і про порівняння архітектури middleware з грою в «испорченый телефон»?

то что написано выше и есть middleware с сервис локатором впилененым в сервер. но глобально это ничего не меняет. как было middleware так и осталось. Зависимостей между handlers нету ни в первом, ни во втором случае, пока их туда не привнесут криворукие девелоперы — единственное от чего зависят смежные request handlers контракты обьектов request, response. ООП в подходе с сервис локатором также нет.

Ок, давайте уточню, що під middleware я маю на увазі Connect/Express/Koa... middleware, тобто ланцюжок колбеків, кожен із яких викликає next, аж до req.send(), наприклад.

По-суті, цей ланцюжок колбеків робить те саме, що робить композиція в ООП, але з дуже суттєвою відмінністю в плані:

1. Вирішення залежностей вхідних сервісів. Візьмемо bodyParser чи session, які як правило, записують

app.use( bodyParser() )
незалежно від того чи треба це кожному middleware чи ні — архітектура не дозволяє зробити це чітко. Бо якщо ми понаписуємо щось типу
app.post('/someurl', bodyParser, session, ...)
 то у нас не буде гарантії, що ці bodyParser, session не продублює ще якийсь middleware роблячи одне й те саме...

2. чіткості вхідних параметрів, бо традиційно чи не кожен сервіс middleware робить свою роботу над об’єктами req, res змінюючи їхні властивості. Тобто коли я пишу черговий middleware, мені треба продивитись усі попередні app.use(), app.all((), продивитись їхній код, оцінити чи вони мають вплив на мій middleware, оцінити які саме параметри req, res до мене долітають...

Само-собою, що для мікросервісів указані відмінності маже не помітні, бо їх там усього пару десятків. І, як ви пишете, обробники запитів майже не залежать один від одного. Але думаю, що вже можна писати щось поскладніше, ніж мікросервіси на Node.js-фреймворках.

Обьясните пожалуйста, в чем разница между первым и вторым случаем кроме синтаксиса? Разве в первом случае, если мы напишем


app.use( bodyParser() )
app.use( session() )
app.post(’/someurl’, someHandler);
это будет не то же самое для единичного случая, что и во втором:

app.post(’/someurl’, bodyParser, session, someHandler);

?

Якщо у нас немає інших middleware, то для someHandler це буде одне і теж. Але якщо у нас є ще якісь плагіни у формі middleware, то треба проглядати і їх, наприклад такі:

app.use(’/someurl’...)
app.all(’/someurl’...)
app.param(...)

Бо вони також можуть виконуватись у випадку

app.post(’/someurl’, bodyParser, session, someHandler);
ООП в подходе с сервис локатором также нет.
Я знаю лише про такий DI, робота якого полягає у створенні об’єктів класів, попутно вирішуючи їхні залежності, указані в їхніх конструкторах. Тобто саме справжнє ООП.

Відверто кажучи я не зрозумів у чому проблема

пів сотні middleware
, якщо у Вас виникають конфлікти між middleware я раджу розбивати їх у окремі роутери www.terlici.com/...09/29/express-router.html

Так, самі обробники у якості контролерів справді не проблема розкидати по текам, але я кажу про сервіси для обробників, такі наприклад, як bodyParser, session і т.д.

мені здається, шо ви не відповіли на задане вам запитання. Бо я з вашого прикладу бачу переваги ооп-архітектури, але не бачу ніяких переваг ооп-фреймворків. Бо робити таку архітектуру, як у вашому коді, можна і на експресі, і на голому пхп, і де хочеш.
Які переваги тут дає тайпскріпт? Хіба шо цю DI магію, коли інформація про залежності береться з сигнатури метода, а не лежить десь окремо

А мені здалось, що коли я гово́рю про архітектуру middleware-фреймворка і ООП-фреймворка, то стають очевидними недоліки middleware-фреймворка. Хіба ні?

Я ж згадував і про складність прослідковування у пів сотні middleware, і згадав про порівняння middleware-архітектури з «испорченным телефоном», і про тестування.

loopback.io позиціонується себе як enterprise nodejs framework
а ще є Sails.js як альтернатива
Sails очень плохо кастомизируется. Модуль для websocket работает с костылями, причем не документированными, подружить websocket с OAuth — вообще печаль беда. Как по мне, он подходит только для простых проектов аля rest api(get, create, delete, update). Во всяком случае так было год назад. Сам сейчас переписываю c sails на express, и с express все гораздо проще.

Чем именно проще, в том плане, что сам все пишешь с нуля и собираешь под себя?

И Sails и Loopback имеют в своем коре Express зависимость, по-этому проблема кастомизации несколько надуманная

Чем именно проще, в том плане, что сам все пишешь с нуля и собираешь под себя?
Именно + в проекте будет ничего лишнего
И Sails и Loopback имеют в своем коре Express зависимость, по-этому проблема кастомизации несколько надуманная
То, что они работают на express не отменяет факта присутствия жесткой архитектуры в этих фреймворках, кастомизировать которую не всегда есть возможность, а если и есть — это гораздо больший геморрой, чем написать это с голым express. Для примера — можно попробовать написать websocket api с авторизацией через oAuth на sails и на express — сразу будет виден результат.

А Hapi.js пробовали? Если да, то как он вам?

Ні, майже не дивився на нього, порівняв лише його швидкість, глянув на його зірочки на github, пробігся по документації.

Мені більше підійшов restify, який я зараз форкнув і зробив restify-ts, бо у парі з Angular, від фреймворка потрібно було щоб він давав лише REST API, без зайвого функціонала у вигляді обробки в’юх на боці сервера.

Про те, що TypeScript це НЕ мага-круто, може говорити лише той,
хто вивчив JS та розуміє всі його сильні та слабки сторони.

Якщо ви не змогли зрозуміти JS, то це не значить, що всі навколо такі самі ;)

Про те, що TypeScript це НЕ мага-круто, може говорити лише той, хто його не використовував, або той, хто поколупав його пару годин, зачепився за якусь шараховатість у вигляді відсутності TypeScript-бібліотек, або у неможливості написати TS-вираз з потрібною сігнатурою і т.д., і пішов далі незадоволений.
...или тот, кто пишет под javascript на функциональщине) ну там Elm, ClojureScript, PureScript и все такое. :-)
Виходячи з вищезазначеного, думаю час вже створити нарешті сучасний Node.js-ООП-фреймворк. Я вже попи́сую свій, але ще рановато його представляти.
о! Респект! будет интересно его глянуть, когда он будет готов)
Може вже є такі фреймворки
может www.totaljs.com .. помню когда-то его смотрел — мне понравился. Правда не знаю, насколько он ООП, но его позиционируют как laravel- и django-подобный фреймворк (т..е. по идее на нем можно довольно крупный проект поднять).

Проглядав я і totaljs.

По-перше, він позиціонує себе як фреймворк без єдиної залежності... що є досить сумнівним рішенням, хоча й зручним в плані «вивчити одну документацію, замість десяти (якщо б він залежав від сторонніх модулів)». Сумнівним, бо розробник намагається у ньому писати майже усе сам, включаючи драйвери для пошти, бази даних і т.д.

По-друге, він написаний на сумновідомому лапша-синтаксису, ще й майже усе в одному файлі, та ще й має купу глобальних змінних, типу:

global.TRANSLATE = function(name, key) {
	return F.translate(name, key);
};

global.TRANSLATOR = function(name, text) {
	return F.translator(name, text);
};

global.LOG = function() {
	return F.log.apply(F, arguments);
};

global.TRACE = function(message, name, uri, ip) {
	return F.trace(message, name, uri, ip);
};

Що є «таким собі рішенням», бо з таким підходом на витік пам’яті можна неявно натикатись досить легко, а вигоди від того... — не буде зайвих імпортів?

Мірявся тільки що... кхм, показниками з Koa. Цікаво, начебто стандартний Hellow World роблю з версією 1.2.4

var koa = require('koa');
var app = koa();

app.use(function *(){
  this.body = 'Hello World';
});

app.listen(8081);

При тому що у нього й роутера то немає (і взагалі, прямо скажемо — майже ніфіга немає), споживання пам’яті більше ніж у express (77 MB проти 50 MB), з приблизно однаковим req/sec.

Цікаво чи з другою версією щось змінилось. Бебеля не маю, може хто інший порівняє прості хелоуворди і споживання пам’яті, наприклад за допомогою pm2?

Оо, это оно жретъ 77 и 50МБ чтоб отдать хелловорлд и 2.5 заголовка?
я щас не стебусь, а вполне серьезно.

Це споживання пам’яті для роботи веб-сервера з application, який виводить Hello World. Думаєте PHP покаже менші результати?

реакт демка — drive.google.com/...I3_NgKT_J1Wlg4dnF6SlFtSGs , ну да ладно, реакт голый, там ни роутеров ни еще каких-то плюшек.
но вот амп демка, — drive.google.com/...I3_NgKT_J1TmpYV1JzZU5rX1k — с роутерами т.д, как экспресс. еще и вебсокеты поднимает.

Указана пам’ять (70 і 50 МБ) займається не просто при старті процеса, а при тестах:

ab -n 50000 localhost/

Запустите цей тест, завтра він завершиться, скажете результати =).

P.S. node-фреймворки виконують цей тест за 20 секунд.

ну я тогда завтра запущу, успеется)

а нет, не могу молчать, когда в интернете кто-то не прав.
Node.js v7.2.0

const http = require('http');
const port = 1337;

const server = http.createServer((req, res) => {
    res.statusCode = 200;
    res.end('Hello world');
});

server.listen({port: port}, () => {
    console.log(`Server running`);
}); 
drive.google.com/...I3_NgKT_J1RENtSlhGQlhnMG8


ReactPHP PHP 7.0.8 (на php, без ev, libev, libevent и т.д.)

<?php

require 'vendor/autoload.php';

$app = function ($request, $response) {
    $response->writeHead(200, array('Content-Type' => 'text/plain'));
    $response->end("Hello World\n");
};

$loop = React\EventLoop\Factory::create();
$socket = new React\Socket\Server($loop);
$http = new React\Http\Server($socket, $loop);

$http->on('request', $app);
echo "Server running";

$socket->listen(1337, '10.0.2.15');
$loop->run();
drive.google.com/...I3_NgKT_J1UVIxM1l1OVQzVWc

ну или как-то так.

Не знаю на якій машині ви тестували, але 567 req/sec для голої ноди — мега-мало. На моїй машині вона 3400 req/sec робить без конкуренсії, а з конкуресією 15 users робить майже 7900 req/sec. Ну то таке.

Ну а про пам’ять чого промовчали?

Не знаю на якій машині ви тестували
Ubuntu 16.04.1×64, 2 ядра х3.4Ghz, 2GB ram, через сеть 300мбит.


3400 req/sec робить без конкуренсії, а з конкуресією 15 users робить майже 7900 req/sec.
ну ладно, хотите на локалхосте меряться, давайте на локалхосте:

нода — drive.google.com/...I3_NgKT_J1VWdiZVBtSThIRVU
реакт — drive.google.com/...I3_NgKT_J1cVdrdkFSLVItbUU
код тот же.


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

В ноді дуже просто міряється пам’ять, за допомогою:

console.log( process.memoryUsage().heapUsed )

З PHP не в курсі як

в пхп
memory_get_usage(true); memory_get_peak_usage(true);
только я ему не верю, в винде на реакте оно метров 5-7 будет показывать под нагрузкой в таймере, а не реальное потребление, которое будет в той же винде 15+. в никсах memory_get_peak_usage(true) показывает 2мб при реальном ~7мб.
в cgi/fcgi работает вроде более корректно.

так что даже через top смотреть будет более актуально.

Між іншим, я перейшов на VPS на Digital Ocean, бо мій shared-хостер заявив, що я перелімітив 128 MB пам’яті, коли на мій сайт зайшло онлайн чоловік 300 (з ДОУ). І це при тому, що на той момент я використовував KohanaFramework — один з найекономніших PHP-фреймворків (PHP v5.6.4).

Express.js споживає 50 МБ, коли відпрацьовує указану вище кількість у 50 000 запитів, але без конкуренції. Коли ж додаю конкуренції під 100, то споживання збільшується до 70 МБ. Тобто до 128 МБ ще дуже далеко.

Коли ваш ReactPHP будуть ставити на продакти, тоді й серйозно можна буде його сприймати. Поки що це якийсь хак PHP, а не PHP.

ну вы не сравнивайте php в режиме cgi, который вращается на бедном апаче, с инстансом ноды или реакта или приложением на дотнете.

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

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

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

Нічого, ось допишу свій Node.js-фреймворк, думаю PHP-шнікам сподобається (якщо вони люблять ООП). З фічою async/await взагалі буде майже усе зразу їм зрозуміле...

нуу не знаю, я как пхпшник, любящий ооп, выбрал бы шарпы, где async/await из коробки уже года 4.

Кажуть TypeScript дуже схожий на C#, у них один й той самий «батько».

Поки що посиджу на TypeScript, хай там що не кажуть, а перспективи у нього великі. Якщо ж мої сподівання не виправдаються, то може теж перейду на C#. Це одна з найзатребуваніших мов програмування на ринку праці.

а проблема з дебагом typescript якось вирішується, зокрема з this?

Я не знаю про такі проблеми. Що вони собою являють?

При дебагу якщо навести на this він не буде реальним this, так як typescript перетворює this в _this, і при дебагу з sourceMap не завжди вийде продебажити typescript

Що не усе дебажиться указуючи на *.ts версію файла — це правда, бо не усі конструкції з TS є у JS. Справді інколи дебаг перекидає на *.js файл, але з тим можна миритись, особливо якщо при компіляції «tsc —target es2015», або вище.

Проблем із this я не зустрічав. Дебаг роблю у VS Code (взагалі цей безкоштовний редактор для TypeScript дуже добре підходить, рекомендую). Хоча цей дебаг мабуть підійде лише для бекенда, фронтенд прийдеться дебажити у браузері.

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

Давайте поговоримо про ES2015+ OOP-фреймворки під Node.js
нет

JS дає чудові можливості для ФП, а тут все ООП і ООП..

JS дає чудові можливості для ФП, а тут все ООП і ООП..
так. але ж самі ж фронтендери обирають ООП стиль :)
при цьомоу наголошуючи що за ФП — майбутнє.

то як з українською мовою — є опитування, а є статистика вибору мови в банкоматах, або на сайтах.

і те що кажуть люди про те яка мова для них рідна, зовсім не збігаєця з тим яку мову вони обирають коли мають вибір.

так і з ФП. на JS тепер можна вибрати парадігму. от і побачимо як ФП переможе, коли переважна більшість фронтендщиків обирає ООП :D

не впевнений в статистиці, але думаю, що немала частина фронтендерів — вихідці з джавів і сішарпів. Тому і пишуть в ОО-стилі.

причини вибору не мають значення.

мова ж про статистичний тренд.

річ у очевидному багу логіки — якщо більшість обирає Х замість Y, то про який мейнстрім Y у майбутньому кажуть фанати Y?

але фани Y цього не помічають :) вони роками впевнено казали і казатимуть що Y буде мейнстрімом. навіть тоді, коли самі пишуть у ООП парадигмі :D

переважна більшість фронтендщиків обирає ООП
Это не совсем так. Большинство фронтэнщиков ничего не выбирают. Они часто страдают и мучаются от забагованного кода в императивном стиле, который был написан также не выбирающими бэкэндщиками(или фронтэндщиками, которые к такому уже привыкли). Возможно, когда рынок насытиться и людей станут реже заставлять лезть в то, в чем они не разбираются и разбираться не планируют, мы будем видеть больше декларативного кода во фронте. И сильная популярность React, Rx, Elm, того, что пишут во всех новых книгах по JS и документациях в либах/фреймворках, говорят на конференциях — этому достаточно сильно способствует.

Сама реализация языка сильно толкает отказаться от ООП-шного псевдо-классового кода.
То как работает псевдо-классовое наследование
И то как прототипное (OLOO)
И сразу вдогонку забавный видос, в котором паренек рассказывает, почему можно вообще отказаться от наследования в JS: www.youtube.com/watch?v=wfMtDGfHWpA&t=

великий плюс за Elm, Rx і звісно Кайла Сімпсона)

вы научитесь отличать популярность от хайпа вначале. А потом уже приступайте к анализу причин.

Потому что я не умею дискутировать о том как популярен Эрланг у мучающихся на Джаве

научитесь отличать популярность от хайпа вначале
Расскажите подробней. В моем понимании эти 2 понятия отличаются только тем, что хайп может не перерасти в популярность и с такой-же скоростью, как появился, потухнуть.

В мире JS декларативный стиль написания это не хайп, а скорее тенденция, которую можно объяснить здравым смыслом.
мучающихся на Джаве
Псевдо-ООП в JS достаточно болезненная тема, никто не сравнивает с Java.
В моем понимании эти 2 понятия отличаются только тем, что хайп может не перерасти в популярность и с такой-же скоростью, как появился, потухнуть.
в определении слова популярный лежит ответ о разнице.

но ок, давайте договариваться о терминах.

ПОПУЛЯ́РНЫЙ, (от лат. popularis — народный).
1. Общедоступный, понятный всем по простоте изложения. Популярный очерк. Популярное изложение. Популярно (нареч.) излагать, писать (об авторе).

это реакт то понятней ангуляра широким массам трудящихся ?

второе значение — популярное — это то что используют большинство. большинство, это те самые мухи которые не могут ошибаться, если вас это утешит. это Elm то массово используют?

hype {имя существительное}
активная реклама, пускание пыли в глаза
hype {прилаг.}
клевый
to hype {глаг.}
крикливо рекламировать

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

и, не забывать о Gartner Hype Cycle

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

прошли годы... ну и чё?

Псевдо-ООП в JS достаточно болезненная тема
для кого болезненная? для адептов функциональщины?

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

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

но перед этим вначале надо четко отличать — популярность от хайпа.

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

а может правее Andrey Listochkin — Anti hype как не гнаться за технологиями и начать жить
www.youtube.com/watch?v=xPFRUM_oDKA

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

говорят на конференциях
buzzwords и bla-bla-bla да, отличный фундамент для прогнозирования будущего.
это реакт то понятней ангуляра широким массам трудящихся ?
Естественно. С этим даже никто не спорит. Другое дело, что React в большинстве случаев тянет за собой целую кухню других вещей. Но даже в плане популярности, можно заметить такую штуку: ashleynolan.co.uk/...=email#js-framework-usage . Более хайповый сейчас Vue. И я ничего не имею против angular2 и считаю, что он тоже вполне ok.
тусил в блогах функциональщиков, то там да, сплошь было — все, закапывайте джаву. на ней останутся только недопрограммисты
Речь вообще не об этом. Не про настроение кто лучше/кто хуже. Всех так задолбал tooling, что народ постоянно говорит, что надо выбирать инструменты в зависимости от задачи в первую очередь. Другое дело, что комьюнити не зацикливается на ООП, а берет с этих парадигм лучшее. Например в том же React большинство инициализирует компоненты через class MyComponent extends React.Component, при этом популяризируют тему pure(functions/Components), Higher-Order Components, Immutability и т.п.
для кого болезненная? для адептов функциональщины?
Нет, для всех, кто разобрался и может писать в любом стиле. Не зря же TypeScript придумали и так хвалят. Значит в чистом JS им многого не хватало.
С этим даже никто не спорит.
то есть популярней пока «ангуляр» (в кавычках, потому что И подобные) а не реакт. конечно с уточнением — пока.
Другое дело, что React в большинстве случаев тянет за собой целую кухню других вещей
о, отлично что мне не пришлось об этом упоминать :)
Более хайповый сейчас Vue.
да. пока хайповый. но учитывая что он из того же «ангуляр» теста, что более вероятно

предположить популярность Vue в будущем,
или
предположить популярность React в будущем, с учетом что придется переучиваться концептуально, и осваивать «целую кухню других вещей»?

Например в том же React
это не важно что там в нем.

важно — то что выше написал — предположение о вероятности события — популярность чего-то в будущем.

Другое дело, что комьюнити не зацикливается на ООП
ок. давайте по другому.

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

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

или
когда вы говорите — автомобилисты то-то и то-то — вы имеете ввиду среднего автомобилиста, или Нассера Аль-Аттия?

Нет, для всех, кто разобрался и может писать в любом стиле.
так для всех(большинства) ИЛИ для тех кто разобрался и может?

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

посудачить о Нассере — это не тоже самое что стремится попасть на Париж-Дакар лично.
понимаете?

популярность и хайп — различаете?

между тем что показывают на парижской моде, и тем что носит обычная женщина — разницу видите?

Ладно, я понял, что вам нравится философствовать, что более популярное и почему. Мне это не интересно. У меня с вами несогласие только в этом:

але ж самі ж фронтендери обирають ООП стиль
Выбирают то, на чем уже написан проект. Выбирают то, за что больше платят. Выбирают то, что им ближе по идейным причинам. Но ООП они вообще никак не выбирают. Выбирали бы ООП, писали бы на Java или C# и не лезли во фронт с его JS. Или разницу между «вынуждены писать на» и «выбирают» вы тоже хотите философски оспорить с позиции среднего автомобилиста?
Мне это не интересно
вот именно.

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

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

но вот что дело в том что именно — выбирают, а не

на чем уже написан проект
 да, оспариваю.

потому что кто-то же выбрал скалу, хаскель, эрланг, реакт, elm.

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

кто-то же служит в элитных войсках? кто-то же гоняет за свои деньги на париж-дакаре?

а насчет философствования, то его еще не было.

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

ну и конечно непрозрачно намекнул на кашу в голове :)
адепты, такие адепты.
или чаще — «богема».

«Linux скоро станет самой массовой ОСью на десктопах! потому что у меня, красноглазика он на всех компах, и даже девушку заставил его поставить!»

Есть шутка: линуксоиды каждый год объявляют годом десктопного линукса

да, причем я ее слышу года с 2002го :)

потому что уже тогда они утверждали что вот-вот :)

адепты, такие адепты.

тоже самое с функциональщиной :)
страшно далеки от народа светлые умы что в ней.

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

www.youtube.com/watch?v=F_nZgA4AvA4

а бохема на форумах снобиствует, ведь быть в рядах функциональщиков модно.

При этом сама нифига не знает об ООП, ибо в джаваскрипте такого никогда и не было, а многие из них кроме как джаваскрипта ничего не видели. Ну то такое, лично я уже привык. Чем более человек ограничен тем более он категоричен. О, даже рифмуется))

П.С. да и вообще каждый хвалит то что ему нравится. Такова суть людишек.

отож.

И.
Как-то в одном из подкастов радио-т, пару лeт тому обсуждали как комьюнити в действительности реагирует на новье.

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

Я же видел вживую когда не последние программисты бурчали на лямбды и стримы в джава 8 — понапридумали хрени...

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

Мне неинтересно обсуждать это с вами. Вы явно не в курсе, что RxJs начал набирать популярность именно благодаря Angular и на что больше идеологически похож Vue, которые сами пишут, что они «view layer only». Вы даже не заметили, что я не популяризирую идею, что на фронте будет исключительно ФП. Я говорю о том, что существует тенденция отказываться от иллюзии ООП на JS, т.к. его на фронте, до появления TypeScript, никогда не было в адекватном виде. А было прототипное недоразумение, которое кому-то что-то напоминало. И именно из за непринятия этого недоразумения и появляются различные Elm, ClojureScript и даже тот-же TypeScript. А людей, которые добровольно выбирают это недоразумение сейчас — не так много, как вы думаете.

Люди которые во фронте и прям сознательно выбирают ООП, а не непонятно что, обычно пишут на TypeScript, но таких 1 из 10. Остальные пишут в стиле, который диктует фрейвморк/фирма/рынок.

а вы не заметили что я писал не о реакте вообще-то? Он так, как пример пика моды приведен.

И написал почeму я думаю так как думаю.

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

В айтитехеологиях аналогом монетки является количество потраченного времени на изучение, освоение технологии. Личного времени. И мозговых усилий.

А то что доклад прошел в переполненном зале интересующихся — не монетка. Люли пришли на спектакль.

а вы не заметили что я писал не о реакте вообще-то?
Заметил, только я не понял, при чем тут я. И при чем тут выбор фронтэндщиков(по вашим словам) в пользу OOП парадигмы, которая непопулярна хотя бы тем, что ее в чистом JS нет.

Псевдо-ООП-шный говнокод(которого именно много, а не нормального ООП-шного, которого несравнимо мало) становится непопулярным, все остальное становится популярным. С чем тут спорить?

Может и так, не того выбрал ☺

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

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

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

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

Главная — выбор комьюнити. Никто фронтендщиков не загонял легаси проектами в ооп. Они сами ж его выбрали.

А потом да, появляется Scala которая убъет Джаву. А до этого руби убил пых. А потом питон убил обоих.

А nosql убил sql. А линух убил винду на десктопах.

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

А потом да, появляется Scala которая убъет Джаву. А до этого руби убил пых. А потом питон убил обоих.
сейчас вроде другая буча поднимается (или уже поднялась): что Elixir убьет Ruby, ибо у Elixir есть Phoenix framework, который типа круче рельсов)
Причем эта буча идет где-то уже полгода (может больше).
А убьет ли — хз) Лично я запасся попкорном на этот счет)

От elm осталось двоякое впечатление, с одной стороны круто, фп, иммутабельность, с другой стороны кода получатся довольно много если сравнивать с React/Redux

На любителя. Мне нравится, но я тоже не готов перейти 100% на него. Зато есть продуктовые фирмы, в которых народ жутко прется по Elm и где разработчикам хорошо платят. И это здорово, работать в кругу единомышленников, которым нравится то, на чем они пишут.

Давайте уже забудем JS/Python/PHP/etc. наконец. Задолбал он за 5 лет — кругом сплошной JS. Поговорим о С++/Java/embedded, или как на 1-ядерном андроид, на яве, читать USB со скоростью 250 кб/с. Вообщем о более интересных вещах.

как на 1-ядерном андроид

О, привет, человек из прошлого! Как там второй андроид, уже вышел?

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

Twitter перевели ВЕСЬ мобільний трафік на React + Node.js

Лінк

Хтось там писав про бізнес-логіку? Нода для туду-шок?

все-таки вирішили з кінцями втопити твіттер

Нічого не маю проти Ноди і Реакта, але твіттер — не найкращий приклад.

«Не найкращий приклад» — бо чого?

Нода, як частина фронтендівського стека, бекенд для реакту — хороше рішення. Писати на ноді бізнес-логіку? Ні, дякую.
До речі так само для интерпрайзу не дуже придатний той самий Го. Вибір лишається невеликим: Симфа або Джава. Ну і Скала ще, якщо джавістам на роботі нудно.

Впевнений, що ви навіть поруч не сиділи з тим, хто пише бізнес логіку на TypeScript під Node.js. Якщо б сиділи, чи навіть самі намагались писати, то... не перестаю хвалити TypeScript — це мабуть не сильно відрізнялось би від тієї самої Java. Хоча я сам теж і рядка на Java не писав, але в теорії, усі мови, які мають статичну типізацію, дуже суттєво спрощують написання бізнес логіки.

Пишучи на TypeScript, ви вже зразу можете писати на 100% готову документацію по API.

Якщо ви маєте на увазі незручність у вигляді асинхронності, то async/await вам може спростити асинхронний код до «синхронного вигляду»...

Хоча я сам теж і рядка на Java не писав, але в теорії, усі мови, які мають статичну типізацію, дуже суттєво спрощують написання бізнес логіки.

TS частично решает проблему Ноды. Нода прогрывает Java/.NET в первую очередь из-за рантайма. У Java/.NET он многопоточный асинхронный, у Nodeм — однопоточный асихнронный и с куда более убогой поддержкой примитивов. Как следствие скейлить ноду можно только кластеризацией и горизонтально, если речь идеть о CPU-intensive логике — это не всегда удобно. В целом Node удобна не для бизнесс логики, а для проксирования запросов на какое-то I\O(микросервисы), работать с CPU и примитивами попрежнему намного удобней и эффективней на Java/C#. Поэтому и ооп-императивный стиль кодирования для Node.js это горожение никому ненужного слона-носорога стоящего на табуретке.

и с куда более убогой поддержкой примитивов

Ну ES2015+ вже додали Symbol, Map(), Set(), WeakMap(), WeakSet()... work in progress.

В целом Node удобна не для бизнесс логики, а для проксирования запросов на какое-то I\O(микросервисы)

А можна більш детально, що саме є суттєво-гіршим при написанні TypeScript-коду, в порівнянні з Java/.NET? Маніпуляції з числами, рядками, масивами у них є на стільки кращими, що це є вирішальним?

Поэтому и ооп-императивный стиль кодирования для Node.js это горожение никому ненужного носорога
Треба більше аргументів...
ооп-императивный стиль кодирования для Node.js это горожение никому ненужного слона-носорога стоящего на табуретке.
До речі, якщо ви говорите що про важкість ООП, то тести для мого restify-ts показують, що навіть при нявності ООП разом з DI, швидкодія і споживання пам’яті майже такі самі як у Express.js. Якщо бути точним, то restify-ts споживає десь на 5 МБ більше, але швидший десь на 50 req/sec.

Якщо цікаво, можете самі пересвідчитись. Приклад для Hello World тут github.com/.../master/src/restify-ts.ts

имхо, тайпскрипт придумали джависты, которых тошнило от нестрогой типизации и не хватило фантазии разобраться в прототипном наследовании ;)
ЕСМА2015/2016 — правильный путь развития джаваскрипт, не нужно псевдо-скрипт оберток всяких

тайпскрипт придумали джависты

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

которых тошнило от нестрогой типизации

Почти тру — других тоже тошнит от такого бреда

и не хватило фантазии разобраться в прототипном наследовании ;)

Фолсе — это прототипное наследование просто никому не нужно.

ЕСМА2015/2016 — правильный путь развития джаваскрипт

Упс, там уже ввели классы =)

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

Отчасти кстати с этим плачем согласен — в тьме случаев на фронте не нужны классы. Но как с паттернами ООП, впихуемыми где попало — так и жду тру ООП версию jQuery.

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

var Class = {
property1: value,
property2: value,

init: function() {

},

method1: function() {

},

....
}

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

К простым вещам можно отнести ситуацию когда нам не потребуется более одного экземпляра объектов какого-то класса.

А на хтмл фронтенде это частая ситуация. Да еще и дум элементы, которые и так инкапсулирую свое состояние. На кой городить еще какую-то свою иерархию классов?

В SPA приложениях да, классы, или их эмуляция, вполне к месту

Упс, там уже ввели классы
Ні. То синтаксичний цукор.

внутри-то да. но в чем разница «с точки зрения пользователя»? отсутствие VMT, чтоб её напрямую модифицировать?

Ні, на жаль, різниця таки є. Ось таке збочення проходить і у ES2015+:

class A{ }
A instanceof Function // true
A instanceof Object // true
const a = new A
a instanceof Object // true

Чому збочення?
Function instanceof Object // true

Я в курсі. Але коли клас є об’єктом, і його інстанс є об’єктом — це саме справжнє збочення, а не ООП.

На мой взгляд, самое забавное, что можно делать так:

const a = class {}
А это значит... Что можно делать фарбики классов! :D
Вот где у настоящих ООП-шников крыша потечет.

Ну ок, добавлю це до моєї книги збочень.

Визначення ООП, по вашому? Якщо «все є об’єктом», чому клас не має бути об’єктом? Така позиція дозволяє зокрема розглядати new як виклик метода. Інакше це операція за межами об’єктної моделі.

Наявність top type aka universal base class (Object) це більш правило ніж виключення.

чому клас не має бути об’єктом?

Тому що клас не є обєктом. Це форма(тип) для створення обєктів. Ще дурні запитання будуть?)

Тому що клас не є обєктом.

Я не знаю жодного визначення „ООП”, яке б включало такий пункт.
en.wikipedia.org/wiki/Metaclass

wiki.c2.com/...efinitionOfObjectOriented п.4
wiki.c2.com/?DefinitionsForOo
wcook.blogspot.com/...or-simplified-modern.html sect. Class, Purity

Це форма(тип) для створення обєктів.

en.wikipedia.org/...ogramming)#Class_vs._type

Я удивлен вашими познаниями ООП по википедии. Продолжайте дальше.

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

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

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

Вся машина это результат создания объекта. Как там в цепочке все работает сути не меняет. Мы не создаем машину путем клонирования, мы ее создаем путем инициализации класса(типа, места где описывают машину). Собственно колесо это может быть инстансом типа «колесо».

Я где то так же все это вижу) а вот твой оппонент, судя по всему, должен быть 3.14зжен ссаными тряпками за свою ересь)

Так он просто хочет повы.бываться как и прочие хейтеры ООП. Они будут нести любую чушь лишь бы спорить)

Це форма(тип) для створення обєктів.
статичні методи та проперті виступають проти такого твердження.
а ще згадується метапрограмування з «змінна типу <клас>» — усякі там дженерики та чомусь згадав дельфійский var a: TClass;
статичні методи та проперті виступають проти

Їх ввели для зручності і економії памяті. Так, вони не вписуються в тру ООП. Але реальна розробка це не пустословіє когось там а робота, де використовують те що треба.

метапрограмування з «змінна типу <клас>» — усякі там дженерики та чомусь згадав дельфійский var a: TClass;

А так, дженерики. Ок, то хіба вони виступають інстансом? Вони знову ж таки виступають типом, яким задають поведінку іншого типу.

Ок, то хіба вони виступають інстансом?
так, поганий аргумент вийшов. В данному випадку просто як (мета-)змінна, жодного метода не викликається.
Але коли клас є об’єктом, і його інстанс є об’єктом — це саме справжнє збочення, а не ООП.
Вы еще раз подтверждаете, что дедушка Алан Кей был таки прав, когда написал «I’m sorry that I long ago coined the term „objects“ for this topic because it gets many people to focus on the
lesser idea. The big idea is „messaging“...
».

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

Design Principles Behind Smalltalk (1981)
news.ycombinator.com/item?id=13611222

таблиця віртуальних методів

классы все равно на прототипах работают

тайпскрипт придумали джависты
Джависты ангуляр придумали. А вот TypeScript и Rx придумали в Microsoft.

не, ну мама драконов и на яве писал, но основное влияние там больше от Flex-а было (как на какой-то конфе ещё давно кто-то из прошлой Core team раcсказывал)
но слышать то, что всё лучше от Явистов — таки приятно, чё )

не, эт Майкросовтовское творение, под C# дизайнили...
но вещь годная, но ясен для проектов уровня, где сам NG2 юзать имеется смысл... просто прикручивать какой-то слайдер к уже готовому сайту на жиКвери, с его использованием, скорее-всего, никто не станет.

как только первые альфы NG2 появились, пришлось и с ним подружиться, и честно — не жалею.

та пишіть собі на експресі в ОО стилі, на то він і unopiniated, minimalist framework

я думаю що на Node.js-фреймворках можна будувати значно більші проекти, ніж на PHP.
треба не думати — а будувати.
А що таке багато коду для ініціалізації в контексті PHP? — Правильно, він її буде робити за кожним запитом, в кращому разі він делегує ініціалізацію на Dependency Injector
так, э така проблема. але, зазирніть у код Magento — щоб «здивуватись» що там ну чиста Java.

коли буде система на ноді хоть на чвертиночку така ж складна як Magento? а це ще не сама складна система на php.

але все одно це не зрівняти з Node.js-фреймворками, які усю ініціалізацію (на рівні application) роблять єдиний раз при старті...
але для цього э Java, C#, Go

чим мова JavaScript краща за Java, C#, Go для великих/складних проектів?
а може рантайм V8 кращий за JVM, CLR .NET?

але для цього э Java, C#, Go
чим мова JavaScript краща за Java, C#, Go? а може рантайм в js кращий?

Дешевшою розробкою, якщо говорити про бізнес побажання. Простішою в освоєнні.

Щоправда, я ніколи не писав складних проектів на чистому JavaScript. Раніше хоч і писав свій код начебто на JavaScript, але в контексті першої версії Angular, де не потрібно було глибоких знань JS. Зараз же я теж пишу виключно на TypeScript, і про чистий JavaScript мені важко щось говорити в плані складності освоєння. Так можу сказати за TypeScript...

Дешевшою розробкою, якщо говорити про бізнес побажання. Простішою в освоєнні.

Для цього вже давно є PHP. Справляється навідмінно з даними вимогами. Для іншого є

Java, C#
Дешевшою розробкою
чого? розробкою — чого саме?
Простішою в освоєнні.
php — простіший. не такий звісно як в Zend та Symfony. але це визнано.

також відомо що фронтендщиків, яки знають не тільки jQuery — теж дефіцит.
то може JS і не такий простий, як здаєця?

або, — ота його простота боком вилазить коли проект складніший мікросервіса?

Щоправда, я ніколи не писав складних проектів на чистому JavaScript.
отож.

про те й мова — а хто писав? назвіть складні проекти з серверсайдом на JavaScript? якийсь тудушнік, або канбан-дошка тіпа якогось Trello? де на сервері нема майже ніякої бізнес-логіки.

Зараз же я теж пишу виключно на TypeScript
ну чекаємо тоді складних проектів на TypeScript.

а поки він себе не показав — то й нема про що балакати :)

чого? розробкою — чого саме?

Ну на даний момент веб-проектів, звичайно ж. Про desctop/mobile-applications поки що рано говорити, хоч і починання є.

В мобайл можливо свіфт все заполонить. Йшли розмови про нього в андроїді. І там дійсно джава це оверхед для мобайл апів. Але чи імплементують його туди... Було би дуже класно, заодно вирішилася б проблема мультиплатформенної розробки.

Ну на даний момент веб-проектів, звичайно ж.
а що такє веб-проект?

згадана Magento — то веб-проект чи ні?

а проекти на Java з ui на ExtJS — то веб-проекти, чи ні?

Простішою в освоєнні.
дуже спірне твердження

я б зказав так ) коли розробка на ноді буде задовільняти потреби замовників по ціні і розробників по зручності як, наприклад пхп/c#/java у їх нішах, тоді можливо вона почне когось витісняти в глобальних масштабах, а до того вона просто екслюзивна штука під спеціалізовані задачі, де потрібна асинхроність.. ) задач з такою потребою збільшилось, ось вона і зайняла одразу цю нішу. а що буде далі ще не дуже відомо (незалежно від того чи з«являться якісь гуд фреймворки )) і залежить більше від глобальних потреб на ринку
і стосовно «більших» проектів, великі проекти можливо будувати на будь-чому ) питання в підтримці і ціні насправді більш актуальне, ніж крутість технології )

і стосовно «більших» проектів, великі проекти можливо будувати на будь-чому ) питання в підтримці і ціні насправді більш актуальне, ніж крутість технології )

Згоден, я кажу про спрощення побудови складних/великих проектів на Node.js. Думаю це вже очевидно що вона таки годиться й для них.

Думаю це вже очевидно що вона таки годиться й для них.
очевидно що не годиться. бо ноді вже не один рік, а складних проектів як не було — так і не чути.

Навіть якщо би годилася то сенсу в цьому нема. Бо є вже опробовані часом потужні рішення на Java and C#. Фронтендщики хай у фронтенді сидять, от скільки вакансій не закрито, хто все це писати буде? А то виходить такий самий цирк як намагання на бекенд мовах писати фронтенд.

Фронтендщики зараз хайпують про ізоморфні аплікації :)

хто все це писати буде?
так, але вище я на те теж натякнув — якщо фронтендщиків не вистачає для фронтенду — то де їх ще набрати і для серверсайду?

Ніде їх не набрати. А бекендерам цей джаваскрипт нафіг не здався. Знають на рівні джейквері чи іншого фреймворка. Тут нема про що говорити — джаваскриптери у яких мова лише недавно дістала базові синтаксичні конструкції яким уже овер дофіга років у інших мовах йдуть усім розказувати що бекенд пишуть неправильно і взагалі його треба писати на джаваскрипті. Це виглядає дуже смішно, хоча вже й викликає відразу. Ну можна на джаваскрпиті написати бекенд, і що? На джаві фронтенд можна написати.

А можно еще написать свой браузер, свои теги, и не в HTML а в прогрессивном JSON стиле, и писать на форумах, что за этим будущее )

ES2015 вийшов у світ менше двох років назад, це визвало цілу революцію по всім фронтам, де використовують JavaScript — це не перебільшення. Потрібен деякий час на побудову складних проектів, а перед цим потрібна була віра в те, що на JavaScript можна писати щось серйозне.

ES2015 дав поштовх великим позитивним змінам, абсолютно не сумніваюсь що Node.js ще покаже позитив...

То що ввели в вашому єс2015 в інших мовах вже існує роками, якщо не десятиліттями. Так що революція за межі джаваскрипту не виходила, нічому виходити. От де дійсно революція так це в шарпі.

абсолютно не сумніваюсь що Node.js ще покаже позитив...

Покаже покаже. Тільки от чомусь на англомовних ресурсах пишуть що хайп ноде джс вже давно пройшов і його вже використовують лише там де треба а не повсюди.

можно ввести еще сколь угодно много новых стандартов, но подвинуть пхп, «противником» которого старается быть нода ей будет очень сложно. потому до сложных языков ей еще далеко, пусть они сейчас и пытаются двигаться в сторону .net, добавляя всякие async...await.
хотя бы потому, что по количеству «плюшек» до того же c# 6.0 они хотяб к ES2030 доплыли. и какой бы крутой не была v8, но CLR быстрее.


чуть конкретнее насчет подвинуть пхп:
пока вы на своей ноде ставите кучу модулей, которые жизненно необходимы, но почему-то не идут из коробки, пытаетесь справиться с callback hell и определить почему неправильно работают promises, а так же мучаетесь с импортом модулей (о да, это так напоминает пхп < 5.1.2), в это же самое время какой-нибудь говнокодер на пхп, которому даже лень ставить композер, тупо wget’ом стягивает архив фреймворка, генерирует каким-нибудь gii или artisan’ом (ну или что будет в его фреймворке) activeRecord-модели и набрасывает логику прямо в шаблоны, просто потому что может.
ичсх это получается более читабельно, чем код на js/ts/dart.


а в итоге похапе под спидами с опкешем + nginx отдают страницу со скоростью плюс-минус 2-5мс, чем набор инстансов ноды, сбалансированных через тот же nginx.


именно поэтому набросать херню, абы работало, для которой node.js и похапе преимущественно используются, на пхп дешевле, быстрей и проще.

Та «повиздихали усi воны» цi складнi проекти)).Я радуюсь что хоть один топик технического характера на Доу появился

Я чего не пойму у вас, радующихся — вы больше ни какие другие сайты не ходите?

«Ура, у меня в ленте фейсбука появился перескпщ статьи с хабра!» — ну так нe торчитe только в фб, или на доу

Koa2 + webpack2 == front&back на typescript 2.1 + async/await из коробки + общие классы моделей для фронта и бека и много других удобных плюшек вместе со 2м ангуляром

Чому так? Ну, по-перше, TypeScript це прямо мега-мега круто! Він дозволяє дуже суттєво зменшувати кількість помилок у коді. А чим менше помилок, тим більший проект можна будувати.

Ох ну это смотря как юзать ТС. Если его и использовать, так c запретом на тип any и что бы проект не компилися при наличии ошибок. Но проблема в том, что при таком подходе нужно дополнительное время на написание всех интерфейсов, а это не всегда оправданно.

Express.js, як говорить нам документація, теж не глобально віддзеркалив нововедення ES2015+.

babel + {любой фреймворк, в том числе express} == глобальне віддзеркалення ES2015+

babel + {любой фреймворк, в том числе express} == глобальне віддзеркалення ES2015+

Ви говорите про можливості писати код на ES2015, типу рефакторинга. Я ж кажу про зміни в архітектурі, нових фреймворках, які з нуля написані з можливостями ES2015.

А что нужно от фреймворка в плане архитектуры с es2015? С express все просто — он просто принимает middleware, вся остальная архитектура руками

Ну, зокрема, використання класів, декораторів, щоб можна було відчути усі переваги DI в ООП:

import 'reflect-metadata';
import {Server} from './server';
import {Request} from './request';
import {Response} from './response';
import {Injectable} from './di';

class Mock{}

@Injectable()
class HelloWorld
{
  constructor(mock: Mock)
  {
    // Here we can to use mock as instances of Mock
  }

  run(req: Request, res: Response)
  {
    res.send('Hello World!');
  }
}

const server = new Server();

server.get('/', HelloWorld, 'run');

server.listen(8080, function()
{
  console.log('%s listening at %s', server.name, server.url);
});

Такий код не просто чіткий виходить, він дуже серйозно спрощує тестування, а значить й підвищує надійність системи.

В теперішньому express.js чи koa.js, і їм подібних, тестування роблять лише інтеграційне, без можливості ізоляції окремих частин на блоки (якщо говорити про великі проекти).

Так все что у вас в коде будет работать и в express, включая инжекторы, при небольших изменениях:

const handler = (ex) => (req, res) => new ex(req, res).run;

server.get('/', handler(HelloWorld));

По поводу удобства тестирования отдельных частей — это зависит архитектуры проекта, а не фреймворка(если мы говорим о гибких фреймворках типа express, hapi, koa и тд.). Вот код с тестами на express:

export const addAction = async (req, { userId, gameId, action, db }) => {
  const game = await db.Game.find({ where: { id: gameId } });
  
  // some code
  
  return gameAction;
};
it('create', async () => {
    try {
      const result = await addAction(mockReq, {mockUserId, mockGameId, mockAction, db});

      expect(typeof result.id).toBe('number');
      expect(typeof result.taskId).toBe('number');
    } catch (err) {
      throw new Error(err.stack);
    }
  });

TypeScript — лажа, ClojureScript наше все

Тут явно не вистачає продовження, типу «...а якщо серйозно, то...»

Ну если серьезно то ООП как подход облажался хотя бы ввиду противоречия базовых принципов

мужики, сворачивайте проекты, ооп облажался.

Схоже, що Тоха знову переплутав четвер з п’ятницею й передчасно напився пива. Ви думаєте чому коментарі у нього такі короткі? — Боїться щоб ми не побачили що у нього вже язик заплутується: сказав щось коротке — усе начебто в нормі. Якщо довгі речення будувати, то там складні звороти — самі розумієте, язик заплутується...

насчет пива вы таки угадали :)
но, это как бы давно описано/обмусолено. я об этом первый раз прочитал в effective java. собственно ввиду этой проблемы и появился подход composition over inheritance

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

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

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

Ничего оно не нарушает. Если родительский клас надо закрыть от наследования то он делается final. То же самое с методами. Кроме того еще есть private, getters, setters. Все давно уже есть и очень хорошее. Т.е. инфраструктура на том уровне уже сделана что даже самый говнокодер будет подталкиваться к написанию правильного кода. А теперь сравните с джаваскриптом где никто даже не знает как там правильно писать. Джаваскрипт сейчас напоминает пхп 4 — там тоже не было ни ООП нормального, ничего. Все лепили в процедурно-функциональном стиле.

Ничего оно не нарушает. Если родительский клас надо закрыть от наследования то он делается final.
и вот вы выкинули только что один из трех «китов» ООП — я вас поздравляю

Слушайте, вы про ООП как я понял знаете из книжок теории для любителей похейтерить а я на нем пишу и вижу что довольно хорошо все получается. Кое какие недостатки есть но то мелочи по сравнению с тем что ООП дает. И так же думают остальные бекенд разработчики и вообще вся отрасль. Продолжайте тут сказки рассказывать. Придумаете что то лучше этой мощнейшей тулзы для построения БОЛЬШИХ И ЛЕГКИХ В ПОДДЕРЖАНИИ И РАСШИРЕНИИ апов то приходите. Я помню вы еще писали что тайпскрипт(который создали по образу отца святого шарпа) не нужен, а он уже в втором агуляре. Джаваскриптеры гавкают, а отрасль продолжает разрабатывать в ООП, даже уже на самом джаваскрипте.

П.С. функциональщина не пройдет!

про ООП как я понял знаете из книжок теории для любителей похейтерить
ну так то я последние лет 8 его активно использую, в разных языках но в основном Java/C#/PHP/EcmaScript, но да вам виднее
думают остальные бекенд разработчики и вообще вся отрасль
отрасль думает об альтернативах, тот же Go как попытка вернутся к императивщине. лямбды в джаве — заимствование идей из мира функциональщины как попытка улучшить положение дел.
Придумаете что то лучше этой мощнейшей тулзы для построения БОЛЬШИХ И ЛЕГКИХ В ПОДДЕРЖАНИИ И РАСШИРЕНИИ
во первых, ни фига не легких в поддержании, во-вторых уже давно придумали — не создавать больших приложений.
вы еще писали что тайпскрипт(который создали по образу отца святого шарпа) не нужен,
я писал что ему место в конкретной нише, но это не панацея, в целом так оно и есть. ангуляр 2 собственно нацелен на эту нишу, но во многих аппах он не нужен.
отрасль продолжает разрабатывать в ООП, даже уже на самом джаваскрипте.
а в реальности они программируют императивно с элементами функциональнщины подавая под видом ООП.
функциональщина не пройдет!
в целом нет, частями уже прошла
отрасль думает об альтернативах

Где?))

тот же Go как попытка вернутся к императивщине

Го как я знаю создавался для микросервисов, и является алтернативой и конкурентом ноде. Куда кстати вернуться? Во времена простыней кода? Лол, поржал.

я писал что ему место в конкретной нише, но это не панацея

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

а в реальности они программируют императивно с элементами функциональнщины подавая под видом ООП.

Все ок пишется, кто умеет. Кто не умеет тот говнокодит и сотрет любую светлую идею.

в целом нет, частями уже прошла

Вот именно что частями. Ибо например передать в качестве аргумента функцию это полезная фича. Но это локальное использование ДЛЯ ООП, а не взамен. Так что вы сами доказали что ООП не только продолжает держаться на троне, но еще и активно улучшается беря все необходимое из других подходов. Разве могут быть у него какие то конкуренты? Nope.

П.С. ладно, пойду я. Не люблю спорить ни о чем. Все дураки, а джаваскриптеры дартаньяны =)

тот же Go как попытка вернутся к императивщине.
при создании — микросервисов.
лямбды в джаве — заимствование идей из мира функциональщины
блоки кода в Smalltalk и Ruby.

указатели на функции в Си, тоже из ФП?

как и лексический захват окружения.

общие для computer scince идеи — не являются придуманными в ФП.

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

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

Тем не менее микросервисы очень даже юзаются.

Адепты функциональщины говорят что она заменит ООП.

писали на анонимных классах. Что конечно не так удобно как в 8ой джаве.

А то говорят адепты — неинтересно. Потому что адепты всегда говорят одно и тоже.

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

вообще-то давно уж стали различать

а что именно мы наследуем, реализацию или интерфейс?

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

а если реализацию — то избегайте наследования больше 3ех.

то что jsники пропустили годы развития ООП да, вполне понятно.

но то что начинают рассказывать об ООП тем кто эти годы в нем и жил, да, интересно :)

ох посмеемся когда получив кусочек ООП начнут пороть те архитектурные ошибки которые большинством уже забыты на серверсайде :)

Любопытно, что понятие реализации (его вроде как в ООП и нет)заменили наследованием?

это на вашем уровне базовых знаний его нет 😁

В первом классе не дают всю школьную программу. Я и намекнул что смешно выглядит когда первоклассник улыбается второкласснику — ты чего мелешь ерунду, такому в школе не учат!

С ООП тоже самое. А если оо моделирования коснемся.... то и все 8 классов начнут ржать над 10 классником — ты чего, в школе не учился?

никто не говорит что это мешает говнячит

Тот случай когда по комментам можно вычислить говнокодера)

Не про вас речь ессесна

вы еще процитируйте знаменитое выступление «Почему ООП провалился», кажется лиспера Пола Грехема.

В каком году оно было...

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

Не пишите глупостей. Нет там лишней прослойки. То все нужно для разработки бекенда. А наговнокодить да, на джаваскрипте проще.

вам не очевиден факт что ООП остается основной парадигмой разработки на тьме ЯП?

вам это не очевидно даже после того как им усилили JS и фроненд отрасль смотрит на TypeScript? (вангую — реакт с редуксом уйдет в уютное подполье, как в джава мире — Scala)

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

Мне очевиден факт что можно лучше, и рано или поздно это лучше прийдет

вы не разобрались с ООП, и вам очевидно как лучше?

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

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

«Это так-то сейчас, потому что в будущем будет то-то и то-то!»

то есть характеристики чего-то сейчас, выводятся из того что УЖЕ произошло в будущем.

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

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

«Это так-то сейчас, потому что в будущем будет то-то и то-то!»
Вам это очевидно, вы были в будущем, и все увидели, да.
(вангую — реакт с редуксом уйдет в уютное подполье, как в джава мире — Scala)
Ясно. Понятно.

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

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

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

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

поэтому о том что Scala не станет мейнстримом я говорил еще лет 5 тому.
поэтому и уже появляющаяся критика в адрес реакта — встречается все чаще.

и поэтому беру на себя смелость экстраполировать, на основе этой моей общей идеи и о судьбе реакта.

но конечно, поживем увидим — что там будет с ангулярами и vue.

и отдельно продолжу про то что дают в начальной школе по ООП, и что принимается первоклашками за истину в последней инстанции.

так вот — наследование НЕ столп ООП. То есть не аксиома, не обязательный признак, а — теорема, способ конструирования объектов. второй известный способ — прототипирование. думаю что и еще более диковинные можно накопать, но они не стали мейнстримом по разным причинам.

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

аксиомы же, столпы ООП поясню на пальцах.

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

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

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

так вот, когда человек не понимает что наследование не столп ООП, но берется рассуждать о перспективах ООП вообще, глобально, то и получается... хм нелепость.

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

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

но, у меня не всегда так получается :)


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

та да. При том что я застал приход этого с++ного ооп в диасофте, и внимал спорам при переводе 1го издания Буча. Спорили старшие товарищи, и как программисты, хня не хня, и они же как переводчики — а вот это так перевести, или вот так.

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

Это сарказм, как я понимаю... А вот лично мне кложа очень нравится. Если бы мне приходилось писать много фронтенда, ClojureScript для меня бы выглядел почти идеально. Минус пока вижу только один: тяжело найти людей на проект с кложей -> начальство/клиент не соглашаются ее использовать -> никто из программистов не разбирается со связкой ClojureScript/DataScript/Om/etc -> круг замкнулся.

никто из программистов не разбирается со связкой
Може вони правильно роблять? ;)

Ну если рассуждать «учу только то, за что сейчас платят», то видимо правильно. Тогда стоит остановиться на PHP в плане веба, и на JAVA в плане ентерпрайза. Никакого ruby/python/etc для веба, зачем? Никакого лиспа или эрганга или го для решения задачи, зачем? Есть же джава.

Это не был сарказм, немного тролинг, немного правда

а вы не задумывались, почему до сих пор нет ООП фреймворка для Node?
потому что ниша ноды — маленькие, но хитрые микросервисы (для маленьких и простых есть go).

представьте себе монолит на JS. ужас, не правда ли?

для микросервиса (который один большой >>= или flatMap) гораздо эффективнее ФП-передигма.
потому что: надежно, нужно меньше тестов, легко деплоить и расширять на ходу.
поэтому: RxJS/Promises + TS/Immutable.js и на этом песня заканчивается (конечно, можно все это написать и на Haskell/Scala, но это кому надо?)

а для больших проектов есть Java/Scala.

Задумувався, і написав про причини в темі, думаю вони помітні.

Можно ще додати про «не так багато часу пройшло із 2015 року, як мінімум». Ну і багатьом заважають стереотипи у вигляді архітектури middleware.

а для больших проектов есть Java/Scala.

Це традиції такі, зовсім недавно і про бекенд на JavaScript ніхто не думав...

Справа в тому, що якщо проект великий, швидше за все, він розбитий на модулі, кожен із яких ініціалізує свою конфігурацію. А що таке багато коду для ініціалізації в контексті PHP? — Правильно, він її буде робити за кожним запитом, в кращому разі він делегує ініціалізацію на Dependency Injector,
очень интересно, но:

github.com/kakserpom/phpdaemon
github.com/amphp
github.com/reactphp/react

Ви пробували програмувати на цих костилях? Я намагався, щоправда не сильно довго, поверхнево. Читав купу матеріалів про нестабільність такої конструкції, їх навряд чи хтось ризикне ставити на продакті.

Та бо вся суть пхп это отработать и умереть) Он для этого создавался. А фанатико всегда попытается лопатой гвозди забивать.

а вся суть js — рендерить всплывающие окошки в браузерах, он для этого создавался.
а фанатики его тащат на бекенд.

симетрично відповім, що так було до PHP 5.4

В цілому погоджуюсь, але я, як людина яка була по обидва боки «барикад», можу сказати що JavaScript/TypeScript дає значно ширші можливості для вирішення одних і тих самих проблем в порівнянні з PHP.

Ну пхп с пятой версии сильно лучше стал. И что, убил конкурентов?) Задавил питон?)

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

jobs.dou.ua
PHP — 297
Python — 78
Ruby — 56
не то, чтоб это в какой-то мере заслуга пхп, но питон с руби и давить-то не надо.

Вы таки забыли джаву с шарпом) Отминусуйте пожалуйста вакансии с цмс, чтобы фреймворки остались, и потом сравнивайте. Уже побежал за попкорном.

а цмс на каком-то другом, специальном php-cms-edition пишут?
8ой друпал живет с ядром симфони, например.
говно конечно то еще, что друпал, что симфони, но «фреймворки» же.

а что жаба с шарпом? это языки широкой специализации.
и да,
Java — 193 вакансии,
.NET — 255 вакансий, из них в заголовке ASP встречается 32 раза.

Широкой то широкой, только в 80% на них пишут веб бекенд. Кстати андроид в другой колонке отделен. Я могу вам сказать по фрилансу — да, пхп фреймворке популярнее каждого из них поотдельности, но в суме нет.

а цмс на каком-то другом, специальном php-cms-edition пишут?

Нет, просто цмски это уровень ларькев. Тру Программисты не рассматривают такие вакансии.

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

Ну ладно, вы тут сритесь, я пойду работать... Кстати на пхп, заставляют апи допиливать.

Тру Программисты не рассматривают такие вакансии.
я слыхал, что «тру» программисты пишут на хаскеле, скале и эрланге, а эти наши шарпы, жабы и, боже упаси, js с похапэ считают говном:)

а цмски... на лурке есть отличная цитата:

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

Аряяя функциональное программирование уже рулез везде ооп нинужон все канец всем скора скала усех захватит!1111

Боже упаси. У скалы есть свое ламповое уютненькое сообщество со своими законами и порядками. И она не функциональна. en.m.wikipedia.org/...la_(programming_language

Т.е. программиста от непрограммиста отличает кол-во деталей добавленных в друпал? Если я устанавливаю друпал и переписываю 50% — всё, я программист?

если вы устанавливаете друпал и переписываете 50% то, возможно, стоит устанавливать не друпал, а что-то другое.

Я слишком тупой для этого =(

Кто то должен и цмски копать. Платят же за это вполне нормально?)

Платят ок, только работать надо, этжфриланс :-D. Другой порос почему труЪ программеры обязательно пытаются ткнуть носом, мол не программист ты и аще не достоин и IQ у тебя низкое, и член короткий, и иннахъ со своими CMSками, вебмакака. Когда я начал интересоваться IT, году в 2003, сообщество было намного дружелюбнее. И как-то видел «своего» и в сисодмине-эникейщике, и в паяльщике материнок, и в программисте. А сейчас тот программист, у кого текущий проект круче. Раньше солнце было ярче! o_O

Это просто раньше доу не было и негде было срачи устраивать

Тру тру тру. 100 лайков господину. Как где то писали — цмс для пользователя, фреймворк для разработчика.

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

Вы ничего не пропустили! Я верю в людей, а особенно в таких как господин Прокоса и его компания(ну та где он был тех лид архитект вордпрес тим лидер).

надеюсь, будет целая сага
«Возвращение Прокосы»
«ГлобалСофт наносит ответный удар»
«Месть Прокосы»
«Атака клонов ботов»
«Новая надежда»

Кстати, пхпшники обещали что с выходом пхп 7 питону трынден и вообще настанет второй приход Христа. Где все вот это?))

питон и без пхп не нужен.

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

потому что разработчикам он нравится и задачи выполняет.
вот вот, 1с то живет)

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

Я уже начинаю писать не на пхп. Так что в процессе.

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

Я уже начинаю писать не на пхп. Так что в процессе
это я читал еще где то год назад )) лол )) успогойся говнокодь дальше на своей пихе ))

у питона в отличии от пхп еще есть ниша всяких системных утилит, скриптов и демонов, которые слишком сложны, чтобы писать на баше и слишком просты и не требовательны к ресурсам, что бы писать на C++

У Питона еще есть ниша датасайнс утилит, которую он делит с R.
В отличие от пхп.

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

Глеб Кузнецов и без его комментариев не нужен.

Давай по существу, а?

мы на доу, какое «по существу»?

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

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

Но вы продолжайте))) Забавно читать как технология х скоро всех порвет, потому что вышла новая версия к ней))

А что такого в ес2015 что бы вкорне изменило ситуацию и он стал так уж нужен на беке?
Ну как минимум генераторы, нативные промисы, async/await — это для управления асинхронностью. С async/await писать асинхронный код сможет даже разработчик с императивной опухолью головного мозга.

Новые структуры данных (map/weakmap/set/weakset/symbol/typed arrays вот это вот всё). Опять же, с weakset/weakmap вероятность утекания памяти снижается в разы.

Плюс tail call optimization для тех же целей. Плюс прокси и рефлекшн объекты. Короче, много всего. Твой товарищ именно _немного_ нырял судя по всему.

смешно его ставить против шарпа
зачем его ставить против сишарпа?

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

async/await

Этого еще нет.

зачем его ставить против сишарпа?

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

Твой товарищ именно _немного_ нырял судя по всему.

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

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

kangax.github.io/...lus/#test-async_functions — в браузерах есть нативно, в ноде — через транспайлер.

Лол. Прекрасно, пойду напюсь))

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

async/await
Этого еще нет.
а, вот, и да

Хорошо, как раз лет через 10 такое появится и в браузерах))

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

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

async/await — это для управления асинхронностью
та ну, это ж следующая версия. хоть, в ноде уже есть, да.
Плюс tail call optimization для тех же целей
к несчастью, нет. ну, может, и к счастью, но лично я расстроен.

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

ну, да, реализация есть, но из стандарта выкинули, так шо кто знает, как будет в будущем.

a) так, я пробував
b) habrahabr.ru/post/220393
с) i в чому ж полягає ця «нестабiльнiсть»?

На скільки пам’ятаю, нестабільність полягає у першу чергу у витоку пам’яті, ну і у підтримці процеса у робочому стані... Але то було давно й не правда, може зараз (через 5 років) щось змінилось, хз.

bfy.tw/9zPi
bfy.tw/9zPk
bfy.tw/9zPm

але чомусь ніхто не створює з цього трагедію.

А вот и ООП захотелось жабоскриптерам. Ну я ж говорил! Путь ПХП.

Виходячи з вищезазначеного, думаю час вже створити нарешті сучасний Node.js-ООП-фреймворк. Я вже попи́сую свій
пошел за попкорном и буду смотреть на

Це не однозначний показник. З одного боку він може говорити про нестабільність у JavaScript-середовищі, але з іншого боку — говорить що на JavaScript досить легко писати.

Это говорит о том, что никто не может написать универcальный инструмент для работы с UI. Ну или хотя бы что-то без немалого списка минусов и статей «<js framework=»"> sucks".

Тому же PHP не нужны 20 новых фреймворков в год, т.к. если не гнаться за модными тенденциями — то и фреймворки 4-5 летней давности впринципе неплохо работают и зачастую в 5 раз быстрее чем модный Laravel.

Подписаться на комментарии