Конвертер HTML/CSS/JS кода в массивы байт

В процессе работы по запуску web-сервера на STM32 понадобилась программа, конвертирующая исходные тексты страниц (HTML/CSS и др.) в массивы данных, для последующей загрузки в исходники микроконтроллера.
После непродолжительных поисков было решено написать свою, за одно вспомнить C#.

Программа для конвертации текста в HEX

Интерфейс достаточно интуитивен, но небольшие комментарии по работе:
Три блока текста:
  1. Input — сюда вставляем свой текст;
  2. Formatted — текст, после форматирования с заданными настройками. Этот текст будет преобразован в шестнадцатеричную систему;
  3. Hex — выходные данные, готовые для загрузки в MCU.


Пример преобразования HTML -> HEX:
Converter HTML to HEX

Добавлено форматирование в виде массива: данные обрамляются в массив, после данных добавляется размер
converter html, css, javascript to hex

Настройки форматирования исходного текста позволяют сэкономить драгоценные байты в памяти микроконтроллера:
  1. Удаление всех дублирующихся пробелов и символов переноса строки;
  2. Замена символа табуляции на пробел;
  3. Замена следующих друг за другом символа переноса строки и пробела (образуются после замены табуляции на пробел);
  4. Замена символов переноса строки на пробелы — преобразование в одну строку (Внимание! если в коде используются однострочные комментарии (// comment), то код теряет работоспособность);
  5. Удаление всех пробелов (Внимание! применимо к очень специфическим исходным текстам);


Настройки форматирования и экономия размера массива на примере файла JavaScript-кода.
Без форматирования — 3782 байта:
Преобразование исходного текста в шестнадцатеричную систему

Очистка дублирующихся пробелов и переноса строки — 3720 байт:
Конвертер текст в массив байт

Удаление табуляции и пробелов (оставшихся после замены табуляции) — 3483 байта. Выделен комментарий, который далее сделает код нерабочим:
Convert HTML, CSS, JavaScript to Hex Array for MCU

Исходный текст в одну строку — 3351 байт. После удаления комментариев будет станет ещё меньше.
Text to byte array Converter

Надеюсь программа будет полезной при разработке программ на МК и для других разработчиков.
Приложение требует установленного .NET Framework 3.5
  • +3
  • 02 апреля 2015, 14:39
  • JonBAL
  • 1
Файлы в топике: Text_To_Hex Converter.zip

Комментарии (54)

RSS свернуть / развернуть
Для большей эффективности джваскрипт можно предварительно прогнать через гугловый компилятор (он умеет делать более продвинутые оптимизации, типа замены имен локальных переменных и т. д.)
+3
А еще можно ен использовать богомерзский jQuery. SPL им не нравится, а jQuery, значит, заябись технология.
А еще автор не слышал ни про minify, ни про uglify, ни про grunt, например. Целый склад готовых велосипедов для минимизации веб кода. Настоятельно советую присмотреться
+3
Даже обработки комментариев нормальной не умеет (5 строчек кода на Си!). Зато подавай фреймворк 3.5. Как это типично.
+1
Зато подавай фреймворк 3.5.
.NET 3.5 — это олдскул (суровый 5-курсник), щас уже надо юзать 4.5
-1
Даже обработки комментариев нормальной не умеет (5 строчек кода на Си!).

На самом деле почти всю функциональность по обработке JS как у автора (с корректным удалением однострочных комментариев) на С# можно реализовать вообще одной строкой (одним выражением).
Что-то типа
string input = "buz();    //comment\n   \t  foo();\n      \t  bar();";
string result = input.Split('\n').Select(s => s.Split(new string[] { "//" }, StringSplitOptions.None).First().Trim()).Where(s => s.Length > 0).Aggregate((a, s) => a + " " + s);
Console.WriteLine("Result: " + result);

Result: buz(); foo(); bar();


(на самом деле так делать не нужно, длинные LINQ тяжело читать плюс лучше использовать StringBuild)
Просто автор, видимо, не захотел заморачиваться с обработкой комментариев

Зато подавай фреймворк 3.5

А чем вас версия фреймворка не устраивает (тяжело сейчас найти машину с виндой без установленного 3.5) Нет, ну можно, ради спортивного интереса, переписать код под 1.0, можно даже написать аналогичной код на чистом ASM. Но зачем?
+1
Маленькое дело — лучше большого безделья, но все уже придумано до нас.
Весь код JS склеивается без пробелов и cr/lf через ";" легко, да и html с css тоже в множестве онлайн сервисов.

Я бы посоветовал с регулярными выражениями подружиться, тогда удаление комментария до конца строки займет 1 команду, да и многострочник — тоже. regex — это такая же базовая вещь, как 29 операторов си. Чтобы не грызть гранит, в интернете есть интерактивный туториал, очень сильно помогает в освоении.

Еще лучще, писать такое под веб, хоть на том же php, у Вас же не high load планируется. Тогда обеспечена независимость от платформы, и где бы не застало вдохновение можно ужать код.
+1
Я бы посоветовал с регулярными выражениями подружиться, тогда удаление комментария до конца строки займет 1 команду

У вас есть проблема. Вы решили использовать регулярные выражения чтобы её решить. Теперь у вас две проблемы :)

Регулярные выражения не читабельны. Это отличный пример write only кода. Вот вы можете понять/декодировать/найти ошибку/отладить следующую регулярку?:

^(((0[1-9]|[12]\d|3[01])\.(0[13578]|1[02])\.((19|[2-9]\d)\d{2}))|((0[1-9]|[12]\d|30)\.(0[13456789]|1[012])\.((19|[2-9]\d)\d{2}))|((0[1-9]|1\d|2[0-8])\.02\.((19|[2-9]\d)\d{2}))|(29\.02\.((1[6-9]|[2-9]\d)(0[48]|[2468][048]|[13579][26])|((16|[2468][048]|[3579][26])00))))$
0
да ну, не сложнее, чем регистры МК на си напрямую долбить, без библиотек. Тем более, убрать все что после двух слэшей выражение будет как у вас от каретки до точки.
просто нужен навык.
-1
да ну, не сложнее, чем регистры МК на си напрямую долбить, без библиотек.

Сложнее. Любой современный ЯП позволит вам декомпозировать задачи, позволит вам писать читабельный и самодокументируемый код, отлаживать его по частям, писать ютнит-тесты. Код LINQ запроса можно разбить на части, отлаживать по отдельности, пройтись по нему в пошаговом режиме отладки. А регэкспыы – чистая магия (нет средств для декларирования своих целей в рамках синтаксиса, нет средств нормальной отладки)
0
Ну он и предлагает прямо с регистрами работать. Еще и на асме, поди. Но асм лучше, в нем хотя бы комментарии есть.
0
Да, как по мне, ASM по сравнению с регулярками – вообще милое дело. И комментарии, и код достаточно просто (на уровне синтаксиса) разделить на отдельные операции, которые выполняются последовательно…
0
А регэкспыы – чистая магия (нет средств для декларирования своих целей в рамках синтаксиса, нет средств нормальной отладки)

А кто их использует — говнокодеры и лохи. Нормальный программист не будет себя утруждать их изучением и напишет свой велосипед.
+2
А кто их использует — говнокодеры и лохи. Нормальный программист не будет себя утруждать их изучением и напишет свой велосипед.

Нет, вы неправильно сделали вывод из моих слов. Я сам их иногда использую, но стараюсь этого избегать.

Я просто говорю, что их синтаксис не читаем, отлаживать их тяжело. Или Вы с этим не согласны?

Если простую регулярку еще можно понять достаточно быстро, то с такой как я привел выше – без 100 грамм не разобраться (и, боюсь, 100 грамм будет мало). Иногда проще написать свою регулярку с нуля, чем пытаться найти ошибку в существующей (что и есть write only)
0
Иногда проще написать свою регулярку с нуля, чем пытаться найти ошибку в существующей (что и есть write only)

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

Повторюсь, Вы согласны с тем, что синтаксис регулярок начитаем?

И дело не в изучении. Изучить синтаксис не проблема, по отдельности он достаточно прост, но как только появляются сложные регулярки – начинаются проблемы. Иногда требуется куча времени, чтобы разобрать регулярку, которую ты же писал год назад…
0
все можно при желании сделать нечитабельным, а некоторые вещи не обязаны быть читабельными. выводы: писать читабельные выражения, если это не одноразовое приложение. в случае длинных выражений стараться разбивать их на части, а части подробно комментировать.
0
Вы согласны с тем, что синтаксис регулярок начитаем?

Нет, мы не согласны.

Иногда требуется куча времени, чтобы разобрать регулярку, которую ты же писал год назад…

Писать надо нормально и комментировать.
0
Нет, мы не согласны. Писать надо нормально и комментировать.

:) Ну ОК, только как «писать нормально» в рамках синтаксиса регексп и как комментировать?

Возьмем практический пример. В выражении

^(((0[1-9]|[12]\d|3[01])\.(0[13578]|1[02])\.((19|[2-9]\d)\d{2}))|((0[1-9]|[12]\d|30)\.(0[13456789]|1[012])\.((19|[2-9]\d)\d{2}))|((0[1-9]|1\d|2[0-8])\.02\.((19|[2-9]\d)\d{2}))|(29\.02\.((1[6-9]|[2-9]\d)(0[48]|[2468][048]|[13579][26])|((16|[2468][048]|[3579][26])00))))$

(а это просто проверка даты с учетом высотных годов) есть 2 ошибки (одна из них критическая, вторую можно игнорировать). Если Вы настолько легко читаете регексп выражения – для вас не составит труда выявить эти ошибки. Если вы их выявите – я признаю, что я быдлокодер и так и не научился читать регекпы :)
0
Тема времени — это сложная тема. Как в бытовом, так и в философском плане. Так что вы выбрали непростой пример. :-)
Григорианский календарь был впервые введён в октябре 1582 г. До этой даты февраль имел 28 дней согласно юлианскому календарю (с 1 января 45 года до н. э.). Не все европейские страны одновременно перешли на григорианский календарь. В Европе последней перешла Греция в 1923 г. Но можно условиться считать началом 1582 год, а первым високосным будет 1584 г.

Что мы видим в регекспе?
Длинные месяцы, короткие месяцы и короткие феврали матчатся по выражению года
((19|[2-9]\d)\d{2})
То есть матчатся годы 19## и с 2### по 9###.
1) Ранее 1900 года не пройдут никакие даты кроме 29 февраля, которое матчится по другому регекспу года
(1[6-9]|[2-9]\d)
То есть матчатся годы c 16## по 19## и с 2### по 9###.
2) 1584 год не матчится.
+2
я быдлокодер и так и не научился читать регекпы :)
0
Не, ну расковырять-то его можно, интересно только сколько времени на это уходит… Я забыл на часы глянуть, мне показалось, что минут 10 разбирал в редакторе с подсветкой скобок.
+1
Я ковырял минут 15. При этом я нашел «ошибку», которой там на самом деле нет. После комментария EW1UA пересмотрел снова, и понял, что был неправ. Вот по этому я и не люблю регэкспы :)
+1
А я не говорил, что это просто. Как раз таки я согласен, что длинный регэксп проще написать, чем прочитать.
Если бы это было выражение для языка программирования, я бы разбил его на пять подвыраженй в if-else. Ну а если для egrep, то ничего не поделаешь.
+3
А я не говорил, что это просто. Как раз таки я согласен, что длинный регэксп проще написать, чем прочитать.

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

ИМХО – у регулярок есть 2 плюса:
— их синтаксис стандартизирован, они поддерживаются практически везде (иногда на уровне самого ЯП)
— они позволяют заменить «десятки строк» простого и примитивного кода на ЯП на одну строку с нечитаемой регуляркой (здесь каждый решает для себя, когда нужно отказаться от «обычного» кода и прибегнуть к регуляркам).

Но для меня странно, что люди не согласны с тем, что синтаксис не читаем, нет нормальных механизмов отладки и т. д. Так можно и Brainfack выставить в лучшем свете, главное «писать надо нормально и комментировать»
0
Сложное — упростить!
Если задачка сложная в целом, то её нужно пытаться разбить на более простые части. Это правило применимо и для регулярных выражений тоже.

Если средства языка (Perl?, PHP?) позволяют, то данное выражение можно разбить на пять частей и прокомментировать каждую:
1. длинные месяцы;
2. короткие месяцы;
3. 1-е — 28-е февраля;
4. 29-е февраля для четвёртых годов;
5. 29-е февраля для четырёхсотых годов.
Для пунктов 1-3 подвыражение года будет одинаковым, поэтому его следовало бы вынести в отдельную константу-строку. Для пунктов 4 и 5 подвыражение число+месяц будет общим, его тоже можно вынести в константу. Вот, что в моём понимании «писать нормально и комментировать».

Даже на мой взгляд, каждая из пяти ветвей будет содержать достаточно простое для понимания выражение. Чтобы их усложнить :-), я бы предложил добавить обработку трёх разделителей (.-/) и поддержку одно-, двух- и трёхзначных годов.
+1
:) Ну ОК, только как «писать нормально» в рамках синтаксиса регексп и как комментировать?

Разбить на части и написать, что эта куча букв делает, какой формат данных принимает и какие исключения обрабатывает.

Если Вы настолько легко читаете регексп выражения – для вас не составит труда выявить эти ошибки.

Автор не удосужился добавить комментарии, с чего бы мне разбирать его говнокод?
0
Писать надо нормально и комментировать.
Пример приведи. Именно для регулярок. Ну, например, перепиши читабельно регулярку от e_mc2.
+1
Тем временем мне рассказали, что у регулярок есть и более вменяемый синтаксис:
Хорошая регулярка выглядела бы примерно так:
^(
   (
      (?<group1> 0[1-9]|[12]\d|3[01])\.   # Находим первую группу цифр
      (?<group2> 0[13578]|1[02])\.         # Вторая группа цифр
      ...
    )
)
Ну и т.д.
В Perl RegExp уже сто лет как есть расширенный синтаксис с комментариями и переносами строк
Плюс никто не запрещает составлять регулярку по частям, опять же
Типа
var group1Regex = "(?<group1> 0[1-9]|[12]\d|3[01])";

var compositeRegex = "(
  ${group1Regex}   # Находим первую группу
  ... и так далее
)";
0
Для начала пусть автор напишет комментарии о том, что этот регэксп делает, какой формат данных принимает и какие исключительные ситуации обрабатывает. Потом можно разбить эту кучу букв на части для лучшей читаемости и отладки.
0
Я: Синтаксис регулярок не читаем …
Вы: Не согласен…
Я: ну так прочитайте…
Вы: Для начала пусть автор напишет комментарии о том, что этот регэксп делает …

Дык о чем мы тогда спорим? В том и проблема, что без комментариев от автора, имея только сам регексп тяжело разобраться. Именно поэтому я и говорю, что синтаксис нечитаем.

Если автор напишет комментарии, в которых все распишет, а еще лучше выступит с докладом «как прочитать мою регулярку» — то да, все понятно. Только к читабельности самого регекспа это не имеет отношения. Если исходный код на Brainfack снабдить множеством комментариев – то в программе вполне можно разобраться. Но это не делает Brainfack читабельным ЯП.
+1
Именно поэтому я и говорю, что синтаксис нечитаем

int m = 754974721, N, t[1 << 22], a, *p, i, e = 1 << 22, j, s, b, c, U;
f (d)
{
  for (s = 1 << 23; s; s /= 2, d = d * 1LL * d % m)
    if (s < N)
      for (p = t; p < t + N; p += s)
	for (i = s, c = 1; i; i--)
	  b = *p + p[s], p[s] = (m + *p - p[s]) *
	    1LL * c % m, *p++ = b % m, c = c * 1LL * d % m;
  for (j = 0; i < N - 1;)
    {
      for (s = N / 2; !((j ^= s) & s); s /= 2);
      if (++i < j)
	a = t[i], t[i] = t[j], t[j] = a;
    }
}

main ()
{
  *t = 2;
  U = N = 1;
  while (e /= 2)
    {
      N *= 2;
      U = U * 1LL * (m + 1) / 2 % m;
      f (362);
      for (p = t; p < t + N;)
	*p++ = (*p * 1LL ** p % m) * U % m;
      f (415027540);
      for (a = 0, p = t; p < t + N;)
	a += (6972593 & e ? 2 : 1) ** p, *p++ = a % 10, a /= 10;
    }
  while (!*--p);
  t[0]--;
  while (p >= t)
    printf ("%d", *p--);
}


Насколько «нечитаемый синтаксис» у этого ЯП?
0
Насколько «нечитаемый синтаксис» у этого ЯП?

Этот код еще относительно понять можно. Вы могли бы привести и более вырожденный случай, типа
main(int riguing,char**acters){puts(1[acters-~!(*(int*)1[acters]%4796%275%riguing)]);}

(взято из этого конкурса).

Что Вы хотите доказать вашим примером?

Язык С дает вам возможность в рамках синтаксиса делать код читаемым (осмысленное название функций, переменных, логичная декомпозиция кода и т. д.). И большинство программистов этой возможностью пользуются :) А вот синтаксис регекспа такими свойствами не обладает (ну или практически не обладает).
+1
А вот синтаксис регекспа такими свойствами не обладает

Знатока сразу видно. Например в перле регэкспы можно, как минимум, переносить по строкам, не говоря уже о том, что вместо одного большого можно использовать несколько мелких для лучшей наглядности и удобства отладки.
0
Знатока сразу видно.

:) Это называется «переубедить Вас у меня не получится, поэтому давайте сразу перейдем к оскорблениям…»

Например в перле регэкспы можно,

Коллега Vga несколькими комментариями выше показывал эти возможности в перле. Но, это не решает всех проблем синтаксиса, да и использование регеспов перлом не ограничивается.
+2
Это называется «переубедить Вас у меня не получится, поэтому давайте сразу перейдем к оскорблениям…»

«И не будем обращать внимания на очевидное опровержение крайне категоричного заявления в цитате».
0
очевидное опровержение
Это какое? То, что «а в перле можно …» или то, что на С тоже можно писать нечитаемый код?
0
«Мимо кучки спорящих граждан интеллигентской наружности проходил мужчина с неприятным лицом, он был в мятом плаще и в забрызганных грязью кроссовках Adidas за 9 тыр(это, если считать по старому курсу). Такое его одеяние было весьма странным, т.к. кое-где еще лежал грязный снег. Вытащив из кармана кусок батона, он откусил его и жуя вплотную придвинулся к спорящим, внимательно вслушиваясь в разгоравшийся спор.»

Я считаю, что уважаемый коллега e_mc2 прав насчет применения регулярных выражений в алгоритмических языках. Когда мы видим конструкции ветвления, циклов, присваивания значений переменным и даже конструкции с указателями — мы в целом понимаем, что там происходит на уровне процессора и асм, чего не скажешь про рег.выражения. Интересно, что некоторые продвинутые библиотеки для быстрого парсинга не используют regexp, а событийно-программируются пользователем на нахождение нужного в потоке входных данных через набор колбэков.
+1
То, что «а в перле можно …»

MySQL:

SELECT 'sometext' 
REGEXP CONCAT('^(so',   /* comment */
              'me)*',   /* comment */
              'text$'); /* comment */


что на С тоже можно писать нечитаемый код

Так у него всё-таки «нечитаемый синтаксис»?
0
MySQL

Сдаюсь, коллега. У меня просто не осталось контраргументов. Признаю, синтаксис рекулярок прост и легко читается. Теперь, когда я буду разбирать очередную длинную регулярку – мне будет намного легче.
+1
а для конвертирования под линуксом есть замечательная комапда xxd которая может любой поток данных превратить в массив байт
0
отстой. консольные утилиты с ключами командной строки гораздо юзабельнее в таких случаях. можно автоматизировать. а тут — сиди, дрочи кнопку. Шиндовс-вей.
0
Я когда заливаю сайт в еепромку делал следующим образом:
1. прогонял через гугл java компилер и ajaxmin
2. Склеивал самописной программкой всё это дело в один хекс файл, и генерил отдельный .h файл с табличкой адресов-смещений начала каждого файла.
3. (опционально): По мере склеивания файлов можно парсить все инклюды и заменять имена файлов на цифры типа («index.css»->«1») итд. Затем составлять табличку адресов, соответственно при запросе клиента на файлы, будут приходить цифры которые можно делать atoi и смотреть адрес в массиве addr = arr[atoi(url));

Всё делалось с командной строки, автоматически перед каждой компиляцией.

PS: Использовать богомерзкий jQuery в контроллере… даже комментировать не буду.
+1
Использовать богомерзкий jQuery в контроллере… даже комментировать не буду.

Конечно нечего тут комментировать, JS ведь контроллером обрабатывается, а не файлом отдаётся.
0
Для примера: у меня весь сайт занимает меньше или как минимум столько же сколько самая ужатая версия jQuery. И если вам не жалко памяти, окей, давайте тогда ставить гигагерцовые процы или сразу mini-pc типа raspberry какой-нибудь, к чему тогда речь о контроллерах вообще? Это показывает невежество автора и неспособность написать ничего вразумительного на чистом JS. Но ваше дело конечно же.
0
Для примера: у меня весь сайт занимает меньше или как минимум столько же сколько самая ужатая версия jQuery.

Писькомерка агонь.

Это показывает невежество автора и неспособность написать ничего вразумительного на чистом JS.

Например c аяксовыми событиями и отловом ошибок. Для этого обязательно надо писать свой велосипед, чтобы надрачивать потом на объём говнокода.
0
Например c аяксовыми событиями и отловом ошибок. Для этого обязательно надо писать свой велосипед, чтобы надрачивать потом на объём говнокода.
2 строчки с XHTMLRequest, или jQuery давно мозги высосал?
Писькомерка агонь.
Это про то, если сайт весит 10кб, то это не уважению к юзеру заставлять его ещё выкачивать 30кб, или же верх идиотизма.
0
30кб уже не размер даже для мобильного интернета. Для многих МК это уже существеннее, но можно хранить сжатый (если хранить в gzip, то можно так сжатый и отдавать). Если предполагается, что обращающийся к МК клиент всегда имеет доступ и в интернет — можно подгружать jQuery с CDN, тогда он вообще скорее всего возьмется из кэша браузера (т.к. оттуда его многие сайты грузят).
+2
Вообще, подгружать зависимости с CDN это дурной тон в мире веб-разработки. Вариаций разных библиотек великое множество, одного jQuery можно найти более 50 штук в разных вариантах, и вероятность того что определенный вариант находится у тебя в кэше — очень мала. Ну и обычно железяки с МК работают в локальной сети, да и ситуации когда удалённый ресурс недоступен также бывают(и не редко).

Что говорить о jQuery, это личное дело каждого, и я своими выссказываниями могу спровоцировать холивар. Но имхо: он не даёт НИЧЕГО в функционале кроме удобства кроме записи. Любая его функция реализуется максимум в несколько строчек. И в мире ограниченных ресурсов (эмбеда) он уж точно излишен, особенно если идёт речь о нескольких страничек а не о CMS системах.
+1
И в мире ограниченных ресурсов (эмбеда) он уж точно излишен, особенно если идёт речь о нескольких страничек а не о CMS системах.
Вообще, в отрыве от задачи на эту тему рассуждать смысла нет. С одной стороны, веб-интерфенйс роутера — тоже эмбед, и там 30кб jQuery — несущественная малочь (одно лишь лого производителя картинкой весит больше). С другой — релюшка с веб-мордой на ATTINY2313 определенно jQuery не потянет, да и скорее всего не нуждается в нем.
Если ресурсы позволяют разместить jQuery и он облегчает разработку — почему бы и не применить? Все равно незадействованные ресурсы выбрасываются впустую.
+1
Вообще, подгружать зависимости с CDN это дурной тон в мире веб-разработки.
Не подгружать ресурсы с CDN вот это действительно дурной тон.
0
Почитайте тематический статьи об исследованиях на эту тему. Факт в том, что на практике они не ускоряют загрузку страниц а лишь создают неудобства пользователю. И если в случае обычных веб-страниц, это практически не заметно (хотя бывает иногда), то что касается веб-страниц железяк, нужно очень и очень хорошо подумать прежде чем пихать туда ресурсы с CDN.
+1
Почитайте тематический статьи об исследованиях на эту тему. Факт в том, что на практике они не ускоряют загрузку страниц а лишь создают неудобства пользователю.
Факт в том, что вы явно оперируете неполной информацией. И да, рекомендовать мне почитать тематические статьи на эту тему почти тоже самое, что рекомендовать Ди почитать школьный учебник по физике.
-1
Поддерживаю Vga .

В отрыве от задачи на эту тему рассуждать смысла нет.

И нельзя все сводить к одному правилу (использование jQuery, загрузка из CDN). Роутер с WEB интерфейсом не должен тянуть ресурсы из CDN. Аналогично, есть сугубо Intranet приложения, которые тоже не должны быть зависимы от внешних ресурсов (например, из соображения самодостаточности и безопасности).

С другой стороны есть свои плюсы в использовании jQuery и ее погрузке из CDN.
0
2 строчки с XHTMLRequest, или jQuery давно мозги высосал?

Нет, без переносов-то и одна строчка будет. Только вот объём кода несколько больше.

Это про то, если сайт весит 10кб, то это не уважению к юзеру заставлять его ещё выкачивать 30кб, или же верх идиотизма.

С нормальным веб-интерфейсом картинки весят в разы больше.
+1
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.