Согласен, десктопное приложение более широкое понятие и этот термин подойдет лучше. Ну сути ведь он не меняет? мне надо было разделить те приложения которые работают в браузере и те которые пишутся под ОС. Традиция называть их нативными взяла вверх. Или я что-то упустил и есть ERP CRM системы написанные на Java и которые работают на любых ОС через браузер?
Я не совсем Вас понял, Вы рассматриваете 1С как НЕ нативное приложение?
Я склонен думать, что 1С это все же нативное приложение. Да его БД может быть в облаке (либо идет репликация между базами), но клиент по прежнему работает в винде ведь?
А теперь посмотрите, как интересно получается: разработка серверных скриптов, отвечающих за подготовку данных, по сути ничем не отличается как для нативных приложений, так и для веб-приложений. Ведь, как я уже упомянул в таблице, общая тенденция такова: вынести HTML-код за рамки скриптов и передавать\принимать данные в формате XML или JSON. Таким образом, задача клиентских приложений — принять данные, визуализировать их, получить новые данные и передать их на сервер.
То есть, его в данном случае рассматривать не вижу смысла, ведь речь идет о фронтэнде…
ну почему не учитываю ) я отношу Java к тому же нативу (если речь конечно о клиенте). В данном разрезе вопроса отличие Java только в том, что с ее помощью натив получается универсальным для различных ОС.
приложений на Delphi действительно с каждым днем все меньше, как впрочем и самой операционной системы Windows. Но тут есть мысленная ловушка, которая заключается в том, что «стало меньше, не означает что стало мало». Просто рынок пользователей разделился в согласно своим потребностям, и как следствие этого оказалось, что хоть многим и нужен компьютер, но вовсе необязательно чтобы на нем была винда, и вовсе необязательно использовать тогда нативные приложения. Но остается все-таки бизнес, который технологичен до такой степени, что не откажется от натива (как я думаю).
В частности это и относится к вопросу интернет-магазинов. На самом деле это направление достаточно молодое и переживает бум «наполнения», то есть уровень вхождения в этот бизнес остается достаточно невысоким. Однако, все же общая тенденция такова, что месяц за месяцем начинает происходит укрупнение магазинов. То есть, маржинальность на товаре уменьшается, стоимость рекламы увеличивается, конкуренты демпингуют и т.п. В этом случае у состоявшихся проектов остается не так много вариантов выживания(развития), один из них это увеличение товарооборота и сокращение издержек. Именно увеличение товарооборота и потребует от магазинов большей технологичности, которую и смогут обеспечить нативные решения.
У нас написан гибридный комплекс :) Говоря по-простому — админка CMS это нативное приложение со встроенными в нее веб-модулями (на случай если не хватает функционала). Сама же система (PHP-ядро) является конечно же веб-приложением — фреймверком, на котором и разрабатываются и работают модули формирующие витрину (классические MySQL+PHP+HTML).
Я хотел указать на сходство. Мне как программисту, все больше и больше разработка веб-приложения под браузер напоминает разработку нативного приложения под ОС.
Ключевые бонусы, которые мы достигли это скорость и комфортность работы. Поскольку мы использовали нашу же CMS для создания своего магазина, то мы получили преимущества и вывели магазин в лидеры (в нашем товарном сегменте). Назвать наши условия специфическими… ну в принципе да, они не рядовые, то есть магазин однозначно не начального уровня. Поэтому, если задачи для CMS несложные, то конечно «из пушки по воробьям» нет смысла стрелять, используя нативную CMS.
Я склонен думать, что 1С это все же нативное приложение. Да его БД может быть в облаке (либо идет репликация между базами), но клиент по прежнему работает в винде ведь?
А теперь посмотрите, как интересно получается: разработка серверных скриптов, отвечающих за подготовку данных, по сути ничем не отличается как для нативных приложений, так и для веб-приложений. Ведь, как я уже упомянул в таблице, общая тенденция такова: вынести HTML-код за рамки скриптов и передавать\принимать данные в формате XML или JSON. Таким образом, задача клиентских приложений — принять данные, визуализировать их, получить новые данные и передать их на сервер.
То есть, его в данном случае рассматривать не вижу смысла, ведь речь идет о фронтэнде…
В частности это и относится к вопросу интернет-магазинов. На самом деле это направление достаточно молодое и переживает бум «наполнения», то есть уровень вхождения в этот бизнес остается достаточно невысоким. Однако, все же общая тенденция такова, что месяц за месяцем начинает происходит укрупнение магазинов. То есть, маржинальность на товаре уменьшается, стоимость рекламы увеличивается, конкуренты демпингуют и т.п. В этом случае у состоявшихся проектов остается не так много вариантов выживания(развития), один из них это увеличение товарооборота и сокращение издержек. Именно увеличение товарооборота и потребует от магазинов большей технологичности, которую и смогут обеспечить нативные решения.
Ключевые бонусы, которые мы достигли это скорость и комфортность работы. Поскольку мы использовали нашу же CMS для создания своего магазина, то мы получили преимущества и вывели магазин в лидеры (в нашем товарном сегменте). Назвать наши условия специфическими… ну в принципе да, они не рядовые, то есть магазин однозначно не начального уровня. Поэтому, если задачи для CMS несложные, то конечно «из пушки по воробьям» нет смысла стрелять, используя нативную CMS.