Как отделить программирование JavaScript от фреймворков?

Question

У меня есть один вопрос о фреймворках Javascript. Я использую ExtJs в своем приложении, но есть много проблем с лицензированием и тому подобными вещами, поэтому мне интересно об этом.
Есть ли способ следовать некоторым стратегиям в разработке Javascript, чтобы я мог легко переключаться с одной платформы Javascript на другую?

Answer 1

Если бы вы сделали это, я чувствую, что вы разработали бы свою собственную среду JavaScript. Я сомневаюсь, что это возможно. Лучше выберите один в начале и придерживайтесь его.

Answer 2

Я думаю, что никогда не бывает так просто полностью перейти с одного фреймворка на другой без переписывания большинства частей приложения. Особенно JavaScript фреймворки очень разные. Я действительно не знаю какой-либо реалистичной альтернативы тому, что предлагает ExtJS (я знаю, что у них были некоторые проблемы с лицензированием, но я до сих пор не понимаю, почему разработчики коммерческих приложений так не решаются платить от 330 до 1300 $ за то, что может предложить Framework. И если вы используете его с открытым исходным кодом, вам не нужно беспокоиться о лицензировании).

Что вам нужно сделать, это избавиться от любого специфического кода JavaScript Framework на стороне сервера (сделать передачу данных как можно более общей). Это облегчает переход на другую платформу на стороне клиента, даже если вам, вероятно, придется переписывать большую часть кодовой базы там (но только там) (я даже не вижу простого способа, например, просто перейти с Prototype на jQuery и они относительно похожи друг на друга). Единственная известная мне JS Framework, которая использует подход, не зависящий от библиотеки, - это JavaScriptMVC (например, вы можете переключаться между native, jQuery или Prototype для базовой функциональности, но даже они рассматривают возможность полностью основывать его на jQuery для следующий перевод).

Answer 3

Позвольте мне подышать свежим воздухом для обсуждения.

Основная проблема многих библиотек и фреймворков Ajax заключается в том, что у каждого из них есть свой (и собственный) API. Кроме того, разные библиотеки также позволяют и продвигают разные модели программирования. Все это действительно разумно, так как не существует стандарта API, в котором есть все функции, которые могут предложить фреймворки. Однако многие фреймворки забывают, что существует довольно базовая модель API и программирования, которая изначально заложена в браузерах - XML ​​(в простом случае HTML) для разметки, CSS для стилей и DOM для сценариев. Этот пакет доступен не только в браузерах, но также, например, в технологиях Gecko XUL, Flex и Silverlight.

Существует Javascript GUI Framework, который возвращает эту естественную модель программирования в руки разработчиков - Ample SDK . Работая с этим, вы можете макетировать свой интерфейс в устройстве XML (XHTML, XUL или SVG1.2), стилизовать пользовательский интерфейс с правилами CSS3 и по-прежнему писать код в соответствии со стандартом API DOM (уровень 2/3) браузер.

Выбрав такой подход, вы можете быть уверены, что завтра, когда все браузеры будут в равной степени хорошо реализованы базовые функции (упомянутые выше), вы сможете повторно использовать множество javascript-кода приложения, поскольку он будет работать в исходном режиме!

Действительно, это была часть истории - взаимодействие с View (хотя многие фреймворки и библиотеки javascript не проводят никакой разницы между M, V и C - в этом и заключается боль). Кодирование Javascript-приложения часто представляет собой нечто большее, чем просто взаимодействие с DOM, и тогда появляются архитектуры кода MVC и PAC. Они доказали свою эффективность, они независимы от реализации. Выберите одну реализацию (как предложено Daff - например, PureMVC) или создайте свою собственную.