Pull to refresh

Big switch или жизнь после Microsoft: Почему мы сказали .NET'у нет

Reading time 3 min
Views 12K
До недавнего времени предано нес знамя Microsoft .NET. Восхвалял Silverlight, ASP.NET MVC и верил в чудеса. За четыре года работы c .NET стал сертифицированным разработчиком по широкому спектру
технологий: ASP.NET, WCF, WPF, ADO.NET. Однако за год существования собственного интернет агентства разочаровался в выбранном пути и обратился в другую веру.
image

В серии статей “Big switch или жизнь после Microsoft” я расскажу об опыте полученном нашей командой при переходе со стэка веб-технологий Windows + .NET на Linux + Ruby on Rails, а также приведу конкретные инструкции к применению, которые помогут на первых порах.

Начну я с 3-х причин, которые побудили нас сказать .NET'у нет.


1. Зависимость


image

Работая с продуктами .NET вы обрекаете себя на зависимость. Зависимость от платного программного обеспечения и бесконечного множества платных компонент, начиная от графического интерфейса и заканчивая банальным сбором почты по протоколу IMAP.

Вы тратите львиную долю времени на изучение лицензий и цен для поиска подходящей конфигурации. Вам приходится мириться с тем, что remote desktop не поддерживает двух подключений, а в состав windows web server 2008 не входит dns-сервер.

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

2. Закрытость


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

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

Качество продукта с открытым исходным кодом можно оценить основываясь на более весомых факторах:
  • Покрытие тестами.
  • Частота обновлений.
  • Количество загрузок.
  • Количество и личности разработчиков.

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

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

Стоит отметить, что Майкрософт начал делать шаги в сторону открытого исходного кода. Однако пока это можно назвать лишь поползновениями, так как в реальности выкладываются лишь срезы соответствующие определенной бете или релизу. В результате чего сообщество по-прежнему безучастно в жизни продукта и со слюной у рта ждет очередного релиза. Для убедительности приведу лог коммитов проекта ASP.NET MVC:

image

3. Microsoft way


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

Еще вчера Майкрософт делал собственный JavaScript фреймворк и благо в конечном итоге внедрил Jquery. Тоже самое можно сказать и о технологии ASP.NET, которая за 5 лет до появления ASP.NET MVC показала свою полную несостоятельность.

Несмотря на положительную тенденцию, которые задал ASP.NET MVC (веб-фреймворк полностью дублирующий Ruby on Rails, однако, лишенный прелестей динамического языка) Майкрософт по прежнему наступает на те же грабли. Так, например, в новой версии вместо адаптации Haml нам обещают Razor, который будет «очень удобен» и все будут «счастливы».

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

image

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

Проанализировав альтернативные открытые решения, мы остановились на фреймворке Ruby on Rails, который на наш взгляд имеет очень большое и главное профессиональное сообщество (редко можно найти проект без тестов).

В последующих статьях данного цикла я на конкретных примерах покажу преимущества Ruby on Rails над ASP.NET MVC и другими продуктами Майкрософт, приведу инструкции по безболезненному переходу на Ruby on Rails для людей далеких от мира Linux и открытых технологий.
Tags:
Hubs:
+173
Comments 253
Comments Comments 253

Articles