Зараз я дивлюся на node.js і на його наслідки для продуктивності (я захоплююсь швидкістю), але я не дуже багато вникав у це.
Профіль, профіль, профіль. Це єдиний спосіб знати, що ваші скорочення справляють належний вплив. Ви можете здогадатися, що це досить швидко. Але більшість людей люблять передчасно оптимізувати. Це гірше, ніж грати із собою під час побачення.
Мені цікаво, чи node.js може повністю замінити мою типову розробку веб-сторінок у C # та ASP.NET MVC, якщо це краще як доповнення до C # та ASP.NET MVC, чи є якісь речі, які повинні просто «залишити достатньо добре в спокої ".
Чи є випадки використання для / проти C # та node.js?
Звичайно, якщо ви знаходитесь в магазині, який регулярно пише код на C #, тоді вам слід використовувати MVC (це набагато краще, ніж WebForms, і називається WebPages). Ви не будете втрачати багато часу на підготовку з інструментарію, і це те, з чим уже мають працювати ваші робочі процеси.
Те, що ви, здається, не вказуєте вище, - це причини вибору кожного. Ви дали два поточні ринкові варіанти, один на етапі Alpha, а другий на третьому році випуску платформи. Я б не хотів порівнювати поточну модель тестування електромобілів з гібридами Honda, які вже виходять на ринок. Вони в двох різних лігах.
Тепер ось вам причина, щоб не триматися подалі від node.js, якщо ви номінально є магазином C #.
Наразі ви не працюєте в асинхронному парному введення-виводу, зараз працюєте в процедурному форматі.
Це антитеза до того, що nodejs збирається зробити для вас.
Однак якщо ви часто пишете код асинхронізації в C #, і ви багато використовуєте його в стильному стилі, то так, node.js для вас серйозно розглядає.
Ось що ви відмовитеся:
IIS - Це насправді важливо для багатьох людей. Такі речі, як рідна інтеграція A / D, вже зроблені, і досить непоправні. Насправді node.js тепер добре інтегрується з IIS.- Шаблонні бритви - якщо ви зробили будь-який серйозний C # MVC, ви використовуєте та любите Бритву та як швидко ви можете виправити речі. У вузлі є схожі шаблони, і я, звичайно, не збиваю вузол, але весь ланцюжок інструментів вже присутній у C #, і багато його наразі будується у світі вузлів. Примітка: багато цього інструментарію зараз досить зріле _
- збирання dlls за часом компіляції - node.js зазвичай збирається на ходу, тобто не всі шляхи перевіряються при запуску. Цілком можливо мати дійсно поганий код у вузлі, до якого ніхто ніколи не торкається, перевіряє чи не перевіряє.
- Всі інструменти, в даний час вбудовані у VS, якими ви користуєтесь щодня - Просто не так багато підтримки VS для JavaScript. Почасти тому, що все в JavaScript настільки динамічно. NB: Microsoft, очевидно, працює над підтримкою інструментарію для JavaScript _
Ось що ви отримаєте:
- все, що ви розробляєте, буде на тій же мові, якщо припускати, що ви робите сценарії на стороні клієнта, а також на стороні сервера. (або чому ви навіть розглядаєте javascript на сервері)
Отже, оскільки я, здається, цілком б'є тут Вузол, дозвольте мені зазначити, що вузол - це моя грана мова вдома, я люблю це, і я допомагаю людям налагоджувати його іноді на серверах чатів stackoverflow (кімната 642). Я бачу, що він має великий та надзвичайний потенціал у майбутньому.
Я просто кажу, не кидайте дитину і дивуйтеся, чому ванна вода брудна.
Ви не дали причини, чому вам слід відмовитися від багаторічного досвіду і почати щось нове. Чи це погані інструменти? Зовсім ні. Обидва чудові і роблять розвиток вітер.
Чи може вузол замінити C #? Так, цілком точно. Так може бути PHP або Java або Ruby. Ви про це не питаєте.
Ось як ви знаєте, коли ви готові запрограмувати node.js замість C #:
- Ви розглядаєте можливість написання книги, щоб допомогти іншим "отримати javascript" замість нудних старих програм, які вони писали раніше в C # і т.д.
- У вас виникли проблеми із синхронним (блокуванням) вводу / виводу, що зупиняє ваші програми на практичній роботі.
- Ви не використовуєте жодних бібліотек в C #, крім MVC за замовчуванням, і лише для маршрутизації, і ви впевнені, що можете зробити кращий механізм маршрутизації, і ви кодуєте все як можна ближче до металу.
- Кожен об’єкт даних, який ви проектуєте, бачите як хеш замість сильно набраного об’єкта.