Bất cứ khi nào mình đề cập đến việc tôi không sử dụng các preprocessors CSS, mình có xu hướng có ngạc nghiên từ những người không thể tưởng tượng được việc viết CSS mà không có Sass. Và vì thế mình phải bảo vệ sự chọn lựa của tôi và giải nghĩa tại sao, hết lần này đến lần khác. Một số người sẽ hiểu, hầu hết sẽ không. Hoặc họ không muốn. Nhưng đây là một nỗ lực để giải thích lý do của mình.
Quay lại khi các preprocessors CSS đầu tiên được đưa vào thời trang, mình đã thử sử dụng chúng. Và sau đó vài năm một lần, do áp lực bên ngoài và dai dẳng, tôi đã có diện mạo mới và cho họ cơ hội mới. Nhưng đối với mình, họ luôn cảm thấy như các giải pháp cần xử lý vấn đề. Đó là, mình không thật sự tìm ra được "vấn đề" với CSS mà các nhà tiền xử lý dự định giải quyết các vấn đề. Quy mô của trang web tôi đang xây dựng không trọng điểm, có thể là website nhỏ chỉ với một vài trang tĩnh hoặc mạng nội bộ công ty khổng lồ. mình chỉ ngắn gọn là không bao giờ cảm thấy sự cần thiết cho mixins, làm tổ hoặc mở rộng.
Một list các lý do sau đó:
mình không cảm thấy các tiền giải quyết CSS "vấn đề" có ý định giải quyết là đủ nghiêm trọng để đảm bảo chi phí, tức là với tôi giải pháp tồi tệ hơn vấn đề.
mình muốn kiểm soát tuyệt đối CSS của mình, có nghĩa rằng tôi muốn làm việc với nó, và tham khảo chính xác những gì sẽ được gửi đến trình duyệt (tuyệt vời, trước khi nó được minified và gzipped, tất nhiên). Nếu điều đó cho thấy nhìn thấy cùng một khai báo lặp đi lặp lại trong một số quy tắc, hoặc phải đọc tiền tố nhà cung cấp trông như thế nào, vì vậy hãy là nó. Đối với tôi, WET CSS dễ hiểu hơn và có thể bảo trì hơn so với hộp giả CSS màu đen DRY.
mình không muốn tìm hiểu và lệ thuộc vào một cú pháp không chuẩn để đóng gói CSS của mình, làm cho nó cần phải biên dịch trước khi các trình duyệt có thể hiểu được nó. mình cũng không muốn đồng nghiệp của tôi phải làm như vậy.
Tôi muốn CSS nguồn của tôi có thể triển khai mọi lúc, mặc dù ở dạng chưa được rút gọn, không được ghép nối. Nếu quá trình xây dựng của mình không thành công, vì bất kỳ lý do gì (như một mô-đun npm chưa được xuất bản), mình có thể open beta CSS nguồn như một giải pháp khẩn cấp. Hiệu suất có thể có thể mất một hit, nhưng một website hơi chậm hơn có khả năng tuyệt vời hơn so với một website bị hỏng hoặc không có CSS cho đến khi quá trình xây dựng có thể được cố định.
mình không muốn phải chờ đợi để biên dịch trước khi nhìn thấy kết quả của những đổi thay CSS của tôi. Thời gian xử lý có thể là bất cứ điều gì từ không đáng kể đến bực bội, rõ ràng, nhưng nếu mất nhiều thời gian hơn để tôi chuyển từ trình chỉnh sửa mã sang browser của mình và load lại trang (≈1s) thì quá chậm.
Tôi hoàn toàn nhận thức được rằng nhiều người sử dụng các bộ tiền xử lý CSS sẽ không đồng ý với hầu hết hoặc tất cả những điều trên. Tôi đã biết rằng vì thế không cần phải nói với tôi :-).
Xem thêm:Học lập trình
Tuy nhiên, mình không sử dụng Sass hoặc các bộ tiền xử lý CSS khác như cssnext không có nghĩa là tôi không sử dụng các bộ giải quyết CSS. Sự khác biệt, như mình thấy, là liệu CSS của bạn có yêu cầu biên dịch hay không trước khi các browser có thể hiểu nó, điều mà mình thực sự muốn tránh.
Tôi sử dụng PostCSS (với các plugin của bên thứ ba và những cái tôi đã tự viết) và CSScomb làm người trợ giúp cho những thứ như:
- Sắp xếp các khai báo và sửa các vấn đề về kiểu code hóa với CSScomb
- Tự động chèn tiền tố của nhà cung cấp vào bất cứ nơi nào họ cần (hoặc xóa chúng ở bất cứ đâu)
- Chèn dự phòng cho thuộc tính tùy chỉnh
- Iinting CSS
Tôi thiết lập cả CSScomb và PostCSS để làm việc trên CSS nguồn của tôi, có nghĩa rằng tôi luôn thấy kết quả. Không có hộp đen. tôi có thể save tệp của tôi và tải lại ngay lập tức mà không cần phải chờ biên dịch (vì các thay đổi chủ yếu là tiền tố của nhà cung cấp và tiền tố / chỉ có thể được chèn một lần). Nhưng các tool giúp mình tiết kiệm được một số phương pháp gõ và sửa chữa hầu hết các mâu thuẫn kiểu mã hóa đối với tôi. Đó là loại giải quyết CSS của tôi.
Không có nhận xét nào:
Đăng nhận xét