Розробка · 9 лютого 2017, 14:30 5403

Костя Третяк, full-stack developer (TypeScript, restify-ts, Angular)

Давайте поговоримо про 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-ООП-фреймворк. Я вже попи́сую свій, але ще рановато його представляти.

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

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті

Теми: ES2015, node.js

👍ПодобаєтьсяСподобалось0

До обраногоВ обраному0

Facebook

Twitter

LinkedIn

Найкращі коментарі пропустити

Nik Katalnikov 15.02.2017 18:17

еще раз для ~~свидетелей~~ любителей ООП на 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 — прекрасный нишевый инструмент у которого очень большое и светлое будущее в своей уютненькой зоне микросервисной архитектуры.

Перейти до дискусії

Ctrl + Enter

Ctrl + Enter

anastasia-ache 13.08.2022 13:04

Доброго дня, можливо не в тему, але чому при завантаженні node js у мене виникає проблема? Пише: change,repair or remove installation. Що з цим робити? help me please..

Відповісти

Підтримати

Костя Третяк TypeScript web developer 13.08.2022 13:12

Що ви маєте на увазі, коли кажете «завантаження node js»? Хоча, судячи із помилки, мабуть ви намагаєтесь встановити NodeJS на Windows. Так? Якщо так, то виберіть один із варіантів, який вам пропонує інсталятор.

Він це пропонує, бо схоже, що у вас вже встановлено NodeJS. Відкрийте командний рядок, введіть node і натисніть ентер. Потім відпишіться що ви бачите.

Відповісти

Підтримати

Костя Третяк 24.01.2018 17:20

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

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

Відповісти

Підтримати

Костя Третяк 24.01.2018 17:33

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

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

Відповісти

Підтримати

Костя Третяк

Костя Третяк 24.02.2017 22:09

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

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

Відповісти

Підтримати

Костя Третяк 25.02.2017 09:51

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

Відповісти

Підтримати

Костя Третяк

Nik Katalnikov explorer 15.02.2017 18:17

еще раз для ~~свидетелей~~ любителей ООП на 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 — прекрасный нишевый инструмент у которого очень большое и светлое будущее в своей уютненькой зоне микросервисной архитектуры.

Відповісти

Підтримати

Костя Третяк 15.02.2017 18:39

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

Відповісти

Підтримати

Oleksandr Tkalenko . 15.02.2017 18:40

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

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

Відповісти

Підтримати

Jim Moriarty 22.02.2017 11:50

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

Відповісти

Підтримати

Ще 3 коментарі

Костя Третяк 22.02.2017 12:11

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

Відповісти

Підтримати

Jim Moriarty 22.02.2017 16:49

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

Відповісти

Підтримати

Костя Третяк

Костя Третяк 22.02.2017 17:26

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

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

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

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

Відповісти

Підтримати

Max Swarovski 14.02.2017 23:51

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

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

Відповісти

Підтримати

Dmytro Verbovyi Typing on keyboard в Scout Gaming Tech 14.02.2017 17:07

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

Відповісти

Підтримати

Костя Третяк 14.02.2017 17:25

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

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

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

Відповісти

Підтримати

Dmytro Verbovyi

Ще 14 коментарів

Dmytro Verbovyi Typing on keyboard в Scout Gaming Tech 14.02.2017 17:57

loopback платний

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

й також не ООП

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

Відповісти

Підтримати

Костя Третяк

Костя Третяк 14.02.2017 18:57

яка різниця як написаний він всередині, хто Вам заважає писати в ООП-стилі самому використовуючи його. 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. Ми не піклуємось про те що вони у своїх конструкторах мають якість там свої залежності...

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

Відповісти

Підтримати

Dmytro Verbovyi

Andriy Maletsky 14.02.2017 19:35

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

Відповісти

Підтримати

Костя Третяк

Vladimir Krasulya Web Dev в Ciklum 14.02.2017 20:26

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

Відповісти

Підтримати

Костя Третяк

Костя Третяк 14.02.2017 21:08

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

Відповісти

Підтримати

Vladimir Krasulya

Дмитро 14.02.2017 22:22

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

Відповісти

Підтримати

Костя Третяк

Костя Третяк 15.02.2017 09:36

Ок, давайте уточню, що під 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-фреймворках.

Відповісти

Підтримати

Miroslav Grabinskiy senior node.js 15.02.2017 22:50

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

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

это будет не то же самое для единичного случая, что и во втором:

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

?

Відповісти

Підтримати

Костя Третяк

Костя Третяк 15.02.2017 23:06

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

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

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

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

Відповісти

Підтримати

Miroslav Grabinskiy

Костя Третяк 15.02.2017 09:54

ООП в подходе с сервис локатором также нет.

Я знаю лише про такий DI, робота якого полягає у створенні об’єктів класів, попутно вирішуючи їхні залежності, указані в їхніх конструкторах. Тобто саме справжнє ООП.

Відповісти

Підтримати

Vladimir Krasulya Web Dev в Ciklum 14.02.2017 22:40

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

пів сотні middleware

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

Відповісти

Підтримати

Костя Третяк

Костя Третяк 15.02.2017 09:39

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

Відповісти

Підтримати

Vladimir Krasulya

Andriy Maletsky 14.02.2017 22:00

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

Відповісти

Підтримати

Костя Третяк

Костя Третяк 15.02.2017 09:02

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

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

Відповісти

Підтримати

Andriy Maletsky

Vadym Bondarenko 14.02.2017 18:17

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

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

Відповісти

Підтримати

Dmytro Verbovyi

Ще 6 коментарів

Dmytro Verbovyi Typing on keyboard в Scout Gaming Tech 14.02.2017 18:30

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

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

Відповісти

Підтримати

Vadym Bondarenko

Vadym Bondarenko 14.02.2017 19:10

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

Именно + в проекте будет ничего лишнего

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

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

Відповісти

Підтримати

Dmytro Verbovyi

NewOne NewOne 15.02.2017 10:33

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

Відповісти

Підтримати

Vadym Bondarenko

Костя Третяк 15.02.2017 10:38

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

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

Відповісти

Підтримати

NewOne NewOne 15.02.2017 11:50

Я Вадима спрашивал ))

Відповісти

Підтримати

Костя Третяк

Костя Третяк 15.02.2017 12:31

А, точно, сорі =)

Відповісти

Підтримати

Олександр Шпак Oarsman в Self Employed 11.02.2017 00:09

Про те, що TypeScript це НЕ мага-круто, може говорити лише той,

хто вивчив JS та розуміє всі його сильні та слабки сторони.

Відповісти

Підтримати

Костя Третяк 11.02.2017 10:09

Тобто — ніхто =)

Відповісти

Підтримати

Олександр Шпак

Ще 1 коментар

Олександр Шпак Oarsman в Self Employed 11.02.2017 14:42

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

Відповісти

Підтримати

Костя Третяк

minodvesP Vasya 10.02.2017 23:58

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

...или тот, кто пишет под javascript на функциональщине) ну там Elm, ClojureScript, PureScript и все такое. :-)

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

о! Респект! будет интересно его глянуть, когда он будет готов)

Може вже є такі фреймворки

может www.totaljs.com .. помню когда-то его смотрел — мне понравился. Правда не знаю, насколько он ООП, но его позиционируют как laravel- и django-подобный фреймворк (т..е. по идее на нем можно довольно крупный проект поднять).

Відповісти

Підтримати

Костя Третяк 11.02.2017 10:22

Проглядав я і 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);
};

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

Відповісти

Підтримати

minodvesP Vasya

Nik Katalnikov explorer 10.02.2017 21:56

Коментар порушує правила спільноти і видалений модераторами.

Костя Третяк 10.02.2017 21:14

Мірявся тільки що... кхм, показниками з 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?

Відповісти

Підтримати

Глеб Кузнецов Independent contractor 16.02.2017 03:23

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

Відповісти

Підтримати

Костя Третяк

Ще 14 коментарів

Костя Третяк 16.02.2017 11:10

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

Відповісти

Підтримати

Глеб Кузнецов

Глеб Кузнецов Independent contractor 16.02.2017 15:07

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

Відповісти

Підтримати

Костя Третяк

Костя Третяк 16.02.2017 15:12

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

ab -n 50000 localhost/

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

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

Відповісти

Підтримати

Глеб Кузнецов

Глеб Кузнецов Independent contractor 16.02.2017 15:45

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

Відповісти

Підтримати

Костя Третяк

Глеб Кузнецов Independent contractor 16.02.2017 16:33

а нет, не могу молчать, когда в интернете кто-то не прав.
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

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

Відповісти

Підтримати

Костя Третяк

Костя Третяк 16.02.2017 17:04

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

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

Відповісти

Підтримати

Глеб Кузнецов

Глеб Кузнецов Independent contractor 16.02.2017 17:37

Не знаю на якій машині ви тестували

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мб.

Відповісти

Підтримати

Костя Третяк

Костя Третяк 16.02.2017 17:46

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

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

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

Відповісти

Підтримати

Глеб Кузнецов

Глеб Кузнецов Independent contractor 16.02.2017 18:00

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

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

Відповісти

Підтримати

Костя Третяк

Костя Третяк 16.02.2017 18:12

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

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

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

Відповісти

Підтримати

Глеб Кузнецов

Глеб Кузнецов Independent contractor 16.02.2017 18:38

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

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

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

Відповісти

Підтримати

Костя Третяк

Костя Третяк 16.02.2017 19:05

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

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

Відповісти

Підтримати

Глеб Кузнецов

Глеб Кузнецов Independent contractor 16.02.2017 19:14

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

Відповісти

Підтримати

Костя Третяк

Костя Третяк 16.02.2017 21:41

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

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

Відповісти

Підтримати

Глеб Кузнецов

anonymous 10.02.2017 16:23

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

Відповісти

Підтримати

Костя Третяк 10.02.2017 16:35

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

Відповісти

Підтримати

Ще 2 коментарі

anonymous 12.02.2017 11:53

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

Відповісти

Підтримати

Костя Третяк

Костя Третяк 12.02.2017 12:02

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

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

Відповісти

Підтримати

Павел Борисов Писатель в Неизвестности™ 10.02.2017 13:35

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

Відповісти

Підтримати

Ivan Bokii 10.02.2017 12:24

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

нет

Відповісти

Підтримати

Oleksandr Ivanov Data engineer в Schibsted 10.02.2017 12:22

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

Відповісти

Підтримати

undefined pointer 10.02.2017 13:44

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

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

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

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

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

Відповісти

Підтримати

Oleksandr Ivanov

Ще 22 коментарі

Oleksandr Ivanov Data engineer в Schibsted 10.02.2017 14:05

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

Відповісти

Підтримати

undefined pointer

undefined pointer 10.02.2017 14:14

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

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

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

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

Відповісти

Підтримати

Oleksandr Ivanov

anonymous 10.02.2017 14:33

переважна більшість фронтендщиків обирає ООП

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

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

Відповісти

Підтримати

undefined pointer

Oleksandr Ivanov Data engineer в Schibsted 10.02.2017 15:29

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

Відповісти

Підтримати

undefined pointer 10.02.2017 15:47

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

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

Відповісти

Підтримати

anonymous 10.02.2017 15:59

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

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

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

мучающихся на Джаве

Псевдо-ООП в JS достаточно болезненная тема, никто не сравнивает с Java.

Відповісти

Підтримати

undefined pointer

undefined pointer 10.02.2017 16:11

В моем понимании эти 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 да, отличный фундамент для прогнозирования будущего.

Відповісти

Підтримати

anonymous 10.02.2017 16:46

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

Естественно. С этим даже никто не спорит. Другое дело, что 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 им многого не хватало.

Відповісти

Підтримати

undefined pointer

undefined pointer 10.02.2017 16:58

С этим даже никто не спорит.

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

Другое дело, что React в большинстве случаев тянет за собой целую кухню других вещей

о, отлично что мне не пришлось об этом упоминать :)

Более хайповый сейчас Vue.

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

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

Например в том же React

это не важно что там в нем.

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

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

ок. давайте по другому.

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

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

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

Нет, для всех, кто разобрался и может писать в любом стиле.

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

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

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

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

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

Відповісти

Підтримати

anonymous 10.02.2017 17:13

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

але ж самі ж фронтендери обирають ООП стиль

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

Відповісти

Підтримати

undefined pointer

undefined pointer 10.02.2017 17:38

Мне это не интересно

вот именно.

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

Или разницу между «вынуждены писать на» и «выбирают»

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

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

на чем уже написан проект

да, оспариваю.

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

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

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

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

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

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

Відповісти

Підтримати

Olexandr Vovchok 10.02.2017 17:42

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

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

Відповісти

Підтримати

undefined pointer

undefined pointer 10.02.2017 17:46

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

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

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

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

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

www.youtube.com/watch?v=F_nZgA4AvA4

Відповісти

Підтримати

Olexandr Vovchok

Olexandr Vovchok 10.02.2017 17:49

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

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

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

Відповісти

Підтримати

undefined pointer

undefined pointer 10.02.2017 18:13

отож.

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

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

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

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

Відповісти

Підтримати

Olexandr Vovchok

anonymous 10.02.2017 18:25

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

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

Відповісти

Підтримати

undefined pointer

undefined pointer 10.02.2017 18:40

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

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

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

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

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

Відповісти

Підтримати

anonymous 10.02.2017 18:52

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

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

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

Відповісти

Підтримати

undefined pointer

undefined pointer 10.02.2017 19:06

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

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

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

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

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

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

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

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

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

Відповісти

Підтримати

minodvesP Vasya 11.02.2017 00:11

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

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

Відповісти

Підтримати

undefined pointer

anonymous 10.02.2017 19:07

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

Відповісти

Підтримати

anonymous 10.02.2017 19:40

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

Відповісти

Підтримати

Oleksiy Zakharov Programmer в - Freelancer 10.02.2017 01:45

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

Відповісти

Підтримати

Olexandr Vovchok 10.02.2017 18:43

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

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

Відповісти

Підтримати

Oleksiy Zakharov

Ще 2 коментарі

Євген Козлов Front-end developer в SoftServe 10.02.2017 21:35

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

Відповісти

Підтримати

Olexandr Vovchok

Olexandr Vovchok 10.02.2017 22:00

Не, не понял что то был сарказм(

Відповісти

Підтримати

Євген Козлов

anonymous 10.02.2017 01:00

-

Відповісти

Підтримати

sanchez 10.02.2017 10:46

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

Відповісти

Підтримати

Oleksandr Ivanov Data engineer в Schibsted 10.02.2017 15:31

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

Відповісти

Підтримати

Ще 1 коментар

Костя Третяк 10.02.2017 15:32

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

Відповісти

Підтримати

Oleksandr Ivanov

Yurii Savka Інженер 10.02.2017 00:39

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

Відповісти

Підтримати

Костя Третяк 22.02.2017 10:59

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

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

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

Відповісти

Підтримати

Ще 3 коментарі

Дмитро 22.02.2017 11:19

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

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

Відповісти

Підтримати

Костя Третяк

Костя Третяк 22.02.2017 11:52

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

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

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

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

Поэтому и ооп-императивный стиль кодирования для Node.js это горожение никому ненужного носорога

Треба більше аргументів...

Відповісти

Підтримати

Костя Третяк 23.02.2017 18:22

ооп-императивный стиль кодирования для Node.js это горожение никому ненужного слона-носорога стоящего на табуретке.

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

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

Відповісти

Підтримати

Evan Demenkoff Teach Lead в ТОВ АБРИС ПТ 09.02.2017 23:06

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

Відповісти

Підтримати

Olexandr Vovchok 09.02.2017 23:11

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

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

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

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

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

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

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

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

Відповісти

Підтримати

Ще 27 коментарів

undefined pointer 09.02.2017 23:22

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

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

Відповісти

Підтримати

Olexandr Vovchok

Olexandr Vovchok 09.02.2017 23:39

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

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

init: function() {

},

method1: function() {

},

....
}

Відповісти

Підтримати

undefined pointer

undefined pointer 09.02.2017 23:49

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

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

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

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

Відповісти

Підтримати

Olexandr Vovchok

anonymous 10.02.2017 00:25

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

Ні. То синтаксичний цукор.

Відповісти

Підтримати

Olexandr Vovchok

Olexandr Vovchok 10.02.2017 00:29

Суті не міняє

Відповісти

Підтримати

Євген Козлов Front-end developer в SoftServe 10.02.2017 00:29

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

Відповісти

Підтримати

Костя Третяк 10.02.2017 10:46

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

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

Відповісти

Підтримати

Євген Козлов

anonymous 10.02.2017 15:15

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

Відповісти

Підтримати

Костя Третяк

Костя Третяк 10.02.2017 15:27

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

Відповісти

Підтримати

anonymous 10.02.2017 15:33

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

const a = class {}

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

Відповісти

Підтримати

Костя Третяк

anonymous 10.02.2017 15:39

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

Відповісти

Підтримати

Костя Третяк

Jorzchyk Pushysty 10.02.2017 16:17

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

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

Відповісти

Підтримати

Костя Третяк

Olexandr Vovchok 10.02.2017 16:22

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

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

Відповісти

Підтримати

Jorzchyk Pushysty

Jorzchyk Pushysty 10.02.2017 16:43

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

Я не знаю жодного визначення „ООП”, яке б включало такий пункт.
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

Відповісти

Підтримати

Olexandr Vovchok

Olexandr Vovchok 10.02.2017 17:32

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

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

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

Відповісти

Підтримати

Jorzchyk Pushysty

Oleksii Pavlov Software Engineer 10.02.2017 17:35

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

Відповісти

Підтримати

Olexandr Vovchok

Olexandr Vovchok 10.02.2017 17:40

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

Відповісти

Підтримати

Oleksii Pavlov Software Engineer 10.02.2017 17:52

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

Відповісти

Підтримати

Olexandr Vovchok

Olexandr Vovchok 10.02.2017 17:53

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

Відповісти

Підтримати

Євген Козлов Front-end developer в SoftServe 10.02.2017 16:44

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

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

Відповісти

Підтримати

Olexandr Vovchok

Olexandr Vovchok 10.02.2017 17:45

статичні методи та проперті виступають проти

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

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

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

Відповісти

Підтримати

Євген Козлов

Євген Козлов Front-end developer в SoftServe 10.02.2017 18:06

Ок, то хіба вони виступають інстансом?

так, поганий аргумент вийшов. В данному випадку просто як (мета-)змінна, жодного метода не викликається.

Відповісти

Підтримати

Olexandr Vovchok

Konstantin Strukov 10.02.2017 19:26

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

Вы еще раз подтверждаете, что дедушка Алан Кей был таки прав, когда написал «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“...».

Відповісти

Підтримати

Костя Третяк

undefined pointer 12.02.2017 14:48

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

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

Відповісти

Підтримати

Konstantin Strukov

anonymous 10.02.2017 15:13

Що таке VMT?

Відповісти

Підтримати

Євген Козлов

Євген Козлов Front-end developer в SoftServe 10.02.2017 16:45

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

Відповісти

Підтримати

Miroslav Grabinskiy senior node.js 10.02.2017 13:00

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

Відповісти

Підтримати

Olexandr Vovchok

anonymous 09.02.2017 23:47

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

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

Відповісти

Підтримати

Ще 1 коментар

Max Swarovski 15.02.2017 00:53

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

Відповісти

Підтримати

Max Swarovski 15.02.2017 00:00

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

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

Відповісти

Підтримати

Andriy Maletsky 09.02.2017 23:02

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

Відповісти

Підтримати

undefined pointer 09.02.2017 21:29

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

треба не думати — а будувати.

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

так, э така проблема. але, зазирніть у код Magento — щоб «здивуватись» що там ну чиста Java.

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

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

але для цього э Java, C#, Go

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

Відповісти

Підтримати

Костя Третяк 09.02.2017 21:40

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

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

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

Відповісти

Підтримати

undefined pointer

Ще 6 коментарів

Olexandr Vovchok 09.02.2017 21:42

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

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

Java, C#

Відповісти

Підтримати

Костя Третяк

undefined pointer 09.02.2017 21:47

Дешевшою розробкою

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

Простішою в освоєнні.

php — простіший. не такий звісно як в Zend та Symfony. але це визнано.

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

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

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

отож.

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

Зараз же я теж пишу виключно на TypeScript

ну чекаємо тоді складних проектів на TypeScript.

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

Відповісти

Підтримати

Костя Третяк

Костя Третяк 09.02.2017 21:52

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

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

Відповісти

Підтримати

undefined pointer

Olexandr Vovchok 09.02.2017 22:08

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

Відповісти

Підтримати

Костя Третяк

undefined pointer 09.02.2017 22:15

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

а що такє веб-проект?

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

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

Відповісти

Підтримати

Костя Третяк

Andriy Maletsky 09.02.2017 22:48

Простішою в освоєнні.

дуже спірне твердження

Відповісти

Підтримати

Костя Третяк

anonymous 09.02.2017 21:24

-

Відповісти

Підтримати

Костя Третяк 09.02.2017 21:30

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

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

Відповісти

Підтримати

Ще 10 коментарів

undefined pointer 09.02.2017 21:33

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

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

Відповісти

Підтримати

Костя Третяк

Olexandr Vovchok 09.02.2017 21:36

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

Відповісти

Підтримати

undefined pointer

undefined pointer 09.02.2017 21:51

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

хто все це писати буде?

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

Відповісти

Підтримати

Olexandr Vovchok

Olexandr Vovchok 09.02.2017 21:55

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

Відповісти

Підтримати

undefined pointer

Александр Шевченко Java developer 09.02.2017 22:12

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

Відповісти

Підтримати

Olexandr Vovchok

Костя Третяк 09.02.2017 21:45

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

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

Відповісти

Підтримати

undefined pointer

Olexandr Vovchok 09.02.2017 21:48

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

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

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

Відповісти

Підтримати

Костя Третяк

Глеб Кузнецов Independent contractor 10.02.2017 00:40

можно ввести еще сколь угодно много новых стандартов, но подвинуть пхп, «противником» которого старается быть нода ей будет очень сложно. потому до сложных языков ей еще далеко, пусть они сейчас и пытаются двигаться в сторону .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 и похапе преимущественно используются, на пхп дешевле, быстрей и проще.

Відповісти

Підтримати

Костя Третяк

Andrey MK 09.02.2017 23:50

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

Відповісти

Підтримати

undefined pointer

undefined pointer 10.02.2017 00:02

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

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

Відповісти

Підтримати

Yarik Shlyakhov junior angular developer в solringair 09.02.2017 20:30

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

Відповісти

Підтримати

Vadym Bondarenko 09.02.2017 18:38

-

Vadym Bondarenko 09.02.2017 18:38

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

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

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

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

Відповісти

Підтримати

Костя Третяк 09.02.2017 18:43

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

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

Відповісти

Підтримати

Vadym Bondarenko

Ще 3 коментарі

Vadym Bondarenko 09.02.2017 19:21

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

Відповісти

Підтримати

Костя Третяк

Костя Третяк 09.02.2017 20:02

Ну, зокрема, використання класів, декораторів, щоб можна було відчути усі переваги 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, і їм подібних, тестування роблять лише інтеграційне, без можливості ізоляції окремих частин на блоки (якщо говорити про великі проекти).

Відповісти

Підтримати

Vadym Bondarenko

Vadym Bondarenko 09.02.2017 22:16

Так все что у вас в коде будет работать и в 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);
    }
  });

Відповісти

Підтримати

Костя Третяк

anonymous 09.02.2017 17:45

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

Відповісти

Підтримати

Костя Третяк 09.02.2017 18:24

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

Відповісти

Підтримати

Ще 30 коментарів

anonymous 09.02.2017 20:24

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

Відповісти

Підтримати

Костя Третяк

Глеб Кузнецов Independent contractor 09.02.2017 20:35

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

Відповісти

Підтримати

Костя Третяк 09.02.2017 20:41

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

Відповісти

Підтримати

Глеб Кузнецов

anonymous 09.02.2017 21:06

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

Відповісти

Підтримати

Костя Третяк

Olexandr Vovchok 09.02.2017 21:29

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

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

Відповісти

Підтримати

anonymous 09.02.2017 21:43

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

Відповісти

Підтримати

Olexandr Vovchok

Olexandr Vovchok 09.02.2017 21:46

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

Відповісти

Підтримати

anonymous 09.02.2017 21:57

Ничего оно не нарушает. Если родительский клас надо закрыть от наследования то он делается final.

и вот вы выкинули только что один из трех «китов» ООП — я вас поздравляю

Відповісти

Підтримати

Olexandr Vovchok

Olexandr Vovchok 09.02.2017 22:05

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

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

Відповісти

Підтримати

anonymous 09.02.2017 22:21

про ООП как я понял знаете из книжок теории для любителей похейтерить

ну так то я последние лет 8 его активно использую, в разных языках но в основном Java/C#/PHP/EcmaScript, но да вам виднее

думают остальные бекенд разработчики и вообще вся отрасль

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

Придумаете что то лучше этой мощнейшей тулзы для построения БОЛЬШИХ И ЛЕГКИХ В ПОДДЕРЖАНИИ И РАСШИРЕНИИ

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

вы еще писали что тайпскрипт(который создали по образу отца святого шарпа) не нужен,

я писал что ему место в конкретной нише, но это не панацея, в целом так оно и есть. ангуляр 2 собственно нацелен на эту нишу, но во многих аппах он не нужен.

отрасль продолжает разрабатывать в ООП, даже уже на самом джаваскрипте.

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

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

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

Відповісти

Підтримати

Olexandr Vovchok

Olexandr Vovchok 09.02.2017 22:28

отрасль думает об альтернативах

Где?))

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

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

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

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

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

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

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

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

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

Відповісти

Підтримати

undefined pointer 09.02.2017 22:30

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

при создании — микросервисов.

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

блоки кода в Smalltalk и Ruby.

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

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

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

во-вторых уже давно придумали — не создавать больших приложений.

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

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

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

Відповісти

Підтримати

anonymous 09.02.2017 23:53

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

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

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

Відповісти

Підтримати

undefined pointer

undefined pointer 10.02.2017 00:07

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

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

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

Відповісти

Підтримати

undefined pointer 09.02.2017 22:21

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

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

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

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

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

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

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

Відповісти

Підтримати

anonymous 09.02.2017 23:55

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

Відповісти

Підтримати

undefined pointer

undefined pointer 10.02.2017 00:13

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

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

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

Відповісти

Підтримати

anonymous 09.02.2017 21:01

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

Відповісти

Підтримати

Глеб Кузнецов

Victor Musienkо Senior Engineer в Noibu.com 09.02.2017 22:49

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

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

Відповісти

Підтримати

undefined pointer 09.02.2017 23:11

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

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

Відповісти

Підтримати

anonymous 09.02.2017 23:58

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

Відповісти

Підтримати

undefined pointer

Olexandr Vovchok 10.02.2017 00:06

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

Відповісти

Підтримати

undefined pointer 10.02.2017 12:04

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

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

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

Відповісти

Підтримати

anonymous 10.02.2017 12:19

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

Відповісти

Підтримати

undefined pointer

undefined pointer 10.02.2017 12:41

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

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

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

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

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

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

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

Відповісти

Підтримати

Oleksandr Tkalenko . 10.02.2017 12:50

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

Вам это очевидно, вы были в будущем, и все увидели, да.

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

Ясно. Понятно.

Відповісти

Підтримати

undefined pointer

undefined pointer 10.02.2017 12:56

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

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

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

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

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

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

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

Відповісти

Підтримати

Oleksandr Tkalenko

undefined pointer 10.02.2017 12:35

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

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

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

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

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

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

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

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

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

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

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

Відповісти

Підтримати

Konstantin Strukov 10.02.2017 19:46

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

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

Відповісти

Підтримати

undefined pointer

undefined pointer 10.02.2017 21:19

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

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

Відповісти

Підтримати

Konstantin Strukov

Andrii Studinskyi Software engineer 12.02.2017 23:24

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

Відповісти

Підтримати

Ще 3 коментарі

Олександр Шпак Oarsman в Self Employed 13.02.2017 00:06

никто из программистов не разбирается со связкой

Може вони правильно роблять? ;)

Відповісти

Підтримати

Andrii Studinskyi

Andrii Studinskyi Software engineer 15.02.2017 00:10

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

Відповісти

Підтримати

Олександр Шпак

anonymous 13.02.2017 07:21

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

Відповісти

Підтримати

Andrii Studinskyi

Nik Katalnikov explorer 09.02.2017 17:37

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

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

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

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

Відповісти

Підтримати

Костя Третяк 09.02.2017 18:22

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

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

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

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

Відповісти

Підтримати

Глеб Кузнецов Independent contractor 09.02.2017 16:39

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

очень интересно, но:

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

Відповісти

Підтримати

Olexandr Vovchok 09.02.2017 16:41

И кому эти костыли нужны?))

Відповісти

Підтримати

Глеб Кузнецов

Костя Третяк 09.02.2017 16:44

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

Відповісти

Підтримати

Глеб Кузнецов

Ще 51 коментар

Olexandr Vovchok 09.02.2017 16:45

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

Відповісти

Підтримати

Костя Третяк

Глеб Кузнецов Independent contractor 09.02.2017 16:51

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

Відповісти

Підтримати

Olexandr Vovchok

Костя Третяк 09.02.2017 16:53

Так було до ES2015+, TypeScript.

Відповісти

Підтримати

Глеб Кузнецов

Глеб Кузнецов Independent contractor 09.02.2017 16:54

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

Відповісти

Підтримати

Костя Третяк

Olexandr Vovchok 09.02.2017 16:57

О, файт файт!)

Відповісти

Підтримати

Глеб Кузнецов

Костя Третяк 09.02.2017 16:59

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

Відповісти

Підтримати

Глеб Кузнецов

Olexandr Vovchok 09.02.2017 17:04

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

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

Відповісти

Підтримати

Костя Третяк

Глеб Кузнецов Independent contractor 09.02.2017 17:08

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

Відповісти

Підтримати

Olexandr Vovchok

Olexandr Vovchok 09.02.2017 17:09

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

Відповісти

Підтримати

Глеб Кузнецов

Глеб Кузнецов Independent contractor 09.02.2017 17:17

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

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

Відповісти

Підтримати

Olexandr Vovchok

Olexandr Vovchok 09.02.2017 17:20

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

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

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

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

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

Відповісти

Підтримати

Глеб Кузнецов

Глеб Кузнецов Independent contractor 09.02.2017 17:27

Тру Программисты не рассматривают такие вакансии.

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

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

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

— Джереми Морган

Відповісти

Підтримати

Olexandr Vovchok

Olexandr Vovchok 09.02.2017 17:28

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

Відповісти

Підтримати

Глеб Кузнецов

Victor Musienkо Senior Engineer в Noibu.com 09.02.2017 22:51

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

Відповісти

Підтримати

Olexandr Vovchok

Vasily Karpets CTO 10.02.2017 09:40

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

Відповісти

Підтримати

Глеб Кузнецов

Глеб Кузнецов Independent contractor 10.02.2017 14:04

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

Відповісти

Підтримати

Vasily Karpets CTO 10.02.2017 14:15

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

Відповісти

Підтримати

Глеб Кузнецов

Olexandr Vovchok 10.02.2017 14:54

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

Відповісти

Підтримати

Vasily Karpets CTO 10.02.2017 15:16

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

Відповісти

Підтримати

Olexandr Vovchok

Olexandr Vovchok 10.02.2017 15:31

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

Відповісти

Підтримати

Olexandr Vovchok 10.02.2017 14:54

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

Відповісти

Підтримати

Глеб Кузнецов

Глеб Кузнецов Independent contractor 09.02.2017 17:21

Уже побежал за попкорном.

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

Відповісти

Підтримати

Olexandr Vovchok

Olexandr Vovchok 09.02.2017 17:33

так жалею, что пропустил вчера весь замес с Прокосой :(

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

Відповісти

Підтримати

Глеб Кузнецов

Глеб Кузнецов Independent contractor 09.02.2017 17:40

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

Відповісти

Підтримати

Olexandr Vovchok

Olexandr Vovchok 09.02.2017 17:10

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

Відповісти

Підтримати

Глеб Кузнецов

Глеб Кузнецов Independent contractor 09.02.2017 17:18

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

Відповісти

Підтримати

Olexandr Vovchok

Olexandr Vovchok 09.02.2017 17:23

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

Відповісти

Підтримати

Глеб Кузнецов

Глеб Кузнецов Independent contractor 09.02.2017 17:30

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

вот вот, 1с то живет)

Відповісти

Підтримати

Olexandr Vovchok

anonymous 09.02.2017 23:26

-

Відповісти

Підтримати

Olexandr Vovchok

Olexandr Vovchok 09.02.2017 23:30

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

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

Відповісти

Підтримати

NewOne NewOne 10.02.2017 09:36

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

это я читал еще где то год назад )) лол )) успогойся говнокодь дальше на своей пихе ))

Відповісти

Підтримати

Olexandr Vovchok

anonymous 10.02.2017 12:02

-

Відповісти

Підтримати

Olexandr Vovchok

Oleksandr Tkalenko . 10.02.2017 12:54

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

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

Відповісти

Підтримати

Victor Musienkо Senior Engineer в Noibu.com 09.02.2017 22:53

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

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

Відповісти

Підтримати

Глеб Кузнецов

Глеб Кузнецов Independent contractor 09.02.2017 23:03

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

Відповісти

Підтримати

Victor Musienkо

Olexandr Vovchok 09.02.2017 17:01

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

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

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

Відповісти

Підтримати

Костя Третяк

Oleksandr Tkalenko . 09.02.2017 17:23

А что такого в ес2015 что бы вкорне изменило ситуацию и он стал так уж нужен на беке?

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

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

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

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

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

Відповісти

Підтримати

Olexandr Vovchok

Olexandr Vovchok 09.02.2017 17:26

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

async/await

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

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

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

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

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

Відповісти

Підтримати

Oleksandr Tkalenko

Oleksandr Tkalenko . 09.02.2017 17:29

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

Шото я там такого не заметил.

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

Відповісти

Підтримати

Olexandr Vovchok

Olexandr Vovchok 09.02.2017 17:30

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

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

Відповісти

Підтримати

Oleksandr Tkalenko

Євген Козлов Front-end developer в SoftServe 09.02.2017 23:01

async/await

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

а, вот, и да

Відповісти

Підтримати

Olexandr Vovchok

Olexandr Vovchok 09.02.2017 23:16

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

Відповісти

Підтримати

Євген Козлов

Євген Козлов Front-end developer в SoftServe 09.02.2017 23:31

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

Відповісти

Підтримати

Olexandr Vovchok

Oleksandr Tkalenko . 10.02.2017 02:08

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

Відповісти

Підтримати

Olexandr Vovchok

Miroslav Grabinskiy senior node.js 10.02.2017 13:16

developer.mozilla.org/...Statements/async_function

Не путайте людей. Но в ноде есть уже, да

Відповісти

Підтримати

Євген Козлов

Євген Козлов Front-end developer в SoftServe 09.02.2017 22:56

async/await — это для управления асинхронностью

та ну, это ж следующая версия. хоть, в ноде уже есть, да.

Плюс tail call optimization для тех же целей

к несчастью, нет. ну, может, и к счастью, но лично я расстроен.

Відповісти

Підтримати

Oleksandr Tkalenko

Oleksandr Tkalenko . 10.02.2017 11:26

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

Відповісти

Підтримати

Євген Козлов

Євген Козлов Front-end developer в SoftServe 10.02.2017 16:49

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

Відповісти

Підтримати

Oleksandr Tkalenko

Глеб Кузнецов Independent contractor 09.02.2017 16:50

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

Відповісти

Підтримати

Костя Третяк

Костя Третяк 09.02.2017 16:55

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

Відповісти

Підтримати

Глеб Кузнецов

Глеб Кузнецов Independent contractor 09.02.2017 17:06

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

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

Відповісти

Підтримати

Костя Третяк

Olexandr Vovchok 09.02.2017 16:38

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

Відповісти

Підтримати

Taras Voloshenko :-) 09.02.2017 16:26

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

пошел за попкорном и буду смотреть на

Відповісти

Підтримати

Костя Третяк 09.02.2017 16:38

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

Відповісти

Підтримати

Taras Voloshenko

Ще 1 коментар

Владимир Черепинский BE Team Lead в Fanhub 09.02.2017 17:43

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

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

Відповісти

Підтримати

Костя Третяк

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

Ваша пошта

Не підписуватись