Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 37
Знаю пример, когда крупная контора перешла с использования perl на использование C++. Так что на счет «вымирания натива», автор, возможно, погорячился.
Каждой задаче свой инструмент.
Нет. Они именно переписывают сейчас на C++ то, что раньше работало на perl.
А что именно? Чтото тяжеловесное и ресурсозатратное?
Это как посмотреть. В основном там нагрузка на БД + обращение к другим внешним API.
переписывают сейчас на C++ то, что раньше работало на perl
В основном там нагрузка на БД + обращение к другим внешним APIИ как оно вяжется одно с другим, я к тому что, что например если секунда отклика была 100/900 — пёрл/чужое, а станет скажем 5/900, то чисто визуально пользователи разницы не почувствуют…
Может тогда озвучить все-таки реальную причину?
Просто у меня, совсем другие наблюдения: сразу несколько известных мне очень крупных контор делают как раз акцент на web-решениях, и кстати да, даже переписывают своих десктопных fat-клиентов на intranet-веб.
Причины банальны, но озвучу:
— кажущаяся «легкость» разработки и (местами реальная) «легкость» соединения с другими корпоративными порталами и ресурсами;
— простота установки и обновлений софта, меньшая требовательность к ресурсам клиента (в теории нужен только браузер, внимание, как проавило IE:);
— количество разработчиков на рынке труда;
Не то что бы я со всем согласен, но тенденция действительно имеет место (просто констатация).
Ну, многие говорят, что теперь полный «вебдваноль», никаких приложений — только браузер. Много ли вы знаете приложений для управления чем-то в вебе? Это редкость. Adwordseditor из известных более-менее. Разработчики 100% сталкивались с тысячей отзывов «зачем вам приложение — большинство CMS это php скриптик». Тут тоже наверняка напишут. Хотя практика применения показывает что приложения значительно функциональнее, удобнее и экономят время подготовленного оператора.
Вы прямо какую-то магическую силу придаете словам «бинарный» и «скомпилированный» :)
Ну и как-то странно видеть, на самом деле, сопоставление кода на Дельфи с хтмлем. Не совсем понятно, что хотели этим сказать.
Не смотря на то, что я знаком с «дельфи» еще с тех пор когда оно называлось «ТурбоПаскаль фор Видновз», с трудом могу себе представить, какие бонусы при построении CMS магазина может дать этот инструмент.
Или у вас там какие-то очень специфические условия?
Ну и как-то странно видеть, на самом деле, сопоставление кода на Дельфи с хтмлем. Не совсем понятно, что хотели этим сказать.
Не смотря на то, что я знаком с «дельфи» еще с тех пор когда оно называлось «ТурбоПаскаль фор Видновз», с трудом могу себе представить, какие бонусы при построении CMS магазина может дать этот инструмент.
Или у вас там какие-то очень специфические условия?
Я хотел указать на сходство. Мне как программисту, все больше и больше разработка веб-приложения под браузер напоминает разработку нативного приложения под ОС.
Ключевые бонусы, которые мы достигли это скорость и комфортность работы. Поскольку мы использовали нашу же CMS для создания своего магазина, то мы получили преимущества и вывели магазин в лидеры (в нашем товарном сегменте). Назвать наши условия специфическими… ну в принципе да, они не рядовые, то есть магазин однозначно не начального уровня. Поэтому, если задачи для CMS несложные, то конечно «из пушки по воробьям» нет смысла стрелять, используя нативную CMS.
Ключевые бонусы, которые мы достигли это скорость и комфортность работы. Поскольку мы использовали нашу же CMS для создания своего магазина, то мы получили преимущества и вывели магазин в лидеры (в нашем товарном сегменте). Назвать наши условия специфическими… ну в принципе да, они не рядовые, то есть магазин однозначно не начального уровня. Поэтому, если задачи для CMS несложные, то конечно «из пушки по воробьям» нет смысла стрелять, используя нативную CMS.
Как программист программисту могу сказать, что по большому счету разработка веб приложений ничем принципиально не отличается от разработки «компилируемых» приложений. Всегда есть определенные условия и особенности платформы, только и всего. Не всегда это очевидно сразу, но по мере накопления опыта этот момент становится очевиден.
Возможно у нас разные представления относительно понятия CMS? Но обычно под этим подразумевается некий программный компелекс, который включает в себя такие компоненты, как хранилище данных, генератор представлений для вебпользователя, средства модификации самой информации и ее структуры (метаданных), средства администрирования. У вас все это на Дельфи написано или нет?
Я знаю системы, написанные на Дельфи (включая дата сторидж!), которые уже много лет успешно эксплуатируются тысячами пользователей на просторах нашей необъятной Родины.
Но современную CMS городить на Дельфях могут заставить только сильные завязки на legacy code или чрезмерное количество непереобучаемых «программистов старой школы», которые не в курсе, что быстрый и удобный интерфейс с полной клавиатурной навигацией «вебсредствами» делается на раз-два.
Возможно у нас разные представления относительно понятия CMS? Но обычно под этим подразумевается некий программный компелекс, который включает в себя такие компоненты, как хранилище данных, генератор представлений для вебпользователя, средства модификации самой информации и ее структуры (метаданных), средства администрирования. У вас все это на Дельфи написано или нет?
Я знаю системы, написанные на Дельфи (включая дата сторидж!), которые уже много лет успешно эксплуатируются тысячами пользователей на просторах нашей необъятной Родины.
Но современную CMS городить на Дельфях могут заставить только сильные завязки на legacy code или чрезмерное количество непереобучаемых «программистов старой школы», которые не в курсе, что быстрый и удобный интерфейс с полной клавиатурной навигацией «вебсредствами» делается на раз-два.
У нас написан гибридный комплекс :) Говоря по-простому — админка CMS это нативное приложение со встроенными в нее веб-модулями (на случай если не хватает функционала). Сама же система (PHP-ядро) является конечно же веб-приложением — фреймверком, на котором и разрабатываются и работают модули формирующие витрину (классические MySQL+PHP+HTML).
Мой знакомый в 2004 году разработал примерно такую же систему. Долго ее делал и кормил завтраками и бажными релизами начальство магазина, в котором я тогда работал. Потом ни шатко ни валко продавал ее как готовое решение.
То есть вы успешно воспользовались более знакомым инструментом для решения конкретной задачи. Это вполне резонно.
Тем не менее, рекомендую более внимательно ознакомиться с современными вебтехнологиями, так как они позволяют делать практически такие же вещи быстрее и гибче, а ниша «динозавров» типа Дельфи с каждым днем все меньше.
Чтобы уйти от предрассудков «компилированного кода» почитайте про устройство, например, гуглового V8 или посмотрите какую-нибудь браузерную opengl'ную демку.
Тем не менее, рекомендую более внимательно ознакомиться с современными вебтехнологиями, так как они позволяют делать практически такие же вещи быстрее и гибче, а ниша «динозавров» типа Дельфи с каждым днем все меньше.
Чтобы уйти от предрассудков «компилированного кода» почитайте про устройство, например, гуглового V8 или посмотрите какую-нибудь браузерную opengl'ную демку.
приложений на Delphi действительно с каждым днем все меньше, как впрочем и самой операционной системы Windows. Но тут есть мысленная ловушка, которая заключается в том, что «стало меньше, не означает что стало мало». Просто рынок пользователей разделился в согласно своим потребностям, и как следствие этого оказалось, что хоть многим и нужен компьютер, но вовсе необязательно чтобы на нем была винда, и вовсе необязательно использовать тогда нативные приложения. Но остается все-таки бизнес, который технологичен до такой степени, что не откажется от натива (как я думаю).
В частности это и относится к вопросу интернет-магазинов. На самом деле это направление достаточно молодое и переживает бум «наполнения», то есть уровень вхождения в этот бизнес остается достаточно невысоким. Однако, все же общая тенденция такова, что месяц за месяцем начинает происходит укрупнение магазинов. То есть, маржинальность на товаре уменьшается, стоимость рекламы увеличивается, конкуренты демпингуют и т.п. В этом случае у состоявшихся проектов остается не так много вариантов выживания(развития), один из них это увеличение товарооборота и сокращение издержек. Именно увеличение товарооборота и потребует от магазинов большей технологичности, которую и смогут обеспечить нативные решения.
В частности это и относится к вопросу интернет-магазинов. На самом деле это направление достаточно молодое и переживает бум «наполнения», то есть уровень вхождения в этот бизнес остается достаточно невысоким. Однако, все же общая тенденция такова, что месяц за месяцем начинает происходит укрупнение магазинов. То есть, маржинальность на товаре уменьшается, стоимость рекламы увеличивается, конкуренты демпингуют и т.п. В этом случае у состоявшихся проектов остается не так много вариантов выживания(развития), один из них это увеличение товарооборота и сокращение издержек. Именно увеличение товарооборота и потребует от магазинов большей технологичности, которую и смогут обеспечить нативные решения.
А почему, говоря «native» вы подразумеваете только С++ и Delphi, но не учитываете ту же Java?
ну почему не учитываю ) я отношу Java к тому же нативу (если речь конечно о клиенте). В данном разрезе вопроса отличие Java только в том, что с ее помощью натив получается универсальным для различных ОС.
3-й абзац топика и коммент выше показывает обратное — не учитываются кроссплатформенные языки разработки для native-приложений (не только Java).
О, круто! У нас уже и Java в native-приложение попало :)
Извините за иронию. Но желаю поскорее освободиться от ваших личных заблуждений насчет «натива». И заканчиваю свое участие в этом околофилософском диалоге.
Извините за иронию. Но желаю поскорее освободиться от ваших личных заблуждений насчет «натива». И заканчиваю свое участие в этом околофилософском диалоге.
Да, если брать «академическое» определение native-приложений, то Java сюда не попадает — в этом случае тут скорее будет более уместно говорить desktop-приложение.
Вы же про это «заблуждение» говорите?
Вы же про это «заблуждение» говорите?
Согласен, десктопное приложение более широкое понятие и этот термин подойдет лучше. Ну сути ведь он не меняет? мне надо было разделить те приложения которые работают в браузере и те которые пишутся под ОС. Традиция называть их нативными взяла вверх. Или я что-то упустил и есть ERP CRM системы написанные на Java и которые работают на любых ОС через браузер?
Я бы не сказал, что комфортность разработки в вебе ниже. По мне так наоборот — примитивный html я способен написать в любимом редакторе vim, а потом отдать дизайнеру. А современный нативный GUI разрабатывается с помощью сложных инструментов, которые я так и не осилил.
Вобщем, я закончу эту мысль, подытожив: очень мало кто из нас пишет на машинном коде, так что смиритесь, все мы управляемые, и нами давно манипулируют (если задето самолюбие, то читай: за нас борются, нас завлекают). Это я к тому, чтобы у Вас не было иллюзий типа “я пишу на самом правильном языке или использую самую оптимальную технологию”.
А что, разве библиотеки есть только в JS?
Интерфейс: Не стандартизирован. Есть аналогичные объекты (кнопка, поле ввода и т.п.), но это не объекты ОС, а схожие объекты браузера и их значительно меньше. Большая часть объектов реализуется разработчиком самостоятельно.
Ну окей, и что дальше? Для интерфейсов есть куча библиотек. Есть даже Objective-J, который позволяет макось-разработчикам писать по ощущениям натурально нативные приложения.
Производительность (интерфейс): Средняя или низкая. Приложение интерпретируемое и работает в бразуере — надстройке в ОС, поэтому имеет доступ только к ресурсам браузера. Ключевым показателем при выборе браузера до сих пор является его скорость работы, что подтверждает актуальность вопроса.
asm.js по перформансу приближается к приложениям на c++ (полгода назад был всего в 2 раза медленнее). В него можно скомпилировать любой llvm-код (это уже про то, что библиотеки скудны и их мало).
я могу докопаться до половины фраз, просто по-моему вы не до конца понимаете, в чем разница между веб-приложением и обычным приложением.
Веб-приложение — это в 99% случаев морда до определенного бэкэнда, которая должна БЫСТРО загружаться, и предоставлять определенную информацию или интерфейс. Она может в любой момент закрыться, должна быстро перезапускаться и хорошо кэшироваться.
С нативными приложениями никому и в голову не придет тягаться, тут слишком разный класс задач.
Даже если говорить про игры: казуалки лучше пойдут в браузере (быстрая загрузка, интеграция с соцсетями), а тяжеловесов в веб нельзя: если кэш случайно потрется, вы будете опять выкачивать 25гб unreal tournament 2015 по мобильному интернету?
Вы попробуйте отойти от примитивного примера интерфейса, указанного в статье, хотя бы до уровня классического интернет-магазинчика. Не говоря уже о резиновом адаптивном интерфейсе с тенями, и прочими визуальными благами. В этом главный недостаток TForm — в нём практически всё позиционируется абсолютно, и в случае увеличения объёмов текста, или увеличения dpi экрана, чтобы всё это выглядело так же, как и в браузере, нужно написать тонны кода.
резиновом адаптивном интерфейсеЗолотые слова (почти), подтверждаю — после многих лет активной разработки и там и там, мне абсолютно фиолетого на чем писать сам интерфейс пользователя (уточняю клиентскую часть) но веб-решение будет сделано быстрее и за то же время сами формы будут много динамичнее, удобнее для пользователей и т.д.
К сожалению всегда есть ложка дегтя, например крайний раз нужно было прицепить к много лет работающему web-решению drag+drop и copy+paste документов из outlook. Сделать то, сделал, но вот тогда приходилось уже бубен расчехлять… (где для десктопного приложения такое пишется влёт).
здесь речь идет только об управлении проектом — админке, поэтому вопрос с тенями здесь неактуален
Тогда к чему у вас в статье сравнение кода формы и соответствующего ему html? Вы хотели показать, что код html ни что иное как натив, при этом сравнение некорректно, так как пример упрощен до безобразия. Веб — это в первую очередь удобный инструмент для проектирования сложных интерфейсов с динамическим контентом.
Настолько спорно, каждый абзац и через предложение, что аж мерещится целое племя довольно-таки голодных тролей.
Ерунда какая-то. Под Мак, например, очень много софта появляется, именно от традиционных интернет-компаний, и такие приложения гоооораздо удобнее их веб-версий (посмотрите на тот же Spotify).
Под плитки Windows 8 тоже приложений много разрабатывается (только клиентов для ВК и Facebook'a по нескольку штук).
Под плитки Windows 8 тоже приложений много разрабатывается (только клиентов для ВК и Facebook'a по нескольку штук).
Да, автор подставился — плюсанул, так как понял, что автора будут валить троли :)
А вообще сравниваем старый век, когда надо говорить о ASP.NET, а не HTML-е
Как-то путано написано. Веб-приложение без серверсайда — большая редкость, а серверсайд по сути — то же «нативное» приложение, построенное по определенным правилам и завернутое в веб-сервер.
Я написал про серверсайд:
А теперь посмотрите, как интересно получается: разработка серверных скриптов, отвечающих за подготовку данных, по сути ничем не отличается как для нативных приложений, так и для веб-приложений. Ведь, как я уже упомянул в таблице, общая тенденция такова: вынести HTML-код за рамки скриптов и передавать\принимать данные в формате XML или JSON. Таким образом, задача клиентских приложений — принять данные, визуализировать их, получить новые данные и передать их на сервер.
То есть, его в данном случае рассматривать не вижу смысла, ведь речь идет о фронтэнде…
А теперь посмотрите, как интересно получается: разработка серверных скриптов, отвечающих за подготовку данных, по сути ничем не отличается как для нативных приложений, так и для веб-приложений. Ведь, как я уже упомянул в таблице, общая тенденция такова: вынести HTML-код за рамки скриптов и передавать\принимать данные в формате XML или JSON. Таким образом, задача клиентских приложений — принять данные, визуализировать их, получить новые данные и передать их на сервер.
То есть, его в данном случае рассматривать не вижу смысла, ведь речь идет о фронтэнде…
Надо писать код на том, в чем больше разбираешься. Главное результат и затраченное время. Хороший заменитель натива — это 1С, в ее оболочке можно описать почти любой интерфейс парой строк, есть куча встроенных функций и библиотек. Код получится открытый, можно редактировать. Для интернет-магазина, писать еще один админ-натив спорно. В 1С и так есть вся информация по товарам, заказам и покупателям. Все это удобно редактируется. Остается только грамотно все это выгрузить на сайт и синхронизировать остатки и заказы. По хорошему, если есть рабочий 1С (ваша бухгалтерия ведется в этой учетной систем), то бексайд и не нужен — зачем по сто раз авторизоваться и обрабатывать одну и туже информацию? Если кто спросит, а как же редактирование страниц/новостей/статистики и подобных неотъемлемых частей интернет-магазина, то при желании и умении, все это можно/нужно/уже вынести в редактирование в 1С. Немножко ссылок на примеры реализаций нашего «натива для управления ИМ в 1С» 1, 2.
Из минусов такого подхода, как и описанного автором натива — обязательное присутствие доступа к 1С серверу для возможности управления. Веб-бексайд требует лишь браузер и не привязывает админа к офису. Но с другой стороны у 1С есть режим управляемого приложения (надо оговориться, что не для всех конфигураций и версий 1С, но уже хорошо), что дает возможность управлять удаленно через браузер в привычной среде 1С. Для офиса нужно правильно прописать порты на роутете для удаленного захода в офисный 1С из любой части света через браузер, но это уже семечки.
Из минусов такого подхода, как и описанного автором натива — обязательное присутствие доступа к 1С серверу для возможности управления. Веб-бексайд требует лишь браузер и не привязывает админа к офису. Но с другой стороны у 1С есть режим управляемого приложения (надо оговориться, что не для всех конфигураций и версий 1С, но уже хорошо), что дает возможность управлять удаленно через браузер в привычной среде 1С. Для офиса нужно правильно прописать порты на роутете для удаленного захода в офисный 1С из любой части света через браузер, но это уже семечки.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Натив умер. Да здравствует натив!