Bootstrap. Това е една от най-често срещаните и добре познати библиотеки с кодове в мрежата - което, разбира се, я прави една от най-противоречивите. За хората, които обичат Bootstrap, това им дава способността много бързо да изграждат своя продукт; за тези, които са от другата страна на оградата, това води до подути уебсайтове, които изглеждат еднакво.

бутстрап

Подобно на много неща, които са силно обсъждани, има някои компромиси, които мисля, че и двете страни могат да изостанат.

Забележка: тази статия предполага, че сте запознати със SASS.

По-внимателен поглед към Bootstrap

Използвам Bootstrap 4 от известно време. Въпреки че все още е в алфа, намерих добър успех в използването и тестването му - затова ще се съсредоточа върху най-новата версия за това (въпреки че същите неща все още важат за Bootstrap 3).

Ако разгледаме изходния код на Github, ще видим познатата папка dist, която съдържа компилирани CSS и JavaScript файлове - но ако разгледаме малко по-дълбоко папките scss и js, изглеждат някои по-малки парчета код.

В нашата папка scss нека надникнем в bootstrap.scss. Това, което виждаме, е товар от внос, който привлича тези по-малки парчета scss. Друг бележка в scss файл е файл _variables.scss.

По подразбиране SASS и!

Разглеждайки файла _variables.scss, забелязваме, че винаги, когато дадена променлива е декларирана, тя е последвана от флаг по подразбиране! Нека да разгледаме как работи този флаг.

Нека разгледаме следния код - и това може да е начинът, по който Bootstrap най-често се използва.

Недостатъкът да правим нещата по този начин е, че нашата продукция ще бъде два пъти по-голяма, отколкото трябва:

Ами ако трябва да предефинираме какво е $ link-color преди компилирането на кода ни? За щастие, за това е флагът по подразбиране!.

Нека разгледаме първия ред в примера по-горе:

Това, което казва този ред, е: задайте този цвят на $ link-color освен ако вече не е дефиниран.

Така че, ако използваме техника за определяне на променлива преди нашия файл Bootstrap, ние всъщност можем да модифицираме кода, който Bootstrap извежда сам.

Да се ​​върнем към нашия пример.

Това ще изведе:

И така, виждаме няколко предимства в декларирането на променливи, преди да включим нашите Bossstrap scss файлове в нашия процес на изграждане:

  1. Пишем по-малко код. Вместо да заменим кода, ние просто заместваме променливите.
  2. Извеждаме по-малко код - винаги чудесно за изпълнение.

Използваме само това, от което се нуждаем

Другото предимство на използването на scss файловете на Bootstrap е, че можем да бъдем малко по-подробни с кода, който включваме в нашия проект. Да не се използват сигнали и модали? Не включвайте тези парчета. Нека да разгледаме моя файл app.scss (основният ми scss файл, който просто импортира други частични scss файлове):

В горната част на файла е моят файл с персонализирани променливи, който заменя всички използвани променливи на Bootstrap (цветове, размери на шрифта и т.н.). Веднага след това са конкретните Bootstrap файлове, които включвам.

Моята стратегия за отслабване на нещата - започнете с необходимите основни компоненти и някои основни файлове (нормализиране, рестартиране и въвеждане) - и като започна да добавям съдържание, добавям свързани файлове (таблици, бутони).

Мога да използвам същите техники с JavaScript файловете на Bootstrap. Процесът на компилация, който използвам, се възползва от webpack, което прави включването на части от JavaScript невероятно лесно.

Всъщност обаче не използвам всякакви на JavaScript функционалността на Bootstrap. Не че нещо от това е лошо - на този етап от моя сайт няма нужда от него.

Резултати

Така че, макар да има малко работа зад това - всъщност е съвсем минимално и си заслужава усилията.

Въведете Bootstrap Me Savings
CSS 23,1 КБ 5.5KB 76%
JS 13.7KB 7.2KB 47%

Ако искате да видите малко повече за това, което правя, изходният код на този сайт е достъпен на Github.

Обобщение

Обичам Bootstrap. Позволява ми да създавам сайтове по-бързо, отколкото да пиша на ръка всичките си CSS. Може ли моят CSS да бъде по-лек, ако го направих? Може би. Но докато не работя на сайт, където всеки байт спестявания помага, съм доволен от резултатите, които получавам, използвайки някои от описаните тук техники.

Балансирането на ефективността спрямо това колко време отделяте за изпълнение е различно за всеки проект. Бих се радвал да мога да получавам сайтове толкова бързо, колкото биха могли да бъдат за всеки проект, по който работя - но реалността е, че отнема време; и не всички клиенти имат това време (т.е. бюджет) за работа.

Така че, правете каквото можете с това, което имате. Ако вече работите по проект с процес на изграждане, предприемането на няколко стъпки, за да намалите някои от библиотеките, с които работите, може да доведе до няколко лесни печалби.

Като този? Имате въпроси?
Обърнете се чрез Twitter на @adamwillsdev