Bất cứ khi nào tôi đề cập đến việc mình không sử dụng các bộ tiền xử lý CSS, tôi 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ì vậy mình phải bảo vệ sự lựa chọn của tôi và giải thích 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 tôi.
Quay lại khi các preprocessors CSS đầu tiên được đưa vào thời trang, tôi đã 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 tôi, họ luôn cảm thấy như các giải pháp cần giải quyết vấn đề. Đó là, mình không thật sự tìm thấy "vấn đề" với CSS mà các nhà tiền giải quyết 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 quan trọng, có thể là trang web nhỏ chỉ với một vài trang tĩnh hoặc mạng nội bộ đơn vị khổng lồ. tôi chỉ đơn giả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 xử lý 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 đề.
tôi muốn kiểm soát tuyệt đối CSS của tôi, cho thấy mình muốn làm việc với nó, và xem 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 chúng ta 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ì thế 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 syntax 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ó. tôi cũng không muốn đồng nghiệp của mình phải làm như vậy.
Mình muốn CSS nguồn của tôi có thể triển khai mọi lúc, cho 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 trang web hơi chậm hơn có khả năng tốt hơn so với một trang web 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 để mình chuyển từ trình chỉnh sửa mã sang browser của mình và tải lại trang (≈1s) thì quá chậm.
Mình hoàn toàn nhận thức được rằng nhiều người sử dụng các preprocessors 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ì vậy không cần phải nói với tôi :-).
Bạn có biết:Java core
Tuy nhiên, tôi không sử dụng Sass hoặc các preprocessors CSS khác như cssnext không cho thấy rằng 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 trình duyệt có thể hiểu nó, điều mà mình thật sự muốn tránh.
Mình sử dụng PostCSS (với các plugin của bên thứ ba và những cái mình đã 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 là tôi luôn thấy kết quả. Không có black box. tôi có thể lưu 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 tôi tiết kiệm được một số cách 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 xử lý CSS của tôi.
No comments:
Post a Comment