Як давній розробник настільних комп'ютерів, який розглядає перше масштабне веб-додаток, які плюси та мінуси робити веб-розробка?

Чи розвивати веб-додаток набагато гірше, ніж розробляти настільний додаток? Наприклад, це більш нудно чи дратує? Чи час на ринок набагато гірший? Чи надмірно обмежує веб-платформа? Якщо відповідь на будь-яке з них - так, то чому?

(І як порівнюється розробка програми Flash або Silverlight?)

Ні

Боляче, якщо ти не знаєш, що ти робиш, або не плануєш правильно, але це правда з будь-якою розробкою. Простіше розлити додаток у настільний додаток, але тоді ви втрачаєте доступність, яку забезпечує кодування веб-програми.

Я б зробив вибір між настільним та веб-сайтом на основі бажаного використання. Я бачу багато програм, написаних на веб-основі, що не повинно бути, тому що вони не знають, як кодувати додатки для настільних ПК. Я не бачу багатьох настільних додатків, які мають базуватися на веб-сторінках, і я думаю, що це варто врахувати. Якщо вам потрібні централізовані функції зберігання, віддалений доступ та інтерфейс користувача, то обов'язково .

Я не можу коментувати Flash або Silverlight, тому що не використовую жодного.

Як зазначають інші, це питання компромісів та правильних знань.

Єдиний підводний камінь, який ви можете розглянути, - це ви: у своєму запитанні ви згадуєте, що в Інтернеті ви бачите як "перехресну платформу" як перевагу. Але чи справді це? Подумайте про це так: якщо ви розробляєте щось для робочого столу, вам потрібно визначити список платформ та їх вимоги до підтримки.

Не помиляйтесь, це те саме для Інтернету. І хоча це вже надзвичайно простіше, ніж раніше, якщо ви розробляєте широкий публічний додаток, вам доведеться мати справу з усіма можливими версіями кожного веб-браузера там. І якщо це більше корпоративного додатку, то створіть себе та підготуйтеся до складання своїх підтримуваних платформ браузерів дуже точно.

Не думайте, що тут і там ви не уникнете зламати конкретні платформи, якщо будуєте щось значне.

А потім веселі частини. Що найкраще? Веб-переглядачі, які майже регулярно оновлюються, як Chrome? Або ті, які впроваджують безпеку, оновлюються лише щомісяця та основними функціями кожного кам'яного віку (як IE)? Відповідь не така очевидна, як ви могли б подумати, тому що деякі з цих частих "прозорих" оновлень можуть порушити ваш код, і вам потрібно буде дотримуватися цього та негайно реагувати. Або слідкуйте за попередніми версіями бета та розробників під час розробки та тестування. Для всіх браузерів ви нерозумно сказали, що хочете підтримати (удачі).

О, і не будемо забувати міркування щодо інтерфейсу користувача. Ви також стикаєтеся з радістю вирішувати, чи хочете ви послідовно користувальницького інтерфейсу ПРОСТО ВСІХ своїх цільових платформ чи послідовного інтерфейсу зкожен цільовий майданчик. Побачити всі ті маленькі кнопки, які можна переглянути на веб-сторінках? Ви хочете, щоб вони скрізь були однаковими або інтегрувались із середовищем, яке використовує ваш користувач? Звичайно, ця проблема не є новою та існувала для інших моделей розробки, але вона, здається, є важливішою тут і залежить від типу користувачів, на яких ви орієнтуєтесь, і чого вони очікують. Громадський кінцевий користувач, як правило, хоче, щоб ви інтегрувались із їх платформою - але все одно хочете, щоб ви "ого!" їх з вигадливими речами - тоді як корпоративний користувач захоче щось, схоже на додаток для настільних ПК. І мобільні платформи мали новий вимір у всьому цьому.

Для останніх 2 абзаців загальною ідеєю є інколи встановити пакунок заздалегідь налаштованого веб-браузера зі своїм інсталятором, який потім підключатиметься до вашого веб-додатку (локально розміщеного або в Інтернеті). Це чудово, тому що ви керуєте частотою оновлення, і ви можете "заморозити" стан, і ви точно знаєте, на чому підтримувати та перевіряти. Крім того, ви можете додавати цікаві речі, такі як спеціальні розширення для користувачів. Наприклад, упаковка «замороженого» Chromium за допомогою невеликих розширень Chrome, розроблених для полегшення використання веб-додатків для різних типів користувачів, може бути надзвичайно приємною. З іншого боку, ви зараз відповідаєте за порушення безпеки, оскільки ви заморозили цикл випуску, і ваш додаток не скористається покращенням швидкості (якщо є).

Як і багато речей, це сокира з двома краями.

Примітка. У мене є сильна упередженість щодо Інтернету, оскільки це в основному велика купа напівфабрикованих технологій (і я тут ввічливий), аж до шарів OSI, на яких ми продовжуємо додавати шари лайна, приховуючи проблеми внизу, не реально вирішуючи або їх фіксація.

Попри це, я виступаю за Інтернет за його всюдисущу природу як платформу. Я думаю, що ваш крок компанії (мабуть) правильний. Очевидно, це залежить від вашого цільового ринку та платформ, на які ви прагнете. Якщо ви хочете викрити щось як послугу, ви, мабуть, добре піти (хоча це теж не потрібно). Якщо ви цього не зробите, то, можливо, причин для цього не так багато.

Хм, і очікуйте цікавих розробок у майбутньому зараз, коли більш легкі варіанти існуючих операційних систем продовжують нереститися для мобільних середовищ (нетбуків, смартфонів, КПК, планшетів, електронних книг ...), приділяючи більше уваги використанню легких вбудованих браузерів. .. але з усією своєю новою часткою глюків, що надають інтерфейс користувача.

Щодо технологій, що базуються на плагінах ... я б сказав, тримайтеся подалі від них. Вони підвищать потужність вашого додатка, але обмежать його проникнення на ринок. У деяких випадках ви побачите це як плюс у плані підтримки міжплатформ, поки нова платформа раптом не відмовиться їх підтримувати. Веб-стандарти тут є з причини (будьте обережні, щоб не надто хвилюватися з приводу всього, що є в HTMl5, інакше це може підірватися вам на обличчя)

РЕДАКТУВАННЯ: інші речі для розгляду ...

Набір персоналу

Це дуже важко знайти знають веб - розробник. Ви можете подумати, що там є їхнє стадо, але вони втрачаються у величезному пулі, ну, досить некомпетентних людей, які думають, що зуміли написати 700 рядків JavaScript / ECMAScript, щоб реалізувати певну перевірку у своїх формах - це все-таки все і бути всім, чого можна досягти за рахунок навичок високого рівня.

Я не жартую, останнім часом моє перше питання для всіх інтерв'ю з веб-розробки - як оголосити змінну, а потім, чи існує різниця між використанням varчи ні (залежно від того, як вони відповідають). Це гнітюче. Мені набагато складніше знайти середнього або просунутого веб-розробника, ніж знайти середнього або просунутого розробника настільних ПК.

Сприйняття

Ніхто ніколи не стане вважати вас серйозно, коли ви скажете "Я веб-розробник". Це для підкласу програмістів, розробників, чи не так? Ті, кого ви ігноруєте та знущаєтесь здалеку, і не приєднуйтесь, коли вони йдуть по каву. :)

Це, очевидно, неправда, але воно зводиться до того, що ви розробляєте для середовища, яке в основному для вас управляється. Веб-переглядачі виправляють вашу розкручену розмітку, стилі, які ви накрутили, і навіть виправлятимуть накручені сценарії для деяких із них та оптимізують її для вас, якщо вам потрібно. І якщо ви веб-розробник, люди не будуть вважати, що у вас є поняття про програмування нижчого рівня, тому ви повинні бути повноцінним ідіотів, правда?

І тоді вони розуміють, наскільки божевільно складний ECMAScript може бути, але відмовляться переглядати свою думку. Тому що це веб. Нам це не подобається по суті, нам просто подобається те, що він дозволяє нам робити.

Як хтось, хто має справу з обома (хоча більше робочого столу, ніж веб): на сьогоднішній день моїм найбільшим захопленням є відчуття "загальної незграбності" у веб-розробці. Навіть з найкращими інструментами та рамками, абстракції все ще дуже проникливі, і ти постійно маєш справу з тим, що ти працюєш над протоколом без громадянства.

Інший пов'язаний роздратування - це поєднання технологій, які використовуються для впровадження веб-додатків. Немає приємного, монолітного, модульного середовища та мови, з яким все можна зробити. Навіть порівняно прості веб-програми вимагають кодування речей у кількох мовах програмування, сценаріїв та розмітки.

Отже, як загальна відповідь: Так , це дійсно так погано. Принаймні, якщо ви приїжджаєте з традиційного фону робочого столу, де ви звикли кодувати речі в чистому, безшовному середовищі, використовуючи технологію та платформу, де все досить лінійно і чітко визначено. Найкращий спосіб - просто не намагатися думати про це як про те саме поле. Якщо ви підсвідомо сподіваєтесь, що веб-розробка буде «як розробка на робочому столі», вона завжди буде виглядати дуже неприємно і дратівливо.

Найбільше переосмислення, що переходить від робочого столу до Інтернету: веб-додаток за своєю суттю без громадянства

розібратися, що розлучитися, і ти хороший.

Значна стомлюваність пов'язана з роботою, необхідною для того, щоб все працювало у всіх браузерах. Оскільки вам, швидше за все, не потрібно знаходитись на межі, що кровоточить, ви можете скористатися роботою, яку виконують інші, вибравши відповідну веб-рамку замість того, щоб переглядати власну.

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

Ні, веб-додатки мають інші вигоди, ніж настільні програми. Кожен має свої сили на мій погляд. Хоча існують сильні сторони, як одне розгортання, можливо, ви знаєте, які браузери ви підтримуєте, і яку роздільну здатність екрана ви очікуєте від клієнта? Хоча у вас є контроль над апаратним забезпеченням сервера, виникає питання про те, скільки трафіку ви очікуєте і наскільки добре він буде масштабуватися? Для тих, хто робив веб-розробки протягом багатьох років, це можуть бути хворі плями, як я вважаю, у вас є деякі завдання з розвитку, які, на вашу думку, є головним болем, ні?

Програма Flash може, на мою думку, бути веб-додатком. Щось на кшталт AIR може зробити деякі Flash-файли запущеними на робочому столі, і деякі додатки побудовані на цьому, наприклад, Twhirl, тому це не відразу так, щоб вирізати і висушити.

Веб-розробка не обов'язково гірша , вона просто дуже різна.

Однією з речей, що відокремлює веб-розробку від розробки настільних ПК, є безліч кардинально різних технологій, якими ви повинні оволодіти, щоб розробити гідно складний додаток. Я маю на увазі, вам в основному потрібно добре знати:

• HTML
• Javascript
• CSS
• Деякі мови на сервері (Java / PHP / що завгодно ...)
• RDBMS (або якась стійка технологія магазину)
• ... і, можливо, багато інших речей, таких як Flash, Silverlight тощо.

Тоді як, при розробці настільних комп'ютерів, ви зазвичай працюєте з набагато більш монолітним набором технологій. Наприклад, розробка програми Java в основному вимагає, щоб ви знали Java, і це все. (Звичайно, це дещо спрощення, але справа в тому, що веб-розробка піддає вам набагато ширший спектр радикально різних технологій, які потребують спільної роботи для формування функціонуючої програми.)

Ні

Поки ви підбираєте потрібні інструменти, веб-розробка є такою ж чистою і простою, як і розробка робочого столу.

Веб-API (html, CSS, Javascript та DOM) є еквівалентом win32 api. Врешті-решт все зводиться до цього рівня API, але ти божеволієш, якщо програмуєш безпосередньо на ньому, без бібліотеки, щоб абстрагувати безлад, багатослів’я та непослідовність від тебе.

Отже, будьте уважні у виборі рамок. Деякі проблеми спричиняються самостійно шляхом вибору поганих інструментів (наприклад, проблеми із сумісністю браузера).

Можна мати чисту і послідовну платформу веб-розробників, що має єдину мову. Наприклад, якщо ви хочете, щоб це було "весь час Java", ви можете використовувати GWT і писати як код на стороні клієнта, так і код на стороні сервера на Java. Або, якщо ви хочете, щоб це був весь javascript, ви можете вибрати щось на зразок Ext JS для клієнтської та node.js для серверного.

Я чув, що це описується як "... бана мого існування", і я погодився б. Мені пропонували $$$ на годину, щоб зайнятись веб-розробкою HTML, і я відмовився від неї. Це такий біль. Я провів більшість часу в HTML і нещодавно почав працювати з "Flash платформою". Це одна з найскладніших рамок, яку я коли-небудь бачив, і про це ніхто навіть не знає. Коли люди виховують Flash, вони думають про Flash, як 10 років тому. Вирощується ... багато. Я знову люблю писати програмне забезпечення.

У нього все ще є недоліки. Клопи іноді залишаються назавжди, але це стає краще (спасибі Стів Дж.).

BTW Існує великий дефіцит для розробників Flex. До мене звернулося стільки компаній, на які вона хворіє. Якщо ви знаєте свій CS, то витрачайте наступні 6+ місяців на навчання Flex хардкор, тоді зателефонуйте мені. Я передаю всі пропозиції щодо роботи, які мені доведеться відхилити.

Оновлення: Підтримка веб-переглядача є головною больовою точкою. Те, що працює в одному веб-переглядачі, не працюватиме в іншому, або не буде, але не буде в попередній версії.

Процес відбувається приблизно так: - отримати дизайн сайту - спроба відтворити його в одному цільовому браузері (це може бути складно) - показати клієнту - клієнт змінює дизайн - скребте всі роботи з компонуванням, які ви спочатку робили - набудьте його функціональним - клієнт схвалює - змусити його працювати в інших браузерах. Це найскладніша частина. По дорозі є незрозумілі помилки. Потім ви зустрінете функції, які попередні веб-переглядачі не підтримують, наприклад, закруглені кути. Ви спробуєте повторно використовувати код і css, але це швидко стає фрагментарним. Просто це може стати високим обслуговуванням дуже швидко. Додайте в анімацію та старіші дроселі браузера.

Клієнт буде вносити зміни. Ви закінчите витрачати весь свій час, роблячи "які повинні бути прості речі" і ненавиджу своє життя. Ви станете гуру і будете знати речі, які не хочете знати. Я знаю, що це звучить драматично, але я не прикрашаю питань, з якими ви зіткнетесь. Каркаси полегшать. Якщо ви наполегливо працюєте в HTML, тоді підготуйте себе відтворити один із улюблених сайтів у HTML, переконуючись у відповідності дизайну та функціональності у всіх браузерах, які він підтримує. Усуньте проблеми, з якими ви стикаєтесь, перш ніж вирушати на роботу. Такі питання, як найкращі інструменти дизайну, найкращі рамки javascript, найкращі інструменти налагодження, найкращі IDE тощо.