Comments 4
Если честно, как-то это всё неубедительно.
Утечки памяти — они ведь не из SPA происходят, а из криворукости разработчика.
Необходимость в периодическом обновлении состоянии всей системы — хм, очень сильно сомневаюсь, что такое в принципе может понадобиться. Большинство таких моментов разрешаются или периодическим опросом, или вебсокетами.
Код, который внедряется через eval() — тоже очень странно.
В общем, интересует, как вы так разрабатывали? Что за фреймворк, почему изначально не озаботились проблемой утечек и так далее.
Сам пишу SPA с Backbone/Marionette + Symfony2 в бэкенде, и испытываю проблемы иного рода, которые скорее происходят из того, что JavaScript — достаточно дурацкий язык.
Утечки памяти — они ведь не из SPA происходят, а из криворукости разработчика.
Необходимость в периодическом обновлении состоянии всей системы — хм, очень сильно сомневаюсь, что такое в принципе может понадобиться. Большинство таких моментов разрешаются или периодическим опросом, или вебсокетами.
Код, который внедряется через eval() — тоже очень странно.
В общем, интересует, как вы так разрабатывали? Что за фреймворк, почему изначально не озаботились проблемой утечек и так далее.
Сам пишу SPA с Backbone/Marionette + Symfony2 в бэкенде, и испытываю проблемы иного рода, которые скорее происходят из того, что JavaScript — достаточно дурацкий язык.
На счёт убедительности, больше подробностей исследования будет во второй части.
Конечно, с утечками можно бороться, и даже успешно. Но учитывая тот объём функционала, который реализуется в таких приложениях, как CRM, это может повлечь за собой совершенно непредсказуемые расходы человеческих ресурсов. Обычно все существующие примеры SPA-приложений являются достаточно простыми, решающими сугубо одну задачу: электронная почта, TODO, CRUD операции и т.п. В CRM же только одна форма Сделки достаточно сложная: это много полей, с расчётными выпадающими списками, дерьевьями, редактированием Reach-текста, загрузкой файлов, и таких форм и экранов довольно много. Оно в итоге работает, но утечки при этом растут как на дрожжах, и вместо того, чтобы сосредоточиться на разработке функциональности, программист вынужден заниматься оптимизацией, да и знания всех ньюансов для прикладного фронтендщика требуются на уровне профи, что опять же без особой нужды увеличивает общий ценник проекта.
Я не говорю, что от технологий, используемых в SPA необходимо совсем отказаться. Просто нет никакой необходимости абсолютно весь функционал большущей системы засовывать на одну единственную страницу. Можно подумать о том, чтобы разбить приложение на несколько страниц, но выполненных по технологиям, применяемых в SPA.
Конечно, с утечками можно бороться, и даже успешно. Но учитывая тот объём функционала, который реализуется в таких приложениях, как CRM, это может повлечь за собой совершенно непредсказуемые расходы человеческих ресурсов. Обычно все существующие примеры SPA-приложений являются достаточно простыми, решающими сугубо одну задачу: электронная почта, TODO, CRUD операции и т.п. В CRM же только одна форма Сделки достаточно сложная: это много полей, с расчётными выпадающими списками, дерьевьями, редактированием Reach-текста, загрузкой файлов, и таких форм и экранов довольно много. Оно в итоге работает, но утечки при этом растут как на дрожжах, и вместо того, чтобы сосредоточиться на разработке функциональности, программист вынужден заниматься оптимизацией, да и знания всех ньюансов для прикладного фронтендщика требуются на уровне профи, что опять же без особой нужды увеличивает общий ценник проекта.
Я не говорю, что от технологий, используемых в SPA необходимо совсем отказаться. Просто нет никакой необходимости абсолютно весь функционал большущей системы засовывать на одну единственную страницу. Можно подумать о том, чтобы разбить приложение на несколько страниц, но выполненных по технологиям, применяемых в SPA.
проблемы иного рода, которые скорее происходят из того, что JavaScript — достаточно дурацкий язык.
А в вашем случае в чём это выражается?
Sign up to leave a comment.
SPA-архитектура для CRM-систем: часть 1