Чому я повинен уникати вбудованого сценарію?

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

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

Гаразд, це питання перетворилося на кілька запитань у письмовій формі. Але в основному, вбудований сценарій - у чому справа?

які реальні проблеми з вбудованим сценарієм? Чи є важливе питання продуктивності чи це здебільшого лише питання хорошого стилю?

Переваги не на основі продуктивності, вони (як зазначив Майкл у своєму коментарі) більше пов'язані з розділенням виду та контролера. Файл HTML / CSS в ідеалі повинен містити лише презентацію, а окремі файли повинні використовуватися для скриптів. Це полегшує вам (та вашим колегам) читання та підтримку візуального та функціонального аспектів.

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

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

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

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

Я не буду захисником диявола, але немає жорсткої залежності між аматорською роботою та вбудованим JavaScript. Давайте подивимось вихідний код кількох найвідоміших веб-сайтів:

• Google,
• Вікіпедія,
• Microsoft,
• Adobe,
• Dell,
• IBM.

Кожна їх домашня сторінка використовує вбудований JavaScript. Чи означає це, що всі ці компанії наймають аматорських людей для створення своїх домашніх сторінок?

Я один з тих розробників, які не можуть ввести код JavaScript всередині HTML. Я ніколи не роблю це у проектах, над якими працюю (за винятком певних дзвінків, як, наприклад, <a href="javascript:...">для проектів, де ненав’язливий JavaScript не був вимогою з самого початку, і я завжди видаляю вбудований JavaScript, коли перетворюю код когось іншого. Але чи варто того докладати зусиль «Не так точно.

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

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

• Що робити, якщо більшість ваших користувачів приходять з порожнім кешем?
• Чи вважаєте ви, що за допомогою файлу extern .js запит буде поданий до цього файлу при кожному запиті сторінки, якщо веб-сайт не налаштований належним чином (і зазвичай це не так),
• Чи дійсно файл .js кешований (з IIS, це може бути не так просто)?

Тому перед тим, як передчасно оптимізувати, збирайте статистичні дані про своїх відвідувачів та оцінюйте показники роботи з вбудованим JavaScript і без нього.

Потім приходить остаточний аргумент: ви змішали JavaScript та HTML у своєму джерелі, тож ви смоктали. Але хто сказав, що ви змішали обидва? Вихідний код, який використовується браузером, не завжди є вихідним кодом, який ви написали. Наприклад, вихідний код може бути стиснутий, зменшеним або кілька CSS або JS файлів можуть бути об'єднані в один файл, але це не означає , що ви дійсно назвали змінні a, b, c... a1і т.д. , або що ви написали величезний CSS-файл без пробілів чи нових рядків. Таким же чином ви можете легко вводити зовнішній вихідний код JavaScript в HTML під час компіляції або пізніше через шаблони.

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

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

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

Як правило, добре намагатися тримати HTML і JS взагалі. HTML - для перегляду, JS - для логіки програми. Але, на мій досвід, надзвичайна розв'язка html та javascript (задля чистоти) не робить її більш рентабельною; насправді це може бути менш рентабельним.

Наприклад, я іноді використовую цей шаблон (запозичений з ASP.net) для налаштування обробників подій:

<input type="button" id="yourId" onclick="clickYourId()" />

або

<input type="button" id="yourId" onclick="clickYourId(this)" />

Немає таємниці, що викликає подію. Причина полягає в тому, що через півроку ви можете оглянути елемент (наприклад, в Chrome) і відразу побачити, що саме запускається подія javascript.

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

<input id="yourId"  />

Як ви можете легко сказати мені, який метод JavaScript викликає? Chrome спростив це, але, можливо, подія пов'язана з ідентифікатором, або, можливо, вона пов'язана з першою дочіркою контейнера. Можливо, подія приєднана до батьківського об'єкта. Хто знає? Успіхів знайти його. :)

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

Отже, коротше, найкраща практика - це розділити HTML та Javascript. Але також зрозумійте, що правила великого пальця іноді є контрпродуктивними, коли переносяться до крайності. Я б заперечував за підхід на середній дорозі. Уникайте великої кількості вбудованих js. Якщо ви використовуєте inline, підпис функції повинен бути дуже простим, як:

1. emptyFunction()
2. doCallWithThis(this)
3. atTheExtremOnlyPassOneNumber(2)

Один мій аргумент, якого я тут відсутній, - це можливість підвищеного захисту від атак міжсайтових сценаріїв .

Можна відключити виконання вбудованого JavaScript у сучасному браузері за допомогою Політики безпеки вмісту . Це зменшило ризик вашого сайту стати жертвою XSS. Це може бути більш переконливим аргументом, який можна зробити вашому менеджменту, щоб інвестувати у видалення вбудованого сценарію.

Ось кілька причин.

1. Вбудований скрипт не можна мінімізувати (перетворюється на скорочену версію за допомогою зменшення символів). Широкосмуговий зв’язок не викликає занепокоєння, але розглянемо мобільний пристрій у зоні низької пропускної здатності, або користувачів, які перебувають у глобальному роумінгу даних - кожен байт може рахуватись.

2. Вбудований скрипт не може кешуватися браузером, якщо сама сторінка не є кешованою (що могло б зробити дуже тугу сторінку). Зовнішні файли Javascript потрібно отримати лише один раз, навіть якщо вміст сторінки змінюється кожного разу. Може серйозно вплинути на продуктивність підключень з низькою пропускною здатністю.

3. Вбудований сценарій важче налагодити, оскільки номер рядка, пов’язаний з будь-якою помилкою, безглуздий.

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

5. Вбудований сценарій не можна перевірити незалежно від його сторінки; зовнішні файли Javascript можна запускати шляхом незалежного тестування, включаючи автоматизовані тести.

6. Вбудований сценарій може призвести до поганого розділення проблем (як це описано в багатьох інших відповідях тут).

Є кілька причин, які виправдовують не включення сценарію в рядок:

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

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

• Якщо ви використовуєте SCM для свого проекту, то, якщо ваші різні компоненти будуть добре розділені, це полегшить відстеження змін та зобов’язання зробити простішим для всіх, хто бере участь.

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

Я не знаю жодних формальних тестів у цій галузі, хоча, швидше за все, хтось їх зробив.

Зрештою, я б сказав, що справа належна більше, ніж будь-що інше, і що переваги з точки зору читабельності та організованості (зокрема, wrt пункт 2) роблять розділення коду на різні файли набагато кращим варіантом.

Відповідь дійсно залежить від того, як використовується вбудований код (за умови JavaScript).

Ми використовували комбінацію вбудованого коду, SSI (на сторону сервера), js-файли та файли css для створення потрібних нам ефектів, а також для зменшення відключення сервера для подій onClick.

Тож хтось зробить бланкетну заяву про те, що використання "прямого коду" є поганим, не розуміючи, як він використовується, може ввести в оману.

Сказавши, що якщо на кожній сторінці однакова копія та вставлений код JavaScript, а не js-файл, я кажу, що це погано.

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

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

Я припускаю тут вбудований JavaScript.

Не бачивши код, важко бути впевненим. Я підозрюю, що він роздумував над якоюсь із двох речей:

1. Ви <script>розсіялися по всій сторінці
2. Все, що ви JS, знаходиться в заголовку сторінки, а не у зовнішніх файлах

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

Щодо другого - це не обов’язково погано. Код певної сторінки повинен бути на цій сторінці. Якщо у вас є дублюючий код між сторінками, вам слід його зовнішньо використовувати <script src>. Потім, коли ви перейдете до створення нової сторінки, ви можете просто включити цей файл, і будь-які виправлені там помилки не потрібно буде переглядати.

Одна з причин НЕ використовувати InLine Javascript (навіть не onclick = "DoThis (this)" на кнопках) - це якщо ви плануєте зробити свою веб-програму додатком Chrome. Тож, якщо ви плануєте перенести веб-додаток у додаток Native Chrome, почніть НЕ включати ВСІЙ вбудований JavaScript. Це пояснюється на початку того, що вам потрібно буде змінити (обов'язково) у своєму веб-додатку, якщо ви маєте намір "Chrome-etize" це.

Які реальні проблеми з вбудованим сценарієм?

Вбудований сценарій поганий і його слід уникати, оскільки він ускладнює читання коду.

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

Складність зазвичай виникає з вкладених кодувань. У наступному рядку коду є проблема, чи можете ви її помітити?

<a onclick='alert("What\'s going wrong here?")'>Alert!</a>

В ідеалі код написаний таким чином, що це легко помітити, коли є помилка. Жоель Спольський написав чудову статтю, яка підкреслює цей момент ще в 2005 році . Приклади коду можуть скористатися значним поліпшенням, оскільки вони показують, що їх вік становить 9 років, але основна концепція все ще сильна: пишіть код таким чином, щоб полегшити вибір помилок.

Чи є важливе питання продуктивності чи це здебільшого лише питання хорошого стилю?

Вбудований сценарій призводить до повторення. Замість того, щоб змінювати один рядок коду, щоб він впливав на 100 сторінок, вам, ймовірно, потрібно буде змінити 100 сторінок окремо. Це поряд із поганою читабельністю серйозно впливає на продуктивність роботи обслуговуючого персоналу . Час програмування має реальну вартість, яка впливає на нижній рядок бізнесу швидше, ніж на кілька мілісекунд від більшості оптимізацій коду. Безумовно, оптимізація вузьких місць є важливою, але різниця в продуктивності коду в цьому випадку незначна.

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

Ні. Якщо це дурно і це працює, це не дурно.

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

Які чинники змусять вас сказати "хм, тут професійна робота", і що змусить вас відмовитися від явно любительської роботи?

Я, як правило, вважаю за краще «професіонала» визначати лише як того, кого платять за виконання завдання, а не припускають, що вони мають якісь значні здібності у тому, що їм платять. Багато професіоналів, безумовно, здатні виконувати хорошу роботу, але частіше за все мені здається, що я переживаю жах у жахливій роботі, яку зробили інші професіонали, а не те, що придумав любитель. Значна частина моєї роботи на сьогодні стосується рятувальних проектів, пов'язаних із аварією поїздів, які були започатковані початковими розробниками, тому ваш пробіг може відрізнятися.

З урахуванням сказаного, вибрати програмне забезпечення якості підприємства легко